1. RE: LISP-like expressions
Mike Nelson wrote:
>
>
> > I've noticed that there is a striking similarity between Lisp and
> > Euphoria: Lists and sequences are almost exactly the same thing.
> >
> > The only things that Euphoria lacks in order for it to actually by
> > definition *be* Lisp is functions as first-class objects (meaning,
> > essentially, that an actual function object can be returned as the
> > *result* of another function) and the use of the same sequence notation
> > as standard syntax for everything.
> >
> > I just find this really interesting, and wonder if perhaps coupled with
> > Diamond or a similar object system, Euphoria could in fact have some of
> > the extra benefits of Lisp.
> >
>
> I'd need to study more Lisp to see if I could implement all of what you
> are
> discussing. I'm confident that I could provide function objects as part
> of
> the Diamond Standard Class Library or as part of the Diamond kernel. I
> will
> look into this possiblity after I complete the 4.0 release.
>
Well, you can pass around functions as first-order objects in Euphoria
using routine-id. It is kind of clumsy and not nearly as elegant as in
a real functional language like Haskell, but it can be done.
I've implemented genetic programming in Euphoria (usually done in LISP)
where arbitrary functions are strung together. You have to write a
routine-id based evaluator to process the resulting expressions, but it
works fine...
2. RE: LISP-like expressions
Derek Parnell wrote:
>
> That is only one aspect of first-class objects. You still won't be able
> to create new routines at runtime and have them execute in the same
> address space as the application (eg. have them share variables). With
> using routine-id, you can only deal with routines that already exist at
> runtime. There is a convoluted method of doing this in WIndows/Linux
> environments, but it involves compiling a new routine as a shared
> library (eg. a Windows DLL) at runtime then loading that library, then
> running the routine - not a pretty method at all.
>
Not sure I understand. In a functional programming context, aren't any
new functions you make going to be built up from (combinations of)
existing functions & operators? You can do that with routine_id().
What kind of scenarios are you talking about?
