Somebody in comp.lang.python recently referred to a Lisp dialect
called "Lush". According to Google, it has never been mentioned in
c.l.l.
At a glance, it looks interesting enough to make me think some of you
might be interested too.
http://lush.sourceforge.net/
Could one of the list's CL experts look at this and review it? It
looks like it might be interesting, but I'm a newbie. What do I know?
I'd just like to see an educated opinion. Looks like a lot of work has
gone into it and it seems to have a lot of library support.
Thanks - Adam
Patrick W <···········@yahoo.com.au> wrote in message news:<··············@key.localdomain>...
> Somebody in comp.lang.python recently referred to a Lisp dialect
> called "Lush". According to Google, it has never been mentioned in
> c.l.l.
>
> At a glance, it looks interesting enough to make me think some of you
> might be interested too.
>
> http://lush.sourceforge.net/
············@yahoo.com (A.F. Smith) writes:
> Could one of the list's CL experts look at this and review it? It
> looks like it might be interesting, but I'm a newbie. What do I know?
> I'd just like to see an educated opinion. Looks like a lot of work has
> gone into it and it seems to have a lot of library support.
If the author had known about the ECLS project, he could have saved
himself the trouble of rolling his own Lisp->C translator (which I'm
assuming he did, since I didn't find any mention of using an existing
one). That way, it would have been mostly ANSI CL compliant, and then
he could have focused more on the core of what he's trying to
accomplish, which is efficient interfacing with some of the nicer
libraries out there.
Since some of the vendor-supplied C/C++ compilers are very good these
days (e.g. Intel's C++ compiler, from what I've heard), I think this is
a good way to go. It's interesting to note that as good as CMUCL is,
ECLS is probably one of the smarter moves in designing a CL system.
There is no overhead in trading data back and forth between CL and C in
ECLS, so FFIs become a while lot easier, with less overhead. This would
make it that much easier to borrow functionality from other systems
easier in general, since most such systems are written in C/C++.
To summarize my point, the main thing that I *don't* like about this
Lush thing is its departure from ANSI CL, which it could have gotten
mostly for free.
dave
"A.F. Smith" wrote:
>
> Could one of the list's CL experts look at this and review it? It
Not an expert. Since they didn't say Common Lisp, I was looking
for a list of the symbol attributes like CLHS Body/t_symbol.htm
in the Lush documentation. Usually Lisp-1 for scheme,
Lisp-2 (actually Lisp-5 ?)
Other classifications: ?
3, 2, or 1-Lisp (could/should we condense that to m-Lisp-n ?)
http://groups.google.com/groups?q=3-Lisp+2-Lisp+1-Lisp+group:comp.lang.lisp.*&hl=en&lr=&ie=UTF-8&selm=sfwra4pfqqx.fsf%40world.std.com&rnum=1
#f #t -vs- NIL, (), 0, everything else
Those are the ones I have come across so far.
> Patrick W <···········@yahoo.com.au> wrote in message news:<··············@key.localdomain>...
> > Somebody in comp.lang.python recently referred to a Lisp dialect
> > called "Lush". According to Google, it has never been mentioned
> > in c.l.l.
> >
> > At a glance, it looks interesting enough to make me think some of
> > you might be interested too.
> >
> > http://lush.sourceforge.net/