Re: New Lisp ?

[Andreas Bogk <address@hidden>]

David Rush <kumo@bellsouth.net> writes:

> > I don't think so.  Having to pass around handlers for all sorts of
> > conditions is a nuisance.  This is something CL and Dylan got right,
> > IMHO.
> Wel I've not written any large reactive systems using CPS for
> condition-handling, but it certainly seems to work well in my
> data-mining code. As things stand today, I'd probably not choose
> Scheme for a large GUI application, although I'm cooking up ideas to

As soon as you pile up some layers of code, it quickly becomes tedious
to pass around handlers everywhere.  Just imagine passing a GUI dialog
for resolving a "disk full" condition all the way through the GUI,
your application code, your storage abstraction down to the actual
disk access.

Imagine that you have some OS-agnostic code in the middle layers, and
that you don't even know that some condition might arise and that it
can be fixed.  Proper exceptions allow code at distant places to
communicate efficiently.

> > > > Oh, and dynamism vs. performance tradeoffs like sealing,
> Huh? What is this feature?

It allows you to specify that you won't add a new method to a certain
generic function, or some application domain of that function.  For
instance, the Dylan <integer> type is a regular class which cannot be
subclassed.  The + function is a generic function sealed over the
domain (<integer>, <integer>), so nobody can override that definiton.

So you get all the performance benefits you'd get when implementing
integers specially, like Java does, but still <integer>s are regular
objects, and you can get the same kind of performance benefits for
your own classes.

> > The point is that you can start writing code without caring about
> > performance. 
> Surely you *don't* really mean this. Big-O issues will jump up and get
> you if you don't think about them.

Actually, I usually nail down *what* I want to do with a naive
implementation, which isn't really intended to solve the problem, but
just serves me as some kind of formal specification of the problem,
which happens to be executable too.  Starting from that, I can
experiment with *how* to solve certain aspects, at which time big-O
complexity comes into play.  Only after having found the right
algorithms and a correct implementation for them I start to think
about low-level performance issues.  And I want my language to support
this kind of process.

> > Once the design has settled, you can sprinkle some
> > adjectives here and there, and the code becomes fast, without having
> > to re-implement performance-critical code.  I consider sealing to be a
> > good thing.
> Do you not also get the same benefits if you develop using good
> functional abstractions?

Of course you can.  I just happen to prefer generic functions, and I
want them to be as fast as the functional approach, which can be sone
with sealing.

Andreas

-- 
"In my eyes it is never a crime to steal knowledge. It is a good
theft. The pirate of knowledge is a good pirate."
                                                       (Michel Serres)