Re: ooeu [was Re: Proposal for math.e (2007-08-23)]
Kat wrote:
>
> Matt Lewis wrote:
> >
> > Kat wrote:
> > >
> > > CChris wrote:
> > > >
> > > > As for string execution, did you look at Matt's OOEu variant?
> > >
> > > Yes, i did, and i like OOEU a lot. OOEU's oop-ish if you like,
> > > but it isn't if you don't want. I like that implementation of classes a
> > > lot.
> > >
> > > But.. it can be *extremely* slow at some things. I suspect converting
> > > it to the newer Eu versions would speed it up, since most of the lag
> > > seems to be in memory allocation when dealing with dozens of megabytes
> > > of data coming in.
> >
> > The issue is that I haven't ported the eval() functionality to the C-based
> > backend yet. I think it's possible (at least for interpreted code), but
> > there are some serious changes that need to be made.
>
> But even loading a disk file into an array already made with repeat(),
> the bigger the file, the slower it goes, drastically. I am talking about
> a 34megabyte file in this case, but i have files 100x that big.
>
> <snip>
>
> > > I hope all of OOEU appears in some form in openeu, with appropriate
> > > credits to Matt.
> >
> > Thanks. I think certain things should be left out, like some of the
> > dynamic goto stuff. I think the static gotos are a good thing to add,
> > or at the minimum, a more structured form of them for things like exiting
> > loops with more flexibility and power than we currently have. There are
> > also some changes that I would make to the way OOP works to make it
> > better.
>
> As usual, i'd prefer all of it be included. While the dynamic goto
> is used rarely, that's not because it isn't needed in the cases it's used.
> I needed it way back in C64 days, and wrote enough peeks and pokes to
> modify the oem rom code to make it happen. As for Euphoria, it makes a
> handy case() statement as well.
>
> I suppose there's no need to restart a flame war about goto,
> so i won't argue it anymore, i'll just say i want it.
>
> It was me, i confess,
> and you prolly figured out, i emailed CK to add goto to the bounty site.
> It doesn't make sense to throw away good code you already wrote
> just because a few people won't use it.
>
> Kat
Dynamic gotos are handy, and after ll that's how the execution engine in
be_execute.c works when compile as "threaded code". I still prefr calling a
csae() a case() and have it as an explicit statement though.
You can kinda get it now by using a variable in the first argument of
call_func() or call_proc().
Y say "kinda" because the separate routines you call do not share the caller's
variables, which is quite a annoyance there. Putting the whole thing in a file by
itself and using local, rather than private, variables solves this, but raises
other issues, in particular because it would be "too complicated" to implement a
package system in a correct way.
This is why I had suggested in the past having nested functions the way Pascal
does. You could still call_func() dynamicallly, and yet protect all needed
variables inside the main routine. And it can be done without any extra keyword,
which is of paramount importance here. But somehow this hasn't picked much
support, even though it works fine in my own copy of the interpreter.
CChris
|
Not Categorized, Please Help
|
|
