Common Lisp features in Clojures
vseguip
total newbie, I think Common Lisp and Scheme are good languages but it
lacks the libraries of the Java platform. Your project seems like a
nice approach to providing a Lisp for the masses. OTOH CL and Scheme
do have some powerful features that I think Clojure lacks and would
profit a lot from. I would like to know your opinion on the following
features and wether you plan or think it is a good idea to implement
them.
1) The CL condition system seems far superior to me than the classical
Java Try-.Catch.
2) A CLOS kind of object system (although this can probably be built
on top of the current clojure)
3) Scheme continuations.
4) A comprehensive SLIME kind of environment
5) The ability to save/restore a core image.
Thanks for your work,
V. Segui
Rich Hickey
On Oct 24, 5:45 pm, vseguip <vseg...@gmail.com> wrote:
> First of all I want to congratulate you for your job. Although I'm a
> total newbie, I think Common Lisp and Scheme are good languages but it
> lacks the libraries of the Java platform. Your project seems like a
> nice approach to providing a Lisp for the masses. OTOH CL and Scheme
> do have some powerful features that I think Clojure lacks and would
> profit a lot from. I would like to know your opinion on the following
> features and wether you plan or think it is a good idea to implement
> them.
>
> 1) The CL condition system seems far superior to me than the classical
> Java Try-.Catch.
The CL condition system may be superior, but exceptions are the
standard on the host and so that is what Clojure will support. I think
there are some opportunities to emulate some of the capabilities of
the condition system using dynamically bound functions. e.g. setting
up error handling policy by dynamically binding functions to be called
further down the call chain when a problem happens. This could
potentially enable resumption rather than bailout. I'm not claiming
this is the same as the condition system.
> 2) A CLOS kind of object system (although this can probably be built
> on top of the current clojure)
It could, but I'm not interested in it. In many ways Clojure is a
response to the problems of OO. That said, I have been designing an
event-driven actor system for Clojure which will feel like objects but
be concurrency aware and integrated with transactions and
multimethods.
> 3) Scheme continuations.
Not interested at all.
> 4) A comprehensive SLIME kind of environment
I don't use SLIME, (I'm a LispWorks customer), but I fully understand
the desire. This is something I hope will come from the users. I have
played a bit with NetBeans (Schliemann) editor support, and have some
syntax highlighting working. I also have had success debugging with
JSwat, including stepping, breakpoints, local variables etc. Clojure
emits the data needed for standard Java debugging.
> 5) The ability to save/restore a core image.
Nice capability, not on the agenda right now.
> Thanks for your work,
You're welcome.
Stefan Lang
> On Oct 24, 5:45 pm, vseguip <vseg...@gmail.com> wrote:
> > 1) The CL condition system seems far superior to me than the classical
> > Java Try-.Catch.
>
> The CL condition system may be superior, but exceptions are the
> standard on the host and so that is what Clojure will support. I think
> there are some opportunities to emulate some of the capabilities of
> the condition system using dynamically bound functions. e.g. setting
> up error handling policy by dynamically binding functions to be called
> further down the call chain when a problem happens. This could
> potentially enable resumption rather than bailout. I'm not claiming
> this is the same as the condition system.
It seems to me that the only feature missing to implement
CL's condition system is block/return-from (I think a more general
term for this is "escape continuations"). Though this system would
be separate from regular exceptions, since these unwind the stack.
I read a blog post once where someone (possibly from Sun)
described how to implement escape continuations efficiently on
the JVM. I'll post the link if I find it again, but the basic idea was
to
create a distinct Exception class E for each "block", emit a
try/catch E around the block and return-from compiles to "throw E".
The be efficient, the "throw" mustn't generate a stack trace.
Rich Hickey
Funny - I had implemented exactly that in an earlier version of
Clojure, when I was trying to subset CL. I no longer am trying to do
that - I think people that really want CL want all of CL, and I
recommend ABCL for CL on Java in that case.
I think dynamic functions + exceptions are the right thing for
Clojure. CL doesn't have dynamic functions, but one (inexact) way to
look at handlers/handler-bind/restarts is as dynamic functions
dedicated to error handling. I prefer general dynamic functions.
That said, I still haven't provided try-catch (hopefully this
weekend), so that's where I'm focusing :)
wm.a...@gmail.com
> That said, I still haven't provided try-catch (hopefully this
> weekend), so that's where I'm focusing :)
*whew*
A macroexpand might be useful for people new to lisp. If I
knew Java I'd add it myself.
--
wm
Rich Hickey
describes what I'm working on and what's next.
Stefan Lang
here's the promised link:
http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive
Rich Hickey
> Anyway, in case someones interested in this stuff,
> here's the promised link:http://blogs.sun.com/jrose/entry/longjumps_considered_inexpensive
The Clojure transaction system uses pre-allocated exceptions as
described in the article.