] ]> [...] ]> hi ]> ]> this makes me so curious. how csn one implement GOTO in lisp? ]> ]> [...] ] ]Do you know about the GO special operator? If so, are you asking ]about its implementation? ] ] ]-- ]Samir Barjoud ]sa...@mindspring.com ] ]
bpar...@email.unc.edu (Bijan Parsia) writes: > Erik Naggum <e...@naggum.no> wrote:
> [snip]
> > I think Scheme is an _inelegant_ language the exact same way I > > think anything else that is beautiful only when tiny and undeveloped > > grows into huge morasses of disgustitude when actually put to real use, > > like GUILE. it actually amazes me constantly that the elegance of Scheme > > does not scale beyond the standard and the core language, but it's like
> Have you had a chance to look at the SRFIs (Scheme Requests For > Implementation <http://srfi.schemers.org/>)? I'd be interested in > whether you think the scaling problem holds there. The whole SRFI > processs seems to be the first, general, community based attempt to > expand the scope of (portable) Scheme.
The SRFI process is a good thing and I would advocate a similar one for CL. But, let's consider what are the current SRFI for Scheme, let's say SRFI Final 8: "RECEIVE: Binding to multiple values". Or SRFI 12: "Exception Handling", or, again, SRFI 13: "String Library".
Do we see a pattern here? Or maybe it easier to see what is missing? :)
In other words, there is a way to "expand the scope of (portable) Scheme": use CL. :)
Cheers
-- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa
>>>>> "Rob" == Rob Warnock <r...@rigden.engr.sgi.com> writes:
[...]
Rob> Exactly. CL gives you the *choice* of binding lateness versus Rob> effeciency, because "symbol-function" is in the language Rob> standard and is relatively cheap, compared to "eval". I didn't Rob> mean to imply that CL *couldn't* pass closures, or that it Rob> wasn't usually "the right thing", but only that Rob> Scheme-the-standard doesn't give you a *choice* other than Rob> (presumably slow) "eval", so passing closures is usually Rob> considered the "only right thing".
I don't understand why must we use eval.
Rob> Having said that, of course, someone will chide me about how Rob> specific *implementations* of Scheme give you Rob> "(global-defined-value <symbol>)" [which, for Scheme, a Lisp-1, Rob> is the closest equivalent of "symbol-function" and presumably as Rob> cheap] or the like, but I think we're talking mostly about the Rob> standard-defined languages here, yes? Implementation extensions Rob> don't count in such discussions.
Antonio Leitao <a...@gia.ist.utl.pt> wrote: +--------------- | >>>>> "Rob" =3D=3D Rob Warnock <r...@rigden.engr.sgi.com> writes: | Rob> Scheme-the-standard doesn't give you a *choice* other than | Rob> (presumably slow) "eval", so passing closures is usually | Rob> considered the "only right thing". | | I don't understand why must we use eval. +---------------
Because the original problem being discussed was hooks that are lists of *symbols*, as is often done in Emacs & CL, not closures. That is:
(define my-hooks (list 'func1 'func2))
Now, if (for better or worse) that's how the hook is *defined*, how do you call those functions in *standard* Scheme without using "eval"? [...or a non-standard extension such as MzScheme's "global-defined-value".]
+--------------- | What's the problem with this approach? ... | (define my-hooks (list func1 func2)) ... | (define (run-hooks hooks) | (for-each (lambda (hook) ((car hook))) hooks)) +---------------
[Uh... You don't need the "car"; "for-each" does that for you.]
Well, your hook variable is a list of *closures*, not symbols. That certainly "works" (for some definitions of "work"), but fails to address two of the issues others expressed in this thread: (1) that the traditional Lisp hook style is to use symbols, and (2) that using symbols instead of closures has the advantage of automatically using the *new* value of any hook function that's redefined, even *after* being added to the hook. Compare both ways:
> (define (foo) (print "foo")) > (define (bar) (print "bar")) > (define sym-hook (list 'foo 'bar)) ; the symbol-based version > (define (do-sym-hooks) (for-each (lambda (x) ((eval x))) sym-hook)) > (define clo-hook (list foo bar)) ; the closure-based version > (define (do-clo-hooks) (for-each (lambda (x) (x)) clo-hook)) > (do-sym-hooks) foo bar > (do-clo-hooks) foo bar >
The same so far, yes? Now look what happens when we redefine one of the hook functions:
> (define (foo) (print "this is a new, improved foo!!")) > (do-sym-hooks) this is a new, improved foo!! bar > (do-clo-hooks) foo bar >
Oops!!
-Rob
p.s. Yes, there are ways to get around this problem *without* using "eval", e.g., make every hook function be a trampoline for the "real" function, the one that gets edited:
> (define (real-foo) (print "foo")) > (define (foo) (real-foo)) > (define clo-hook (list foo bar)) > (do-clo-hooks) foo bar > (define (real-foo) (print "this is a new, improved foo!!")) > (do-clo-hooks) this is a new, improved foo!! bar >
But 'tis a bit cumbersome, yes?
----- Rob Warnock, 8L-846 r...@sgi.com Applied Networking http://reality.sgi.com/rpw3/ Silicon Graphics, Inc. Phone: 650-933-1673 1600 Amphitheatre Pkwy. FAX: 650-933-0511 Mountain View, CA 94043 PP-ASEL-IA
* Rob Warnock wrote: > Well, your hook variable is a list of *closures*, not symbols. > That certainly "works" (for some definitions of "work"), but fails > to address two of the issues others expressed in this thread: > (1) that the traditional Lisp hook style is to use symbols, and > (2) that using symbols instead of closures has the advantage of > automatically using the *new* value of any hook function that's > redefined, even *after* being added to the hook. Compare both ways:
No, I think his hook var is a list of lists, the car of each list being a function/closure, so (because you can clobber the car of the list), some kind of redefinition would work. But it wouldn't be the kind you get in CL -- redefine the function, and the new one gets called, you'd need a special macro or something to do this. Which is kind of what CL people are complaining about -- in Scheme you need to do everything yourself!
>>>>> "Rob" == Rob Warnock <r...@rigden.engr.sgi.com> writes:
Rob> Antonio Leitao <a...@gia.ist.utl.pt> wrote: Rob> +--------------- Rob> | >>>>> "Rob" =3D=3D Rob Warnock <r...@rigden.engr.sgi.com> writes: Rob> | Rob> Scheme-the-standard doesn't give you a *choice* other than Rob> | Rob> (presumably slow) "eval", so passing closures is usually Rob> | Rob> considered the "only right thing". Rob> | Rob> | I don't understand why must we use eval. Rob> +---------------
Rob> Because the original problem being discussed was hooks that are lists Rob> of *symbols*, as is often done in Emacs & CL, not closures. That is:
Rob> (define my-hooks (list 'func1 'func2))
Rob> Now, if (for better or worse) that's how the hook is *defined*, how Rob> do you call those functions in *standard* Scheme without using "eval"? Rob> [...or a non-standard extension such as MzScheme's "global-defined-value".]
It's not that hard, actually. Just use an assoc-list (or hashtable) that relates the symbol to the function. If that's the way you want to define my-hooks, I would say that:
(def-hook (func1) (display "do more things") (newline))
that takes car of updating the hook-function-table. Again, it doesn't look very hard.
You might argue that this approach is slower than using eval. You can you hashtables, if you need the extra speed, but at least you have the usual lexically scoped evaluation.
Rob> +--------------- Rob> | What's the problem with this approach? Rob> ... Rob> | (define my-hooks (list func1 func2)) Rob> ... Rob> | (define (run-hooks hooks) Rob> | (for-each (lambda (hook) ((car hook))) hooks)) Rob> +---------------
Rob> [Uh... You don't need the "car"; "for-each" does that for you.]
Are you sure? I don't think you can do that. For-each is applied to a list of lists. Each of the lists contains just one function. Each list is in fact an handle that allows me to change the function dynamically. As a result, the lambda is applied to each of these handles and must use car to extract the function.
Rob> Well, your hook variable is a list of *closures*, not symbols.
Not quite.
My hook variable was (in the version you are mentioning) a list of handles to closures. See above.
Rob> That certainly "works" (for some definitions of "work"), but fails Rob> to address two of the issues others expressed in this thread: Rob> (1) that the traditional Lisp hook style is to use symbols, and
I use symbols in the second version.
Rob> (2) that using symbols instead of closures has the advantage of Rob> automatically using the *new* value of any hook function that's Rob> redefined, even *after* being added to the hook. Compare both ways:
Again, you just need some macrology to hide the update (either to the handle in the first version or to the assoc-list in the second version).
It's obvious that this would not work. But if you look carefully to my solution you will see that it's not what you are suggesting. Try my solution.
Rob> The same so far, yes? Now look what happens when we redefine one Rob> of the hook functions:
>> (define (foo) (print "this is a new, improved foo!!")) >> (do-sym-hooks) Rob> this is a new, improved foo!! Rob> bar >> (do-clo-hooks) Rob> foo Rob> bar >>
Rob> Oops!!
Pretty obvious...
Look again at my previous solution, please.
Note that I'm not a Scheme fanatic (or CL fanatic, for that matter). I just didn't understand what was so different in Scheme and CL that would make impossible to do in Scheme something so simple as implementing hooks.
Maybe I'm still not understanding the problem...
On the other hand, there are some things in Scheme that are extremely difficult to implement in CL. As a result, I think that with some extra SRFIs (maybe 20 more) Scheme will be similar to CL, (modulo being a Lisp1) but with one added feature: first class continuations.
Rob> p.s. Yes, there are ways to get around this problem *without* using Rob> "eval", e.g., make every hook function be a trampoline for the "real" Rob> function, the one that gets edited:
>> (define (real-foo) (print "foo")) >> (define (foo) (real-foo)) >> (define clo-hook (list foo bar)) >> (do-clo-hooks) Rob> foo Rob> bar >> (define (real-foo) (print "this is a new, improved foo!!")) >> (do-clo-hooks) Rob> this is a new, improved foo!! Rob> bar >>
Erik Naggum <e...@naggum.no> writes: > * Christophe Kirkwood-Watts 0790340 <kirkw...@cna0790340.rsc.raytheon.com> > | True, true. (apply #'funcall <list>) is quite a bit more elegant than the > | latter; however, this is generally not the way work gets done in Scheme, > | as you no doubt know.
> please get your attributions right.
Which did I get wrong? I have re-examined my post and the postings previous in this thread, and I am unable to locate the error.
> I'm taking a Schemer's proposed code as a given. I make no > representation to write elegant Scheme code.
The code to which I can only assume you refer is reproduced below. Notice that it is _not_ what the "Schemer" wrote, nor does it perform the same action. Consequently, I can only conclude that either you made it up, or you yourself are the source the attribution error.
> I also happen to do (apply #'funcall <list>) at times. I guess Scheme's > (apply (eval (car list)) (cdr list)) is much more _elegant_. hee hee!
As far as the rest of the post is concerned, please realize that you are arguing against no one.
> Scheme is an _inelegant_ language the exact same way I think anything > else that is beautiful only when tiny and undeveloped grows into huge > morasses of disgustitude when actually put to real use, like GUILE.
[...]
> just you get your attributions right, mister, and this will all rectify > itself automatically. and check your blood pressure while you're at it. > I don't like Scheme, and I make no bones about it. if you don't like > that somebody thinks Scheme is ugly and the Scheme community silly for > its insistence on elegance through missing features, learn to live with.
I regret that it was inferred that my hostility was directed towards you on account of your attitude towards Scheme. I am well aware of this attitude, and I respect your opinions. It was, however, the opportunistic and mindless Scheme-bashing which simply did not seem warranted in this case, since the catalyst of the tirade was Scheme code that you personally constructed.
Chris.
-- Chris Kirkwood-Watts 972/5756402 kirkw...@raytheon.com
In article <3151187105895...@naggum.no>, Erik Naggum wrote: >* Tord Kallqvist Romstad >| This works, of course, but I thought matt meant that all the functions in >| list-of-functions should be used on the same argument (in his example, a >| news article). Having to construct a list of copies of this single >| argument of the same length as the list of functions seems very >| inconvenient.
> it would indeed, so we don't. given this very useful function:
> but it's OK to be a little afraid of this code until you figure it out.
I like code which scares me, I can usually learn a lot from it (unless it is scary because it is badly written, of course). After some thought, I understand how this code works, but I am not at all sure I would be able to invent this idea myself. Thank you for sharing this idea with me!
as the standard spec on &rest args (3.4.1.3 A specifier for a rest parameter) explicitly allows: The value of a rest parameter is permitted, but not required, to share structure with the last argument to apply.
I don't know if this is a problem with any actual current implementation, though.
Bernhard -- -------------------------------------------------------------------------- Bernhard Pfahringer Austrian Research Institute for http://www.ai.univie.ac.at/~bernhard/ Artificial Intelligence bernh...@ai.univie.ac.at
What exactly are "first-class continuations" in Scheme? Semantically, Scheme and Common Lisp's LAMBDA expressions are identical (modulo an explicit FUNCALL in CL to get around it's Lisp-2-ness), so I assume your talking about something other than closures in either language. Are you talking about CALL-WITH-CURRENT-CONTINUATION in Scheme?
-- "I'm very busy. I'm preparing my next mistake." -- B. Brecht
>>>>> "Matthew" == Matthew Economou <xenop...@irtnog.org> writes:
Matthew> Antonio, Matthew> What exactly are "first-class continuations" in Scheme? Matthew> Semantically, Scheme and Common Lisp's LAMBDA expressions Matthew> are identical (modulo an explicit FUNCALL in CL to get Matthew> around it's Lisp-2-ness), so I assume your talking about Matthew> something other than closures in either language. Are you Matthew> talking about CALL-WITH-CURRENT-CONTINUATION in Scheme?
> Tim Bradshaw <t...@tfeb.org> wrote: > +--------------- > | * Fernando D Mato Mira wrote: > | > | > *cough* The "_modern_Lisp_ moral equivalent" is to pass closures, > | > not global function names. > | > | I thought there was just a whole thread about how this was actually a > | bad thing to do sometimes: > | > | (cons #'foo *hooks*) > | > | (defun foo () > | ;; oops > | ...) > +---------------
> Exactly. CL gives you the *choice* of binding lateness versus effeciency, > because "symbol-function" is in the language standard and is relatively > cheap, compared to "eval". I didn't mean to imply that CL *couldn't* pass > closures, or that it wasn't usually "the right thing", but only that > Scheme-the-standard doesn't give you a *choice* other than (presumably slow) > "eval", so passing closures is usually considered the "only right thing".
The right way to do this is not to use symbols but as follows:
(defglobal *hooks* ())
(defmacro add-hook (fn) (if (symbolp fn) ;; add indirection to catch any redefinitions of fn `(add-hook-fn #'(lambda () (,fn))) ;; otherwise assume it's an expression evaluating to a function object. `(add-hook-fn ,fn)))
This avoids the evil symbol-function, which is evil in the same way as eval is evil (i.e., it refers explicitly to the global environment and thus interlaces programs too closely to the development environment, making application delivery harder.)
> > > I think Scheme is an _inelegant_ language the exact same way I think > > > anything else that is beautiful only when tiny and undeveloped grows > > > into huge morasses of disgustitude when actually put to real use, like > > > GUILE. it actually amazes me constantly that the elegance of Scheme > > > does not scale beyond the standard and the core language, but it's > > > like [snip]
> The SRFI process is a good thing and I would advocate a similar one > for CL. But, let's consider what are the current SRFI for Scheme, > let's say SRFI Final 8: "RECEIVE: Binding to multiple values". Or > SRFI 12: "Exception Handling", or, again, SRFI 13: "String Library".
> Do we see a pattern here? Or maybe it easier to see what is missing? :)
> In other words, there is a way to "expand the scope of (portable) Scheme": > use CL. :)
:) Sure. And even when we have SRFI 1000, there will still be a number very good reasons to use Common Lisp. No doubt whatsoever.
The point in question is whether Scheme can remain "elegant" (both in the common judgement, and by its core community's lights) while scaling up to the functionality of Common Lisp. In other words, when we hit SRFI will we merely have a gigantic bug collapsing under it's own weight with *really* hideous feelers aping the elegant trunk of an elephant? I.e., will we have Common Scheme or GUILE (in the way Erik described it) ;)
Of course, there are (at least) two ways Scheme could falter in this scaling--it could turn really ugly and cumbersome, or it could depart from the notion of elegance embodied in the standard and the core language (i.e., as if one implemented Common Lisp on top of a Scheme core). If the langauge you end up using isn't recognizably Scheme, then what *was* the point of expanding it? (I'll contrast again with Smalltalk...expanding Smalltalk doesn't require introducing entirely new techniques or styles. The *feel* of programming remains pretty much the same across the board.)
Robert Monfera <monf...@fisec.com> wrote: > Bijan Parsia wrote to Erik:
> > Have you had a chance to look at the SRFIs (Scheme Requests For > > Implementation <http://srfi.schemers.org/>)? I'd be interested in > > whether you think the scaling problem holds there.
> To chime in without being asked (this is not an answer anyway): [snip] > On the other hand, you recognize that it adds to language size and > complexity, which is not a problem, as these things are often being done > now in one implementation or another, and tools that scale well with > problems are usually a bit more complex than ones where tool size > minimalism matters more.
*Usually*, yes. Absolutely. I guess the real life question is what's the (an) optimal tradeoff. (Aiya, yes, it's much more complex than this. I'm really just wondering about Scheme and whether it is such that given it's particular minimalism, the techniques one develops using the core language--the lessons it teaches--just fail when applied to larger domains. They problem isn't just *should* one standardize libraries, but does adding the useful stuff make Scheme hideous? The difference between the SRFI process and the stuff particular implementors have built is that roughly the same folks who value (in all their different ways) the Scheme standard, are working on, and commenting on, the SRFI. So they're more nearly an expression of the same consuses values that produced the standard. Thus, one would hope, SRFIs will generally have the same properties as the standard. If it's an inherent feature of Scheme that it can't scale without ugliness, *this* (and not, e.g., GUILE) is the place to look.)
[snip]
> I found myself, however, preferring CL more and more for its maturity, > completeness and portability.
Again, CL definitely has those virtues. In spades. But I think, and I'm pretty sure Erik thinks, that CL has it's own (kind of?) elegance. And that's a reason to like and use it. Even if Scheme with SRFI 1-1000 provides all the functionality of CL *and* does so in a "schemely elegant" way, there will, I wager, be reasons to prefer the Common Lispy elegant way.
(That the current standard may not full exemplify the platonic idea of CL elegance is, naturally, no proper strike against it. It certainly is the current *best* exemplar it, and a rather decent exemplar it is.)
[snip]
> So to reverse the question you asked: don't you think Scheme (or maybe > even Java to a lesser extent) eventually finds its way towards being > comparable to CL* (both in size and features), but you have to carry the > burden of ever-evolving and growing Scheme interpreters/compilers?
Huh? The extant CL implementations are every-evolving and growing as well, as is good.
> Aren't you spending quite some time already designing and implementing > new Scheme features, looking up CL specifications for inspiration and > juggling Scheme environments? In the meantime, I always _use_ the > language when I start a CL environment.
Even if true, I don't quite see the point. I can perfectly well grant that CL is more mature and stable (which I do) without granting that Schemely elegance can't scale to CL scope. Which is what I'm curious about. Common Lisp has hard evidence that it can handle big problems well. Scheme, whilst remaining Schemely, hasn't yet proven that. If it can, then there's more choice for people who might find they prefer a Schemely style.
[snip]
> Relative to the history of Scheme and CL, I am a > newcomer, open-minded about making my choice of language for the time > horizons that matter to me. I'm also prone to go my way and > re-innovate, but I have often find it unproductive.
Sure. I'm not sure why your telling *me* this. I'm not a programmer, nor do I do much more than *study* Scheme and CL (but I do study both). When I do program, I tend to program in Smalltalk, which bears some resemblance to Scheme (small core) and CL (lots of functionality, scales well to big problems). (This is *not* to say, imply, suggest, whatever that Smalltalk is Better than CL or Scheme; I just offer it as an existence proof that minimal initial toolset needn't fail to scale. If Scheme can't scale, I suspect that it's something *else* about the minimalism. But I don't know that it can't scale. One example of, IMHO, a unpleasant "beefed up" Scheme is DrScheme. Bleah. Of course, part of their problem is the UI toolkit they use for cross-platform support (wxWindows) which is horrible, horrible.)
[snip]
You've really lost me. I'm not arguing for Scheme over Common Lisp, or Common Lisp over Scheme. Nor am I trying to entice anyone. So all this stuff is irrelevant.
>This avoids the evil symbol-function, which is evil in the same way as eval >is evil (i.e., it refers explicitly to the global environment and thus >interlaces programs too closely to the >development environment, making application delivery harder.)
Indeed. The symbol-function approach is OK, I guess, for .emacs customization and such, but that it is not available as immediately in Scheme as in CL is not a big loss.
>This avoids the evil symbol-function, which is evil in the same way as eval >is evil (i.e., it refers explicitly to the global environment and thus >interlaces programs too closely to the >development environment, making application delivery harder.)
Is there a concise discussion of the problem of application delivery in Lisp somewhere? What other functions make this more difficult?
-- Kenneth P. Turvey <kt-...@SprocketShop.com> -------------------------------------------- Over himself, over his own body and mind, the individual is sovereign. -- John Stuart Mill
> >This avoids the evil symbol-function, which is evil in the same way as eval > >is evil (i.e., it refers explicitly to the global environment and thus > >interlaces programs too closely to the > >development environment, making application delivery harder.)
> Is there a concise discussion of the problem of application delivery in > Lisp somewhere? What other functions make this more difficult?
My ex-ILOG Talk colleagues and I wrote a paper about this subject for the ACM Lisp and Functional Programming Conference in 1994 ("Talking about Modules and Delivery," by Davis, Parquier, and Seniak), where we discuss the interlacing of the compilation and execution environments common in most Lisp implementations and how we avoided it in the ILOG Talk module system, whose explicit goal was simplifying the delivery of applications.
Bijan Parsia wrote: > Thus, one would hope, SRFIs will generally have the same > properties as the standard.
As one of the defining qualities of the standard is minimalism, this is difficult to expect.
> Again, CL definitely has those virtues. In spades. But I think, and I'm > pretty sure Erik thinks, that CL has it's own (kind of?) elegance.
I haven't said CL is not elegant, I just haven't based my argument on CL's elegance.
> And > that's a reason to like and use it. Even if Scheme with SRFI 1-1000 > provides all the functionality of CL *and* does so in a "schemely > elegant" way, there will, I wager, be reasons to prefer the Common Lispy > elegant way.
Absolutely.
[arguments on Scheme growth and instability from me]
> Huh? The extant CL implementations are every-evolving and growing as > well, as is good.
Yes, but please note that fundamental and substantial (useful) applications from many years ago are still capable of running. There has always been a remarkable stability in the CL world, and the key is that the standard has covered enough ground to allow useful applications. Even non-standard features like multiprocessing are more similar across implementations than the wild variety of object systems for Scheme.
> I can perfectly well grant > that CL is more mature and stable (which I do) without granting that > Schemely elegance can't scale to CL scope. Which is what I'm curious > about. Common Lisp has hard evidence that it can handle big problems > well. Scheme, whilst remaining Schemely, hasn't yet proven that. If it > can, then there's more choice for people who might find they prefer a > Schemely style.
It seems to me that much of Scheme's style stems from its minimalism. Reading both c.l.l. and c.l.s., I am yet to see a convincing example for Schemely style. The examples that came up (e.g., avoiding funcall or macro hygiene) could be trivially done in CL with short macros. Maybe you have got something specific in mind?
[snip]
> Sure. I'm not sure why your telling *me* this. I'm not a programmer,
It is difficult to define who you call a programmer. By the way, I am not sure why you are telling *me* you are not a programmer :-)
> When > I do program,
Alright, I have assumed you are a Scheme programmer because of the contents of your posting and the fact that this was about the first time I saw your name on c.l.l.
In article <382cd4d6$0$...@newsreader.alink.net>, "Harley Davis" <nospam_hda...@nospam.museprime.com> wrote:
> My ex-ILOG Talk colleagues and I wrote a paper about this subject for the > ACM Lisp and Functional Programming Conference in 1994 ("Talking about > Modules and Delivery," by Davis, Parquier, and Seniak), where we discuss the > interlacing of the compilation and execution environments common in most > Lisp implementations and how we avoided it in the ILOG Talk module system, > whose explicit goal was simplifying the delivery of applications.
Yes, there is a linux version in there, but it hasnt been updated wrt to libc issues for a long while. The last version of linux I had it working with was RH 5.2. It might still work with the libc5 compatibility stuff tough really I think it needs rebuilding now and some changes to the emacs lisp code (It had a great emacs interface, especially the stepper).
> This avoids the evil symbol-function, which is evil in the same way as eval > is evil (i.e., it refers explicitly to the global environment and thus > interlaces programs too closely to the > development environment, making application delivery harder.)
Harley,
I can see an advantage to your approach, namely that it handles refs to both global and local functions in a uniform way. And a compiler (or whatever) can tell what function you're referring to, something not revealed by the symbol-function approach. So your approach may well be better for application delivery.
However, I don't agree that symbol-function has a pernicious connection with the development environment. A Lisp with no development environment could still have symbol-function.
