Re: Lush changes?

Hi Raymond,

Yes, I'm maintaining a little lush derivative. There are three main 
kinds of changes I am making (I consider them as improvements, but what
an improvement is can be very subjective, so I don't expect everyone
to agree with me on this):

1. Consistency of the Lisp API and the C API
2. CL compatibility
3. Improvements of the API in general

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!
    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). I don't have performance concerns--
    as long as the array manipulation functions are fast and are
    flexible to combine (another area of possible improvement, but I
    haven't spend any time on that yet), you should be able to write
    code that's fast.

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).

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'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.

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.

Cheers,
Ralf






> Hi Ralf,
>
> Yann mentioned in a recent mail on the Lush developers list that you are building
> your own version of Lush with some major changes.
>
> Can you share some details with me (others on the list) about your changes/plans?
>
> I am interested to hear your ideas.
>
> 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