Re: Lush changes?

Hi Ralf,

> Some comments one each point:
> 1. Is useful if you decide that there is a function that you rather
>     want to implement in C for efficiency. But you get Lisp objects
>     in and you want to handle them, extract particular information
>     from it, and you want to build Lisp objects as output. This
>     becomes easy if you have all the lisp core functionality on the
>     C side also and if it goes under the same name!

You intend to have Lisp input with capability for both Lisp or C output.

>     A second, more long term goal is to eventually be able to compile
>     all of lush. This would be a deviation from Lush's current
>     philosophy where there's no dynamic memory management in compiled
>     code (well, it's possible but awkward as Leon pointed out in a
>     recent posting on lush-users). 
> [snip]

I take that you mean the end user will be able to, but not necessarily required to, 
compile their own code.

Memory allocation and garbage collection might be something like in Java. Lush
has single inheritance like Java and Java has ideas from both C++ and Lisp in it
(Guy Steele worked on the Java spec after all).


> 2. I'm not advocating complete CL compatibility (for instance, I
>     don't like CL's idea of having two things associated with a
>     symbol (write #'a for the function, and a for the value). But I
>     believe it would be helpful for people who come to lush and find
>     the semantics of functions equal to that of a standard (CL). So
>     they can take a CL textbook and learn a good part of lush.
>     And people who know CL already are not put off by different
>     semantics. Plus, the CL semantics is often a little more
>     useful (e.g., compare lush's 'apply' and 'mapcar' with CL's).

Complete CL compatibility would be quite an undertaking, especially if
CLOS compatibility is included (not to mention anything resembling a
meta-object protocol). There is something like 1500 functions in that.
Compare that to about 40-50 keywords in C.

More CL stuff is definitely needed to bring more people over to Lush and to
ease porting efforts.
 
> 3. There are many parts of the API that simply aren't very good.
>     The worst is the index API. You can't tell by just looking at a
>     function's name whether an index function changes the index
>     structure only, or the storage content along with it, nor whether
>     it does these manipulations in-place or produces a new object
>     instead. And we should not call everything a matrix, a matrix is
>     an array with two dimensions (of course, you know that).

I'd say that part of the problem with this boils down to naming scheme
and documentation. These are things that are relatively easy to fix, but
given the size of the documentation can take some time to resolve.
 
> I've made many changes of all these different kinds and I already
> talked briefly with Yann about it: psu-lush (that's how I call
> it tentatively) is not backwards compatible with sf-lush (the lush
> on sourceforge), and I'm convinced that we can't make substantial
> improvements without breaking compatibility. Yann sounded open to
> working towards a common next-generation kind of lush where we'd
> break compatibility with current sf-lush. That would be great, if
> we could work together.

Perhaps it would be good to look down the road a bit. The rate of progress
on Lush thus leads me to guess that version 2.0 should come around in about
4 years. A good chunk of time for 1.x version to advance and your version
to become stable, plus time to see which parts of 1.x, your version, and other
yet unknown additions/changes could possibly merge into a 2.x series.

Some participation in developing a roadmap would be a start.
 
> I'm planning to make psu-lush available soon. I have a deadline
> coming up and need to catch up with documentation. So, I'd say
> something like mid to end of October is realistic.

I'll be glad to see what you come up with.

Raymond


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf