Thanks to everyone who replied to my previous post!
I am still trying to decide between Lisp and Scheme. Keeping in mind
that I will be developing in Windows, and code speed is fairly
important I have another question, which is:
Is there anything relevant to programming in the real world that Lisp
is able to do that Scheme cannot, without significant effort and
vice-versa?
Please, I am not trying to start a flame war.
I know that there are differences between Scheme and Lisp in some areas
and have done some reading up, but without extensive understanding and
experience with either one or the other it is almost impossible to know
if the differences impact on real world programming in any significant
way as the languages seem to be almost identical in terms of their
abilities.
Again I emphasize, I know this is an emotional issue with some people
but it is not my intention at all to "stir the pot". My approach is -
"what works best in the real world".
> I am still trying to decide between Lisp and Scheme. Keeping in mind
> that I will be developing in Windows, and code speed is fairly
> important I have another question, which is:
WOW, i did ask same question to me 1 year ago & i solved it & now i
feel qualified to answer your question : -).
the only difference was Linux.
Pascal Constanza is right. play around with both languages for some
time & see where you fit. actually everyone has a different
cognitive-process so what is liked by one will not be liked by some
others. e.g i dont like Scheme, i prefer Lisp & it is purely a personal
choice.
I can give you an idea, rather 2 ideas:
IDEA 1: try these 2 sources to play around:
www.htdp.org & www.gigamonkeys.com/book
both are entirely different.
> Is there anything relevant to programming in the real world that Lisp
> is able to do that Scheme cannot, without significant effort and
> vice-versa?
IDEA 2: search comp.lang.lisp & comp.lang.scheme for posts of Kent
Pitman & Shriram. to know the design ideas of Lisp. that is what solved
my problem.
also see some of my posts.
> Please, I am not trying to start a flame war.
I know, i said the same.
> I know that there are differences between Scheme and Lisp in some areas
> and have done some reading up, but without extensive understanding and
> experience with either one or the other it is almost impossible to know
> if the differences impact on real world programming in any significant
> way as the languages seem to be almost identical in terms of their
> abilities.
see IDEA 2.
> Again I emphasize, I know this is an emotional issue with some people
> but it is not my intention at all to "stir the pot". My approach is -
> "what works best in the real world".
OK, "what works best in the real world": simple answer is Common Lisp
& i am not biased. spend some days with IDEA 2 & you will come to know.
now 2 pieces of advice:
ADVICE 1: feel free to ask questions here & also do one thing before
asking a question: search the archives of www.groups.google.com, i
guarntee that 98% of your problems will disappear.
ADVICE 2: If you want to become a good programmer. i mean not like the
one who does programming only for a living and nothing more. if you
want to live with your profession instead of merely using it as a tool
to earn money, then switch to Linux. you will save lots of time &
energy.
thanks.
"arnuld"
arnuld wrote:
> play around with both languages for some
> time & see where you fit.
Or you could forget about wasting time "playing around," and recognize
that the nuances of Scheme vs. Lisp are strategically unimportant.
What matters is the quality of your implementation, what you're willing
to pay for it, how easy it is to support if you go the open source
route, what size of community is attached to it, has anyone anywhere
done anything "proven" in your problem domain with it, and do you stand
a rat's chance in hell of making any money off your learning curve.
The flamewar stuff is cute, but it's the luxury of people with too much
time on their hands. As is "playing around" with different
implementations, seeing as how it takes so friggin' long to become
fully competent with any one of them.
I decided based on my own problem domain: Windows game development. As
far as "what you can get out there," there's nothing proven whatsoever
in either the Lisp or Scheme universe for this. So, I picked the best,
cheapest open source implementation available on Windows. Didn't see a
point in spending big $$$$ on unknown productivity enhancements for a
problem domain that perhaps nobody else cares about with any
seriousness. Coulda spent small $$$ on Corman Lisp, but it didn't look
so healthy a year ago. Looks better now, but I've already invested my
time into Chicken Scheme.
A tertiary consideration was the possibility of writing my own
language, starting from Chicken Scheme's BSD licensed code. The
implementation isn't that big, it's graspable by 1 person.
Anyways my advice is forget about playing around. Pick 1
implementation, either language, and stick with it until realize it's
clearly not fulfilling your needs.
Cheers,
Brandon Van Every
Brandon J. Van Every wrote:
> ... the nuances of Scheme vs. Lisp are strategically unimportant.
Seems to me that almost all those who make arguments like the above are
Scheme users. I suppose that makes sense, because almost all those who
think the differences ARE important use Common Lisp.
> Coulda spent small $$$ on Corman Lisp, but it didn't look
> so healthy a year ago. Looks better now, but I've already invested my
> time into Chicken Scheme.
As a Windows programmer, do you still use Windows 95? I mean after all
the time invested in it, why would you switch to Windows XP? (BTW, how
much time did you have to invest just to get Chicken to compile on
Windows?)
> Anyways my advice is forget about playing around. Pick 1
> implementation, either language, and stick with it until realize it's
> clearly not fulfilling your needs.
Sounds like a good plan to waste another 2 to 4 years (or more). Look
at how many Java programmers are still using it simply because they
just don't realize it's not fulfilling their needs.
John Stoneham wrote:
> Brandon J. Van Every wrote:
> > ... the nuances of Scheme vs. Lisp are strategically unimportant.
>
> Seems to me that almost all those who make arguments like the above are
> Scheme users. I suppose that makes sense, because almost all those who
> think the differences ARE important use Common Lisp.
>
> > Coulda spent small $$$ on Corman Lisp, but it didn't look
> > so healthy a year ago. Looks better now, but I've already invested my
> > time into Chicken Scheme.
>
> As a Windows programmer, do you still use Windows 95? I mean after all
> the time invested in it, why would you switch to Windows XP?
I never programmed for Windows 95. I was a Linuxer, and then I worked
on Windows NT 4.0. After that, Windows 98, and the reality is I didn't
do much programming in my more talkative Usenet years. By the time I
got seriously down to business, I was on Windows 2000. I still use it,
I have completely blown off the XP generation both in software and
hardware. My use of Windows APIs has been exceedingly minimal, almost
no investment at all. The only reason I persist on Windows is because
there's currently no other viable mass market platform for an indie
developer of modest means. Console devkits are expensive, and I
believe there are licensing problems as well if you want to ship a
title.
I'm certainly not going to "upgrade" my language implementation choice
every 3 years, as your analogy would seem to imply. I do not believe
in churn, whether Microsoft's churn or from other sources. I moved on
from C++ because it failed me, not because I thought it would be neato
kewl to do something new. It took me 2 years of checking languages out
to settle on Chicken Scheme. Not interested in switching gears until
it fails me.
> (BTW, how
> much time did you have to invest just to get Chicken to compile on
> Windows?)
9 months to get it to compile reliably. It already compiled, but it
would break on MSVC because it wasn't getting TLC, and MinGW was rather
unsupported. I expect it'll be another 3 months before others start
widely using my CMake build. Right now the real annoyance is mirroring
the behavior of the ./configure build, so that we can put them both in
1 distribution. That said, for my own purposes, I do have perfectly
viable builds today.
> > Anyways my advice is forget about playing around. Pick 1
> > implementation, either language, and stick with it until realize it's
> > clearly not fulfilling your needs.
>
> Sounds like a good plan to waste another 2 to 4 years (or more). Look
> at how many Java programmers are still using it simply because they
> just don't realize it's not fulfilling their needs.
Um, if they don't realize it's not fulfilling their needs, that's
probably because it *is* fulfilling their needs. You need to preach to
people who are hurting, not people who are trucking along just fine.
The only need that Chicken Scheme doesn't currently fulfil, is it
doesn't make me money. But in the Seattle area, I haven't seen any
evidence that Common Lisp will make me money either. So no point in
switching. I've also decided that I'm not leaving Seattle just so I
can do Lisp or Scheme. A career target would have to be much more
profound to uproot my friends, my dog, etc.
Cheers,
Brandon Van Every
On Sun, 20 Aug 2006 13:42:46 -0700, Brandon J. Van Every wrote:
>
> John Stoneham wrote:
>>
>> Sounds like a good plan to waste another 2 to 4 years (or more). Look
>> at how many Java programmers are still using it simply because they
>> just don't realize it's not fulfilling their needs.
>
> Um, if they don't realize it's not fulfilling their needs, that's
> probably because it *is* fulfilling their needs.
Um, no. If the whole 'Design Patterns' movement doesn't disprove this
statement, the existence of time wasting 'productivity enhancers' such as
Eclipse and Rational Rose do. How many billable hours have been bilked by
people playing with /those/ toys on company time?
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Chris Barts <··············@tznvy.pbz> writes:
> On Sun, 20 Aug 2006 13:42:46 -0700, Brandon J. Van Every wrote:
>
>>
>> John Stoneham wrote:
>>>
>>> Sounds like a good plan to waste another 2 to 4 years (or more). Look
>>> at how many Java programmers are still using it simply because they
>>> just don't realize it's not fulfilling their needs.
>>
>> Um, if they don't realize it's not fulfilling their needs, that's
>> probably because it *is* fulfilling their needs.
>
> Um, no. If the whole 'Design Patterns' movement doesn't disprove this
> statement, the existence of time wasting 'productivity enhancers' such as
> Eclipse and Rational Rose do. How many billable hours have been bilked by
> people playing with /those/ toys on company time?
But with these tools, you're producing something highly valuable,
since it's something the PHB can (start to believe they) understand:
documentation.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
Brandon J. Van Every wrote:
> John Stoneham wrote:
> > Brandon J. Van Every wrote:
> > Sounds like a good plan to waste another 2 to 4 years (or more). Look
> > at how many Java programmers are still using it simply because they
> > just don't realize it's not fulfilling their needs.
>
> Um, if they don't realize it's not fulfilling their needs, that's
> probably because it *is* fulfilling their needs. You need to preach to
> people who are hurting, not people who are trucking along just fine.
It depends on what your needs are. There are two important aspects to
this:
* Most people do not know that things can be improved on. I remember
one programmer telling me that he didn't mind which language he used
because he considered them all to be different syntax for the same
semantics. He had come to this view because he'd only programmed in
3rd gen languages and couldn't imagine things like higher-order
functions.
* Most programmers are not interested in becoming more productive. In
a large company high productivity is bad because it makes people
redundant. The art of running a department in a large company is to
realise that the number of employees you have signifies your
importance. It's not relevant how much work they are doing, so the
less efficiency the better, until you get caught of-course.
Rob Thorpe wrote:
> Brandon J. Van Every wrote:
> > John Stoneham wrote:
> > > Brandon J. Van Every wrote:
> > > Sounds like a good plan to waste another 2 to 4 years (or more). Look
> > > at how many Java programmers are still using it simply because they
> > > just don't realize it's not fulfilling their needs.
> >
> > Um, if they don't realize it's not fulfilling their needs, that's
> > probably because it *is* fulfilling their needs. You need to preach to
> > people who are hurting, not people who are trucking along just fine.
>
> It depends on what your needs are. There are two important aspects to
> this:
>
> * Most people do not know that things can be improved on. I remember
> one programmer telling me that he didn't mind which language he used
> because he considered them all to be different syntax for the same
> semantics. He had come to this view because he'd only programmed in
> 3rd gen languages and couldn't imagine things like higher-order
> functions.
> * Most programmers are not interested in becoming more productive. In
> a large company high productivity is bad because it makes people
> redundant. The art of running a department in a large company is to
> realise that the number of employees you have signifies your
> importance. It's not relevant how much work they are doing, so the
> less efficiency the better, until you get caught of-course.
The original point has segued into stuff that doesn't matter. Learning
either Lisp or Scheme *is* learning how to do *something* better than
C++, Java, or C#. It is a completely valid strategy to pick either 1
Lisp or 1 Scheme implementation and stick with it until proven broken.
Cheers,
Brandon Van Every
Brandon J. Van Every <···········@gmail.com> wrote:
+---------------
| I'm certainly not going to "upgrade" my language implementation choice
| every 3 years, as your analogy would seem to imply. I do not believe
| in churn, whether Microsoft's churn or from other sources.
+---------------
Interesting. That "churn" [plus the then-lack of a native compiler]
was a significant factor in my switch from PLT Scheme to Common Lisp
circa 2000. The PLT was cranking out new (and sometimes incompatible!)
versions faster than I could keep up! ;-} ;-}
+---------------
| It took me 2 years of checking languages out to settle on Chicken
| Scheme. Not interested in switching gears until it fails me.
+---------------
I stuck with PLT Scheme for ~8-10 years, then switched to Common Lisp[1]
and having been happily using it for the last 4-6 years. [There was a
fairly-long period of overlap/transition.] As you say, I'm not interested
in switching gears again unless/until CL fails me.
The positive attributes of long-term stability in one's tools are
often underrated...
-Rob
[1] CMUCL, to be precise, but most of what I do with CL is portable,
and I try to remember to mark the CMUCL-specific bits with #+(CMU),
so if I had to move to SBCL or one of the commercial implementations
the transition would be pretty easy. But to quote you again, I'm not
interested in switching gears unless/until CMUCL fails me.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
··············@gmail.com wrote:
> Brandon J. Van Every wrote:
>> ... the nuances of Scheme vs. Lisp are strategically unimportant.
> Seems to me that almost all those who make arguments like the above are
> Scheme users. I suppose that makes sense, because almost all those who
> think the differences ARE important use Common Lisp.
But it is not true. If TCO and general continuations are important,
the people use scheme.
Regards
Hermann
Hermann Jurksch wrote:
> But it is not true. If TCO and general continuations are important,
> the people use scheme.
>
Is there a Common Lisp implementation which doesn't optimize tail calls
today? I don't think so. I hardly see how this consideration could lead
someone to choose Scheme over Common Lisp as their Lisp-language of
choice.
As for you other stroll through academia halls, I'll call your
continuations and raise you a DEFPACKAGE, an ASSERT, and a DEFCLASS.
On Mon, 21 Aug 2006 23:47:56 +0200, John Stoneham
<··············@gmail.com> wrote:
> Hermann Jurksch wrote:
>> But it is not true. If TCO and general continuations are important,
>> the people use scheme.
>>
>
> Is there a Common Lisp implementation which doesn't optimize tail calls
> today? I don't think so. I hardly see how this consideration could lead
> someone to choose Scheme over Common Lisp as their Lisp-language of
> choice.
>
> As for you other stroll through academia halls, I'll call your
> continuations and raise you a DEFPACKAGE, an ASSERT, and a DEFCLASS.
>
It's not so much if it can but rather if it happens.
In general I belive tailcall optimation happens if debug < speed.
In scheme you always have tailcall optimation while in Lisp
you can turn it off.
Also the degree of support varies.
ACL can optimize tailcalls over multiple mutually recurive
functions while Corman can't for instance.
This behaviour is afterall NOT spesified in the standard.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
John Thingstad wrote:
> On Mon, 21 Aug 2006 23:47:56 +0200, John Stoneham
> <··············@gmail.com> wrote:
>
>> Hermann Jurksch wrote:
>>> But it is not true. If TCO and general continuations are important,
>>> the people use scheme.
>>>
>>
>> Is there a Common Lisp implementation which doesn't optimize tail calls
>> today? I don't think so. I hardly see how this consideration could lead
>> someone to choose Scheme over Common Lisp as their Lisp-language of
>> choice.
>>
>> As for you other stroll through academia halls, I'll call your
>> continuations and raise you a DEFPACKAGE, an ASSERT, and a DEFCLASS.
>>
>
> It's not so much if it can but rather if it happens.
> In general I belive tailcall optimation happens if debug < speed.
> In scheme you always have tailcall optimation while in Lisp
> you can turn it off.
In some Scheme implementations, you can also turn it off.
> Also the degree of support varies.
> ACL can optimize tailcalls over multiple mutually recurive
> functions while Corman can't for instance.
> This behaviour is afterall NOT spesified in the standard.
It's indeed the case that the value of Scheme's "proper" tail recursion
lies in the guarantee that it gives you. It basically states that all
tail calls, no matter what, don't grow the stack. The "no matter what"
bit is the important one. This is probably more important for generated
than for manually written code, but also enables a certain programming
style.
In almost all Common Lisp implementations, you can switch TCO on, but
you don't get the same level of guarantees. For example, in some loosely
performed tests, I had the impression that a (funcall ...) form in a
tail position isn't necessarily considered a tail call in some CL
implementations (or was it apply?), and that generic functions don't
necessarily respect TCO. I could have made mistakes in those tests,
though - I wasn't that much interested in the results...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> John Thingstad wrote:
>> Also the degree of support varies.
>> ACL can optimize tailcalls over multiple mutually recurive
>> functions while Corman can't for instance.
>> This behaviour is afterall NOT spesified in the standard.
>
[snip]
>
> In almost all Common Lisp implementations, you can switch TCO on, but
> you don't get the same level of guarantees. For example, in some loosely
> performed tests, I had the impression that a (funcall ...) form in a
> tail position isn't necessarily considered a tail call in some CL
> implementations (or was it apply?), and that generic functions don't
> necessarily respect TCO. I could have made mistakes in those tests,
> though - I wasn't that much interested in the results...
Why is it that CLs don't always do TCO; is it so much harder to
implement than it is for Scheme?
Lars wrote:
> Pascal Costanza wrote:
> > John Thingstad wrote:
> >> Also the degree of support varies.
> >> ACL can optimize tailcalls over multiple mutually recurive
> >> functions while Corman can't for instance.
> >> This behaviour is afterall NOT spesified in the standard.
> >
> [snip]
> >
> > In almost all Common Lisp implementations, you can switch TCO on, but
> > you don't get the same level of guarantees. For example, in some loosely
> > performed tests, I had the impression that a (funcall ...) form in a
> > tail position isn't necessarily considered a tail call in some CL
> > implementations (or was it apply?), and that generic functions don't
> > necessarily respect TCO. I could have made mistakes in those tests,
> > though - I wasn't that much interested in the results...
>
> Why is it that CLs don't always do TCO; is it so much harder to
> implement than it is for Scheme?
Generally Schemes are interpreters or compilers, no often both.
Generally CLs have both interpreters and compilers. Most CL compilers
implement TCO, many interpreters don't. AFAICK The thought is that the
interpreter is for prototyping so it's more important to make something
reliable and simple, so TCO can be left for the compiler and anyone who
uses recursion heavily can use that.
"Rob Thorpe" <·············@antenova.com> wrote/schrieb <························@i42g2000cwa.googlegroups.com>:
> Generally Schemes are interpreters or compilers, no often both.
Until now I had the impression that every compiling Scheme
implemetation has also an interpreter. Than "both" would be exactly as
often as "compiling". Can you tell me a counter-example (i.e. a
compiling Scheme implementation without an interpreter)?
Regards
Thomas
--
It's lucky you're going so slowly, because you're going in the wrong direction.
Thomas Hafner wrote:
> Until now I had the impression that every compiling Scheme
> implemetation has also an interpreter. Than "both" would be exactly as
> often as "compiling". Can you tell me a counter-example (i.e. a
> compiling Scheme implementation without an interpreter)?
Chez Scheme and both Larceny/Sparc and Larceny/IA32.
(Yes, there is a Larceny interpreter, and it is one of
the faster Scheme interpreters, but in the versions
of Larceny named above it is used only by eval and
by compiler developers. Everything you type into
the read/eval/print loop, and everything you load,
is compiled to machine code.)
Will
Thomas Hafner <······@hafner.NL.EU.ORG> writes:
> "Rob Thorpe" <·············@antenova.com> wrote/schrieb <························@i42g2000cwa.googlegroups.com>:
>
>> Generally Schemes are interpreters or compilers, no often both.
>
> Until now I had the impression that every compiling Scheme
> implemetation has also an interpreter. Than "both" would be exactly as
> often as "compiling". Can you tell me a counter-example (i.e. a
> compiling Scheme implementation without an interpreter)?
Well r5rs only has eval, but note that in the case of Common Lisp,
there's a COMPILE function, but no INTERPRET function (there's still
EVAL, but guess what it will do?)
(defun eval (form) (funcall (compile nil `(lambda () ,form))))
--
__Pascal Bourguignon__
······@hafner.NL.EU.ORG wrote:
> "Rob Thorpe" <·············@antenova.com> wrote/schrieb
> <························@i42g2000cwa.googlegroups.com>:
>> Generally Schemes are interpreters or compilers, no often both.
> Until now I had the impression that every compiling Scheme
> implemetation has also an interpreter. Than "both" would be exactly as
> often as "compiling". Can you tell me a counter-example (i.e. a
> compiling Scheme implementation without an interpreter)?
Stalin (if you want to call the accepted language scheme)
Regards
Hermann
Thomas Hafner wrote:
> "Rob Thorpe" <·············@antenova.com> wrote/schrieb <························@i42g2000cwa.googlegroups.com>:
>
> > Generally Schemes are interpreters or compilers, no often both.
>
> Until now I had the impression that every compiling Scheme
> implemetation has also an interpreter. Than "both" would be exactly as
> often as "compiling". Can you tell me a counter-example (i.e. a
> compiling Scheme implementation without an interpreter)?
I didn't make the point well, I should have said something like "not
often both joined together in the normal way".
Stalin is a pure compiler. Larceny and Chez don't interpret on x86 as
someone else mentioned. Mzscheme doesn't interpret by default anymore
it does JIT, but if you want to compile normally you use mzc which is
rather separate to mzscheme.
The fully joined up Scheme compilers (that behave like CL
implementations) I know of are Chicken, Bigloo and non-x86 Larceny. So,
there are only a few, all the others -be they compilers, JITs or
interpreters- must really support TCO in whatever evaluation method
they choose.
This "behave like CL" is important to the recursion question. You
can't for example in old mzscheme switch so easily between interpreted
and compiled code. This meant that TCO was useful in the interpreter.
Lars wrote:
> Pascal Costanza wrote:
>> John Thingstad wrote:
>>> Also the degree of support varies.
>>> ACL can optimize tailcalls over multiple mutually recurive
>>> functions while Corman can't for instance.
>>> This behaviour is afterall NOT spesified in the standard.
>>
> [snip]
>>
>> In almost all Common Lisp implementations, you can switch TCO on, but
>> you don't get the same level of guarantees. For example, in some
>> loosely performed tests, I had the impression that a (funcall ...)
>> form in a tail position isn't necessarily considered a tail call in
>> some CL implementations (or was it apply?), and that generic functions
>> don't necessarily respect TCO. I could have made mistakes in those
>> tests, though - I wasn't that much interested in the results...
>
> Why is it that CLs don't always do TCO; is it so much harder to
> implement than it is for Scheme?
IIUC it's also hard to implement for Scheme, but I am no expert on this.
(The hard part seems to be to recognize the tail positions.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Lars wrote:
>> Pascal Costanza wrote:
>>> John Thingstad wrote:
>>>> Also the degree of support varies.
>>>> ACL can optimize tailcalls over multiple mutually recurive
>>>> functions while Corman can't for instance.
>>>> This behaviour is afterall NOT spesified in the standard.
>>>
>> [snip]
>>>
>>> In almost all Common Lisp implementations, you can switch TCO on,
>>> but you don't get the same level of guarantees. For example, in
>>> some loosely performed tests, I had the impression that a (funcall
>>> ...) form in a tail position isn't necessarily considered a tail
>>> call in some CL implementations (or was it apply?), and that
>>> generic functions don't necessarily respect TCO. I could have made
>>> mistakes in those tests, though - I wasn't that much interested in
>>> the results...
>> Why is it that CLs don't always do TCO; is it so much harder to
>> implement than it is for Scheme?
>
> IIUC it's also hard to implement for Scheme, but I am no expert on
> this. (The hard part seems to be to recognize the tail positions.)
No, recognizing tail position is easy. What is hard is knowing how to
implement what Schemers want in the presence of special variables and
unwind-protects.
Let's revisit the terminology one more time. Schemers tend to call
their concept "proper tail recursion", and several years ago Will
Clinger and I had a discussion about that (if Scheme's treatment of
tail calls is "proper", does that make other languages' treatments of
tail calls "improper"?) and he and I agreed to call it "space
efficient" tail calls, which I believe he's been doing. But I still
see others calling it "proper tail recursion" or "tail call
optimization" , as above. The problems with these terminologies are:
- "Proper ..." is pejorative to other languages which have perectly
proper concepts or practices regarding tail calling.
- "... Optimization" is not necessarily an optimization - it depends
on what you're optimizing for: if you're optimizing for speed or code
space, it certainly isn't faster to perform a jump than to perform a
call instruction, and sometimes you must actually generate extra code
to remove the stack frame in order to perform this "optimization".
Finally, I call the change from a call to a jump that can occur when
conditions are right for a tail call a "tail merge" operation.
So what's the problem with specials? Well, if a call is in tail
position, but if specials have been bound within the calling function,
they must be unbound before the called function can return all the way
from the caller. Simple example:
(defun foo (x)
(let ((*print-base* 16))
(princ x)))
The call to princ must have *print-base* set to 16 during its
operation, but it must unbind *print-base* before returning.
Whether or not princ is in tail-position is perhaps controversial.
Some might argue that since there is still work to be done after the
call, it is not a tail call. I prefer to state that the call is in
tail position and is thus a tail-call, but that it is not easily
"merged". Note that this does not mean that it _cannot_ be merged; I
can see a scenario where an implementation allocates an extra stack
location for the number of specials that need to be unbound before
return - it is initialized to zero when the function allocates the
stack space. Then each tail merged call would add the number of
specials that are currently bound in the current caller to the count,
and when the actual return is done, it is performed by actually
jumping to an unbinding routine. Not very speed efficient, if you ask
me...
OK, so now what about unwind-protects? Uwps fly in the face of the
definition of tail call, because they specify something to be done
after performing functinality but before returning. And again, it is
a question of how much we are willing to "optimize away our speed" -
it is entirely possible to allow uwps to be pushed onto a list in the
current stack frame, and for the return from the function to make a
pass through the list of uwps that need executing before return. Such
a mechanism would also have to be coordinated with specials-unwinding,
and my gut tells me that it would be incredibly slow.
In conclusion, it is not a matter of recognizing tail calls, but it is
a matter of the direction of the optimization. Common Lisp is defined
in a way that a tail merge which would optimize for stack space might
in some circumstances cause great de-optimization for speed.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
>
> So what's the problem with specials? Well, if a call is in tail
> position, but if specials have been bound within the calling function,
> they must be unbound before the called function can return all the way
> from the caller. Simple example:
>
> (defun foo (x)
> (let ((*print-base* 16))
> (princ x)))
>
> The call to princ must have *print-base* set to 16 during its
> operation, but it must unbind *print-base* before returning.
>
> Whether or not princ is in tail-position is perhaps controversial.
> Some might argue that since there is still work to be done after the
> call, it is not a tail call. I prefer to state that the call is in
> tail position and is thus a tail-call, but that it is not easily
> "merged".
Both PLT Scheme and MIT Scheme have mechanisms for this sort of special
binding. In essence, the call is rewritten to explicitly restore the
old value upon return. Since the call is no longer in tail position, it
isn't a tail call. Neither PLT Scheme nor MIT Scheme consider this to
be a serious drawback.
You *could* however note that recursive special binding introduces the
`buried binding' problem. Each recursive call `buries' the previous
special binding. When you unwind the stack, you restore (exhume?) the
buried binding only to immediately discard it as you unwind the next
frame. If you arranged for buried bindings to be collected, then the
process would have the same asymptotic space usage as a tail-recursive
implemenation.
>
> OK, so now what about unwind-protects? Uwps fly in the face of the
> definition of tail call, because they specify something to be done
> after performing functinality but before returning. And again, it is
> a question of how much we are willing to "optimize away our speed" -
> it is entirely possible to allow uwps to be pushed onto a list in the
> current stack frame, and for the return from the function to make a
> pass through the list of uwps that need executing before return. Such
> a mechanism would also have to be coordinated with specials-unwinding,
> and my gut tells me that it would be incredibly slow.
Whether you push the unwind on the `real' stack or on a list of pending
unwinds is immaterial to the space usage. It will still be linear in
the number of pending unwinds, and not `safe for space' even in theory.
> In conclusion, it is not a matter of recognizing tail calls, but it is
> a matter of the direction of the optimization. Common Lisp is defined
> in a way that a tail merge which would optimize for stack space might
> in some circumstances cause great de-optimization for speed.
While this is true, the general expectation is that the particular
things you outlined here aren't going to be safe for space. One could
easily imagine a definition of tail recursion in Common Lisp that would
optimize for space in the `easy', expected cases and not optimize in
the `corner' cases that not even Scheme attempts to optimize.
Joe Marshall wrote:
> Duane Rettig wrote:
> >
> > So what's the problem with specials? Well, if a call is in tail
> > position, but if specials have been bound within the calling function,
> > they must be unbound before the called function can return all the way
> > from the caller. Simple example:
> >
> > (defun foo (x)
> > (let ((*print-base* 16))
> > (princ x)))
> >
> > The call to princ must have *print-base* set to 16 during its
> > operation, but it must unbind *print-base* before returning.
> >
> > Whether or not princ is in tail-position is perhaps controversial.
> > Some might argue that since there is still work to be done after the
> > call, it is not a tail call. I prefer to state that the call is in
> > tail position and is thus a tail-call, but that it is not easily
> > "merged".
>
> Both PLT Scheme and MIT Scheme have mechanisms for this sort of special
> binding. In essence, the call is rewritten to explicitly restore the
> old value upon return. Since the call is no longer in tail position, it
> isn't a tail call. Neither PLT Scheme nor MIT Scheme consider this to
> be a serious drawback.
This is incorrect in the case of PLT Scheme. Since PLT Scheme version
300, the body of a `parameterize' expression (the equivalent of special
binding that Joe is referring to) is in tail position with respect to
the entire expression. Thus the following program uses constant space
in PLT Scheme (assuming integers use constant space):
(let ([p (make-parameter 0)])
(let loop ()
(parameterize ([p (add1 (p))])
(loop))))
sam th
"samth" <······@gmail.com> writes:
> This is incorrect in the case of PLT Scheme. Since PLT Scheme
> version 300, the body of a `parameterize' expression (the equivalent
> of special binding that Joe is referring to) is in tail position
> with respect to the entire expression. Thus the following program
> uses constant space in PLT Scheme (assuming integers use constant
> space):
> [...]
You can even try it with GCable values to get convinced that the body
is really in a tail position (a point that Pascal raised in another
corner of this thread):
Welcome to MzScheme version 352, Copyright (c) 2004-2006 PLT Scheme Inc.
> (require (lib "foreign.ss"))
> (define counter
(let ((c 0))
(lambda ()
(set! c (+ 1 c))
(let ((l (list c c)))
(register-finalizer l (lambda (x) (printf "collecting ~s\n" x)))
l))))
> (define p (make-parameter (counter)))
> (let loop () (parameterize ([p (counter)]) (loop)))
collecting (118 118)
collecting (74 74)
collecting (16 16)
collecting (139 139)
[...]
^Cuser break
> (p)
(1 1)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
samth wrote:
> Joe Marshall wrote:
> > Duane Rettig wrote:
> > >
> > > So what's the problem with specials? Well, if a call is in tail
> > > position, but if specials have been bound within the calling function,
> > > they must be unbound before the called function can return all the way
> > > from the caller. Simple example:
> > >
> > > (defun foo (x)
> > > (let ((*print-base* 16))
> > > (princ x)))
> > >
> > > The call to princ must have *print-base* set to 16 during its
> > > operation, but it must unbind *print-base* before returning.
> > >
> > > Whether or not princ is in tail-position is perhaps controversial.
> > > Some might argue that since there is still work to be done after the
> > > call, it is not a tail call. I prefer to state that the call is in
> > > tail position and is thus a tail-call, but that it is not easily
> > > "merged".
> >
> > Both PLT Scheme and MIT Scheme have mechanisms for this sort of special
> > binding. In essence, the call is rewritten to explicitly restore the
> > old value upon return. Since the call is no longer in tail position, it
> > isn't a tail call. Neither PLT Scheme nor MIT Scheme consider this to
> > be a serious drawback.
>
> This is incorrect in the case of PLT Scheme. Since PLT Scheme version
> 300, the body of a `parameterize' expression (the equivalent of special
> binding that Joe is referring to) is in tail position with respect to
> the entire expression. Thus the following program uses constant space
> in PLT Scheme (assuming integers use constant space):
>
> (let ([p (make-parameter 0)])
> (let loop ()
> (parameterize ([p (add1 (p))])
> (loop))))
I stand corrected!
Duane Rettig wrote:
> Pascal Costanza <··@p-cos.net> writes:
>> Lars wrote:
>>> Why is it that CLs don't always do TCO; is it so much harder to
>>> implement than it is for Scheme?
>> IIUC it's also hard to implement for Scheme, but I am no expert on
>> this. (The hard part seems to be to recognize the tail positions.)
>
> No, recognizing tail position is easy. What is hard is knowing how to
> implement what Schemers want in the presence of special variables and
> unwind-protects.
>
[...]
>
> So what's the problem with specials? Well, if a call is in tail
> position, but if specials have been bound within the calling function,
> they must be unbound before the called function can return all the way
> from the caller. Simple example:
>
> (defun foo (x)
> (let ((*print-base* 16))
> (princ x)))
>
> The call to princ must have *print-base* set to 16 during its
> operation, but it must unbind *print-base* before returning.
>
> Whether or not princ is in tail-position is perhaps controversial.
> Some might argue that since there is still work to be done after the
> call, it is not a tail call. I prefer to state that the call is in
> tail position and is thus a tail-call, but that it is not easily
> "merged". Note that this does not mean that it _cannot_ be merged; I
> can see a scenario where an implementation allocates an extra stack
> location for the number of specials that need to be unbound before
> return - it is initialized to zero when the function allocates the
> stack space. Then each tail merged call would add the number of
> specials that are currently bound in the current caller to the count,
> and when the actual return is done, it is performed by actually
> jumping to an unbinding routine. Not very speed efficient, if you ask
> me...
>
So does this mean that every Scheme implementation has to do something
like this for calls to with-input-from-file and with-output-to-file?
IIUC, the thunks that are passed to them should be called as if in tail
position, right?
> OK, so now what about unwind-protects? Uwps fly in the face of the
> definition of tail call, because they specify something to be done
> after performing functinality but before returning. And again, it is
> a question of how much we are willing to "optimize away our speed" -
> it is entirely possible to allow uwps to be pushed onto a list in the
> current stack frame, and for the return from the function to make a
> pass through the list of uwps that need executing before return. Such
> a mechanism would also have to be coordinated with specials-unwinding,
> and my gut tells me that it would be incredibly slow.
IIUC, in Scheme dynamic-wind does not require its second argument to be
called as a tail call.
>
> In conclusion, it is not a matter of recognizing tail calls, but it is
> a matter of the direction of the optimization. Common Lisp is defined
> in a way that a tail merge which would optimize for stack space might
> in some circumstances cause great de-optimization for speed.
>
OK, thanks for the clarification.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Duane Rettig <·····@franz.com> writes:
> (defun foo (x)
> (let ((*print-base* 16))
> (princ x)))
>
> The call to princ must have *print-base* set to 16 during its
> operation, but it must unbind *print-base* before returning.
>
> Whether or not princ is in tail-position is perhaps controversial.
It is definitely not in a tail position. Therefore there is no
problem.
> OK, so now what about unwind-protects? Uwps fly in the face of the
> definition of tail call, because they specify something to be done
> after performing functinality but before returning. And again, it is
> a question of how much we are willing to "optimize away our speed" -
> it is entirely possible to allow uwps to be pushed onto a list in the
> current stack frame, and for the return from the function to make a
> pass through the list of uwps that need executing before return.
Again this is not a tail position. Constructing such a list has the
same asymptotic space complexity as a regular non-tail call, it makes
no sense to try to implement it differently.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Duane Rettig <·····@franz.com> writes:
>
>> (defun foo (x)
>> (let ((*print-base* 16))
>> (princ x)))
>>
>> The call to princ must have *print-base* set to 16 during its
>> operation, but it must unbind *print-base* before returning.
>>
>> Whether or not princ is in tail-position is perhaps controversial.
>
> It is definitely not in a tail position. Therefore there is no
> problem.
If you pass the dynamic environment around as an extra hidden argument
then the call is in a tail position.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Sean SCC wrote:
> Thanks to everyone who replied to my previous post!
>
> I am still trying to decide between Lisp and Scheme. Keeping in mind
> that I will be developing in Windows, and code speed is fairly
> important I have another question, which is:
>
> Is there anything relevant to programming in the real world that Lisp
> is able to do that Scheme cannot, without significant effort and
> vice-versa?
>
Lisp can change your mind about the world, scheme cannot.
W
Wade Humeniuk wrote:
> Sean SCC wrote:
> > Thanks to everyone who replied to my previous post!
> >
> > I am still trying to decide between Lisp and Scheme. Keeping in mind
> > that I will be developing in Windows, and code speed is fairly
> > important I have another question, which is:
> >
> > Is there anything relevant to programming in the real world that Lisp
> > is able to do that Scheme cannot, without significant effort and
> > vice-versa?
> >
>
> Lisp can change your mind about the world, scheme cannot.
>
> W
I don't agree with that. Scheme changed my mind about the world.
··············@gmail.com wrote:
> Wade Humeniuk wrote:
>> Sean SCC wrote:
>>> Thanks to everyone who replied to my previous post!
>>>
>>> I am still trying to decide between Lisp and Scheme. Keeping in mind
>>> that I will be developing in Windows, and code speed is fairly
>>> important I have another question, which is:
>>>
>>> Is there anything relevant to programming in the real world that Lisp
>>> is able to do that Scheme cannot, without significant effort and
>>> vice-versa?
>>>
>> Lisp can change your mind about the world, scheme cannot.
>>
>> W
> I don't agree with that. Scheme changed my mind about the world.
I think Wade's comment was more subtle than that.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
"Sean SCC" <···········@googlemail.com> writes:
> Thanks to everyone who replied to my previous post!
>
> I am still trying to decide between Lisp and Scheme. Keeping in mind
> that I will be developing in Windows, and code speed is fairly
> important I have another question, which is:
>
> Is there anything relevant to programming in the real world that Lisp
> is able to do that Scheme cannot, without significant effort and
> vice-versa?
>
> Please, I am not trying to start a flame war.
>
> I know that there are differences between Scheme and Lisp in some areas
> and have done some reading up, but without extensive understanding and
> experience with either one or the other it is almost impossible to know
> if the differences impact on real world programming in any significant
> way as the languages seem to be almost identical in terms of their
> abilities.
>
> Again I emphasize, I know this is an emotional issue with some people
> but it is not my intention at all to "stir the pot". My approach is -
> "what works best in the real world".
Indeed, it's totally dependant on the programmer. That's why you're
the only person able to answer that question. What language do you
prefer?
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Well on the face of it - I prefer Scheme - but only because it seems to
have the power of Common Lisp without the extra complexity. However the
fact that Scheme is a much smaller language makes me wonder - what
can't it do that Lisp can and if so, how significant is that ability?
Pascal Bourguignon wrote:
> "Sean SCC" <···········@googlemail.com> writes:
>
> > Thanks to everyone who replied to my previous post!
> >
> > I am still trying to decide between Lisp and Scheme. Keeping in mind
> > that I will be developing in Windows, and code speed is fairly
> > important I have another question, which is:
> >
> > Is there anything relevant to programming in the real world that Lisp
> > is able to do that Scheme cannot, without significant effort and
> > vice-versa?
> >
> > Please, I am not trying to start a flame war.
> >
> > I know that there are differences between Scheme and Lisp in some areas
> > and have done some reading up, but without extensive understanding and
> > experience with either one or the other it is almost impossible to know
> > if the differences impact on real world programming in any significant
> > way as the languages seem to be almost identical in terms of their
> > abilities.
> >
> > Again I emphasize, I know this is an emotional issue with some people
> > but it is not my intention at all to "stir the pot". My approach is -
> > "what works best in the real world".
>
> Indeed, it's totally dependant on the programmer. That's why you're
> the only person able to answer that question. What language do you
> prefer?
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> "Logiciels libres : nourris au code source sans farine animale."
Sean SCC wrote:
> Well on the face of it - I prefer Scheme - but only because it seems to
> have the power of Common Lisp without the extra complexity. However the
> fact that Scheme is a much smaller language makes me wonder - what
> can't it do that Lisp can and if so, how significant is that ability?
For a good comparison of Scheme and Common Lisp, see
http://makeashorterlink.com/?E2E9254F6
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Sean SCC wrote:
> Well on the face of it - I prefer Scheme - but only because it seems to
> have the power of Common Lisp without the extra complexity. However the
> fact that Scheme is a much smaller language makes me wonder - what
> can't it do that Lisp can and if so, how significant is that ability?
The real issue is that Common Lisp has a larger language standard.
However, there are a number of rich Scheme implementations, so the usual
approach in Scheme is to pick an implementation that has what you need,
and go with that. Scheme also has a large collection of
community-driven specifications in the form of SRFIs, and its standard
(RnRS) is under active development.
Anton
"Sean SCC" <···········@googlemail.com> writes:
>
> Well on the face of it - I prefer Scheme - but only because it seems
> to have the power of Common Lisp without the extra complexity. However
> the fact that Scheme is a much smaller language makes me wonder - what
> can't it do that Lisp can and if so, how significant is that ability?
Common Lisp & Scheme _can_ do the same things--but then, a Turing
machine _can_ do those things too. The difference is what is part of
the language itself, what comes out of the box with your implementation
and what you need to implement yourself.
The Scheme language itself is very small--famously fitting on a single
sheet of paper, IIRC. The downside is that it lacks a lot of useful
features: hash tables, structs, objects, exception handling, packages,
compilation, properties, access to the reader. Common Lisp defines
these things, so you know you can rely on them, that you won't need to
implement them and that they behave the same everywhere (or at least
that they vary only in certain ways). Common Lisp does not, so far as I
know, standardise lazy-evaluation primitives (but it's absolutely
trivial to roll your own); Scheme does. Scheme mandates tail-call
optimisation; CL doesn't, but most implementations do it anyway.
Neither language specifies such modern necessities as a Unix interface,
sockets, GUI toolkits, database interfaces and so forth.
However, the better Scheme implementations provide you with most
everything the Scheme standard lacks but the Common Lisp standard has
and more. Likewise, the better CL implementations provide you with most
everything the CL standard lacks but that you'll need. The major issue
is that because such things aren't standardised they tend to differ,
sometimes radically, between implementations. Common Lisp is far better
off than Scheme, but it is far, far worse off than other languages when
it comes to having reliable infrastructure to depend on.
I personally prefer Common Lisp, but there are some excellent Scheme
implementations out there, and folks have built great systems using
them. My experience with Scheme (which I learnt before CL) was that I
would ask, 'is there some library to do this?' and find that the answer
was 'no' or 'yes, but...' while with CL the answer is, 'yes,' and in
fact it's often built into the language.
Lastly, I much prefer CL's macro system to Scheme's, but that's very
much a matter of taste.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Anything worth shooting is worth shooting twice.
Ammunition is cheap; life is expensive.
--John Kwon
Sean SCC wrote:
> Thanks to everyone who replied to my previous post!
>
> I am still trying to decide between Lisp and Scheme. Keeping in mind
> that I will be developing in Windows, and code speed is fairly
> important I have another question, which is:
>
> Is there anything relevant to programming in the real world that Lisp
> is able to do that Scheme cannot, without significant effort and
> vice-versa?
No.
> Please, I am not trying to start a flame war.
>
> I know that there are differences between Scheme and Lisp in some areas
> and have done some reading up, but without extensive understanding and
> experience with either one or the other it is almost impossible to know
> if the differences impact on real world programming in any significant
> way as the languages seem to be almost identical in terms of their
> abilities.
>
> Again I emphasize, I know this is an emotional issue with some people
> but it is not my intention at all to "stir the pot". My approach is -
> "what works best in the real world".
Play around with both for some time, and see which one works better for you.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Sean SCC wrote:
>
>> Thanks to everyone who replied to my previous post!
>>
>> I am still trying to decide between Lisp and Scheme. Keeping in mind
>> that I will be developing in Windows, and code speed is fairly
>> important I have another question, which is:
>>
>> Is there anything relevant to programming in the real world that Lisp
>> is able to do that Scheme cannot, without significant effort and
>> vice-versa?
>
>
> No.
Are you mad? Or an academic? Scheme does not have objects, it does not
have usable macros, and it does not know that nil is false. They brag
about not having much of a spec, which translates to not having much of
a language. of course, it has a fine core so I can begin my application
project by first erecting a language like Common Lisp atop Scheme, but
then I have violated the "without significant effort" Prime Directive.
Excuse me if I just use Common Lisp and just get to work on my
application /this/ year.
Of course it is possible your answer was aimed at programmers who do not
want to write applications, which is why I offered the exemption for
academics.
:)
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Pascal Costanza wrote:
> > Sean SCC wrote:
> >>
> >> Is there anything relevant to programming in the real world that Lisp
> >> is able to do that Scheme cannot, without significant effort and
> >> vice-versa?
> >
> >
> > No.
>
> Ken Tilton wrote:
> > Are you mad? Or an academic? Scheme does not have objects,
Get it 3rd party. Chicken Scheme has a TinyCLOS egg, for instance.
> it does not have usable macros,
Considering the choices of macro systems available, your objection
lacks merit.
> and it does not know that nil is false.
And this sort of picky detail is worth hooting and hollering about?
Cheers,
Brandon Van Every
Ken Tilton wrote:
> Are you mad? Or an academic? Scheme does not have objects, it does not
> have usable macros, and it does not know that nil is false. They brag
> about not having much of a spec, which translates to not having much of
> a language. of course, it has a fine core so I can begin my application
> project by first erecting a language like Common Lisp atop Scheme
Good lord. Who would want to do that?
Anton
Anton van Straaten wrote:
> Ken Tilton wrote:
>
>> Are you mad? Or an academic? Scheme does not have objects, it does not
>> have usable macros, and it does not know that nil is false. They brag
>> about not having much of a spec, which translates to not having much
>> of a language. of course, it has a fine core so I can begin my
>> application project by first erecting a language like Common Lisp atop
>> Scheme
>
>
> Good lord. Who would want to do that?
Apparently you, since you are writing applications with Scheme. Or are
you doing without OO, macros, and LOOP because... Scheme does not have them?
:)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Apparently you, since you are writing applications with Scheme. Or are
> you doing without OO, macros, and LOOP because... Scheme does not have
> them?
>
> :)
>
Be nice, Ken. There are many fine object systems for scheme, and
it is perfectly reasonable to do OO programming even without using
any such library. Scheme has approximately the same LOOP macro as
CL, but everybody ignores it because tail recursion is so much
simpler and easier to use. And the standard specifies a perfectly
usable macro system, plus defmacro (with implicit captures) and
define-syntax (with explicit captures) are available natively in
most implementations and as portable code-walker preprocessing
libraries for all others.
Scheme's problem is not a poverty, but an "embarrasment of riches"
actually; there being so many different object systems, developing
a large project and reusing code from other projects usually means
modules written for incompatible object systems have to find
ways to (or be retrofitted to) coexist.
Bear
Ray Dillinger wrote:
> Ken Tilton wrote:
>
>>
>>
>> Apparently you, since you are writing applications with Scheme. Or are
>> you doing without OO, macros, and LOOP because... Scheme does not have
>> them?
>>
>> :)
>>
>
> Be nice, Ken.
Or less subtle. That was move one of mate in three.
> There are many fine object systems for scheme, and
> it is perfectly reasonable to do OO programming even without using
> any such library. Scheme has approximately the same LOOP macro as
> CL, but everybody ignores it because tail recursion is so much
> simpler and easier to use. And the standard specifies a perfectly
> usable macro system, plus defmacro (with implicit captures) and
> define-syntax (with explicit captures) are available natively in
> most implementations and as portable code-walker preprocessing
> libraries for all others.
Move two: I see, so forget all that Scheme bragging about having a tiny
spec? Use Scheme! Start building your own Common Lisp today!
>
> Scheme's problem is not a poverty, but an "embarrasment of riches"
> actually; there being so many different object systems, developing
> a large project and reusing code from other projects usually means
> modules written for incompatible object systems have to find
> ways to (or be retrofitted to) coexist.
Move three, thx. :)
kenneth
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
>
> Anton van Straaten wrote:
>
>> Ken Tilton wrote:
>>
>>> Are you mad? Or an academic? Scheme does not have objects, it does
>>> not have usable macros, and it does not know that nil is false. They
>>> brag about not having much of a spec, which translates to not having
>>> much of a language. of course, it has a fine core so I can begin my
>>> application project by first erecting a language like Common Lisp
>>> atop Scheme
>>
>>
>>
>> Good lord. Who would want to do that?
>
>
> Apparently you, since you are writing applications with Scheme. Or are
> you doing without OO, macros, and LOOP because... Scheme does not have
> them?
Apparently your notion of reuse stops with language standards. You
might want to look into the related notions of "language
implementations" and "libraries" sometime.
Of course, focusing on the larger standard is one of the few good
choices you have available to you in this debate, so naturally that's
what you have to do. I forgive you. ;oP
But it's ironic, since that standard has been a double-edged sword,
hasn't it? How did you say McCarthy and Baker put it... something about
"ending innovation"? Hopefully, the next version of the CL standard
will put that to rest, right?
Anton
Anton van Straaten wrote:
> Ken Tilton wrote:
>
>>
>>
>> Anton van Straaten wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>> Are you mad? Or an academic? Scheme does not have objects, it does
>>>> not have usable macros, and it does not know that nil is false. They
>>>> brag about not having much of a spec, which translates to not having
>>>> much of a language. of course, it has a fine core so I can begin my
>>>> application project by first erecting a language like Common Lisp
>>>> atop Scheme
>>>
>>>
>>>
>>>
>>> Good lord. Who would want to do that?
>>
>>
>>
>> Apparently you, since you are writing applications with Scheme. Or are
>> you doing without OO, macros, and LOOP because... Scheme does not have
>> them?
>
>
> Apparently your notion of reuse stops with language standards. You
> might want to look into the related notions of "language
> implementations" and "libraries" sometime.
Exactly. You Schemers run around bleating about your tiny little spec
and then sheepishly cobble together an ad hoc, un-standardized, home
brewed Common Lisp because you were wrong, an application developer
/does/ need a ball of insanely useful mud.
>
> Of course, focusing on the larger standard is one of the few good
> choices you have available to you in this debate,
Aside from Scheme getting macros, namespaces, and nil/false wrong, what
issues are there besides Scheme not having OO, etc?
>
> But it's ironic, since that standard has been a double-edged sword,
> hasn't it? How did you say McCarthy and Baker put it... something about
> "ending innovation"?
McCarthy does not write applicaticons either. The ILC organizers got
stars in their eyes and had all these Lisp dinosaurs (including an M$
suck-up) who had not written a Lisp LOC in a decade and made them the
closing speakers. Because the ILC organizers do not write applications
either. Those bozos and 99% of c.l.l are the last people on earth to be
promoting Lisp, because they are the enemy, viewing Lisp as some crown
jewel to be kept in a plexiglass case and carefully guarded from an
audience allowed to look but not install.
>... Hopefully, the next version of the CL standard
> will put that to rest, right?
What's wrong with this one? Too short?
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Exactly. You Schemers run around bleating about your tiny little spec
Is the old joke about how R5RS is the size of the CLTL index still
bothering you? But really, I don't think anyone seriously claims that
R5RS is much more than a core language specification.
> McCarthy does not write applicaticons either. The ILC organizers got
> stars in their eyes and had all these Lisp dinosaurs (including an M$
> suck-up) who had not written a Lisp LOC in a decade and made them the
> closing speakers. Because the ILC organizers do not write applications
> either. Those bozos and 99% of c.l.l are the last people on earth to be
> promoting Lisp because they are the enemy, viewing Lisp as some crown
> jewel to be kept in a plexiglass case and carefully guarded from an
> audience allowed to look but not install.
Somewhere in there there's an interesting discussion, about things like
how to keep language innovation alive in the presence of standardization
and commercial use. But it's probably too much to hope that we could
have that discussion here. Beer would be required...
>> ... Hopefully, the next version of the CL standard will put that to
>> rest, right?
>
>
> What's wrong with this one? Too short?
So you view the standard as some crown jewel to be kept in a plexiglass
case and carefully guarded, never to be updated?
Anton
Anton van Straaten wrote:
> Ken Tilton wrote:
>
>> Exactly. You Schemers run around bleating about your tiny little spec
>
>
> Is the old joke about how R5RS is the size of the CLTL index still
> bothering you?
There was a retraction? That is excellent news. URL, plz. :)
> But really, I don't think anyone seriously claims that
> R5RS is much more than a core language specification.
>
>> McCarthy does not write applicaticons either. The ILC organizers got
>> stars in their eyes and had all these Lisp dinosaurs (including an M$
>> suck-up) who had not written a Lisp LOC in a decade and made them the
>> closing speakers. Because the ILC organizers do not write applications
>> either. Those bozos and 99% of c.l.l are the last people on earth to
>> be promoting Lisp because they are the enemy, viewing Lisp as some crown
>> jewel to be kept in a plexiglass case and carefully guarded from an
>> audience allowed to look but not install.
>
>
> Somewhere in there there's an interesting discussion, about things like
> how to keep language innovation alive in the presence of standardization
> and commercial use.
Apparently "On Lisp" was not accidentally open to multiple
interpretations. ie, "how to" is not a problem when, unlike Scheme, one
has a usable macro system. Methinks Cells is a frighteningly good
example of the extensibility of Common Lisp, in that any compliant CL
can run the library, and in that Cells is not some distinct language
with CL as its interpreter, rather it swims in the CL sea, extending
vanilla CLOS gracefully and, at the other end, allowing one to write
rules in vanilla CL and somehow still get dependencies wired.
More briefly, i wold love to hear of a language innovation that could
not be implemented in ansi CL.
> But it's probably too much to hope that we could
> have that discussion here. Beer would be required...
There is never a need to justify beer.
>
>>> ... Hopefully, the next version of the CL standard will put that to
>>> rest, right?
>>
>>
>>
>> What's wrong with this one? Too short?
>
>
> So you view the standard as some crown jewel to be kept in a plexiglass
> case and carefully guarded, never to be updated?
You neglected to mention what was wrong with this one. Forgive me if I
hold off on reopening the standards process until there is a reason to
do so.
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Anton van Straaten wrote:
> > Ken Tilton wrote:
> More briefly, i wold love to hear of a language innovation that could
> not be implemented in ansi CL.
FFI
> > But it's probably too much to hope that we could
> > have that discussion here. Beer would be required...
>
> There is never a need to justify beer.
Indeed.
Rob Thorpe wrote:
> Ken Tilton wrote:
>
>>Anton van Straaten wrote:
>>
>>>Ken Tilton wrote:
>>
>>More briefly, i wold love to hear of a language innovation that could
>>not be implemented in ansi CL.
>
>
> FFI
That is a language innovation? You do know what the first "F" stands
for, don't you?
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
"Rob Thorpe" <·············@antenova.com> writes:
> Ken Tilton wrote:
>> Anton van Straaten wrote:
>> > Ken Tilton wrote:
>> More briefly, i wold love to hear of a language innovation that could
>> not be implemented in ansi CL.
>
> FFI
CFFI
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
Pascal Bourguignon wrote:
> "Rob Thorpe" <·············@antenova.com> writes:
>
> > Ken Tilton wrote:
> >> Anton van Straaten wrote:
> >> > Ken Tilton wrote:
> >> More briefly, i wold love to hear of a language innovation that could
> >> not be implemented in ansi CL.
> >
> > FFI
>
> CFFI
CFFI isn't ansi CL it depends on extensions on every Lisp on which it
works.
"Rob Thorpe" <·············@antenova.com> writes:
> Pascal Bourguignon wrote:
>> "Rob Thorpe" <·············@antenova.com> writes:
>>
>> > Ken Tilton wrote:
>> >> Anton van Straaten wrote:
>> >> > Ken Tilton wrote:
>> >> More briefly, i wold love to hear of a language innovation that could
>> >> not be implemented in ansi CL.
>> >
>> > FFI
>>
>> CFFI
>
> CFFI isn't ansi CL it depends on extensions on every Lisp on which it
> works.
I don't know whether I agree with Kenny's point in general, but this
is an example which strengthens it, not weakens it.
If all of the Lisps on which CFFI are built purport to conform to Ansi
CL, and if CFFI has been successfully been ported to all of these
Lisps, how can it possibly be said that it cannot be implemented on
ansi CL? The proof is in the existence of the implementation!
So you say that CFFI implemetations are built upon extensions -
well, ansi CL _allows_ extensions - they are not by definition
portable, but they are every bit in keeping with the spirit of the
ansi CL spec. Of course, some of these extensions may not keep with
the letter of the spec, because some of the extensions might be
nonconformant.
We have arguments going around about what constitutes a spec - is it
an implementation? A standard? Is is heavyweight, like Ansi CL? Or
is it lightweight, like a SRFI? Well, in CFFI we have an examle of a
specification, whether good or bad, which is in the form of an
implementation. It seeks to be inclusive, so although it can't be
instantaneously be thought of as portable, it does of course have the
potential to be portable (you never consider whether emacs is portable
or not in the face of new architectures; you only wait for or work on
the implementation to bring that new architecture out - the same
can/should be said for CFFI).
No, Ansi CL is set in stone, but its very nature makes it a living
standard; it gives implemetations _and_ communities the ability to
extend the definition and usage in ways that are relevant to CL users
today.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Rob Thorpe wrote:
> Pascal Bourguignon wrote:
>> "Rob Thorpe" <·············@antenova.com> writes:
>>
>>> Ken Tilton wrote:
>>>> Anton van Straaten wrote:
>>>>> Ken Tilton wrote:
>>>> More briefly, i wold love to hear of a language innovation that could
>>>> not be implemented in ansi CL.
>>> FFI
>> CFFI
>
> CFFI isn't ansi CL it depends on extensions on every Lisp on which it
> works.
There is surely a difference between implemented _in_ and implemented
_for_ ANSI Common Lisp. However, it is relatively straightforward to
implement such compatibility layers in Common Lisp, so the distinction
doesn't matter much in practice. The fact that Common Lisp is a
relatively large language already helps here. Especially the package
system and the de-facto-standard system definition facilities are very
valuable in this regard. The situation in Scheme will probably improve
here with R6RS because of the inclusion of a module system.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Rob Thorpe wrote:
> > Pascal Bourguignon wrote:
> >> "Rob Thorpe" <·············@antenova.com> writes:
> >>
> >>> Ken Tilton wrote:
> >>>> Anton van Straaten wrote:
> >>>>> Ken Tilton wrote:
> >>>> More briefly, i wold love to hear of a language innovation that could
> >>>> not be implemented in ansi CL.
> >>> FFI
> >> CFFI
> >
> > CFFI isn't ansi CL it depends on extensions on every Lisp on which it
> > works.
>
> There is surely a difference between implemented _in_
Yes, but the original question was what can be implemented in CL.
> and implemented
> _for_ ANSI Common Lisp. However, it is relatively straightforward to
> implement such compatibility layers in Common Lisp, so the distinction
> doesn't matter much in practice. The fact that Common Lisp is a
> relatively large language already helps here. Especially the package
> system and the de-facto-standard system definition facilities are very
> valuable in this regard. The situation in Scheme will probably improve
> here with R6RS because of the inclusion of a module system.
The situation in Scheme and CL with respect to this isn't really any
different. The implementation can extend the language however it likes
at some level invisible to the user then reveal that functionality in
more standard ways.
The compatability layers exist but that is not a good solution. Ken
already decried this approach in the context of Scheme, often people do
not trust libraries - I certainly distrust them to a certain extent.
Having defacto standards like CFFI isn't great either. It would be
much better to have at least informal standards and preferably formal
standards.
I think I'm preaching to the converted here though.
Rob Thorpe wrote:
> Pascal Costanza wrote:
>> Rob Thorpe wrote:
>>> Pascal Bourguignon wrote:
>>>> "Rob Thorpe" <·············@antenova.com> writes:
>>>>
>>>>> Ken Tilton wrote:
>>>>>> Anton van Straaten wrote:
>>>>>>> Ken Tilton wrote:
>>>>>> More briefly, i wold love to hear of a language innovation that could
>>>>>> not be implemented in ansi CL.
>>>>> FFI
>>>> CFFI
>>> CFFI isn't ansi CL it depends on extensions on every Lisp on which it
>>> works.
>> There is surely a difference between implemented _in_
>
> Yes, but the original question was what can be implemented in CL.
>
>> and implemented
>> _for_ ANSI Common Lisp. However, it is relatively straightforward to
>> implement such compatibility layers in Common Lisp, so the distinction
>> doesn't matter much in practice. The fact that Common Lisp is a
>> relatively large language already helps here. Especially the package
>> system and the de-facto-standard system definition facilities are very
>> valuable in this regard. The situation in Scheme will probably improve
>> here with R6RS because of the inclusion of a module system.
>
> The situation in Scheme and CL with respect to this isn't really any
> different. The implementation can extend the language however it likes
> at some level invisible to the user then reveal that functionality in
> more standard ways.
>
> The compatability layers exist but that is not a good solution. Ken
> already decried this approach in the context of Scheme, often people do
> not trust libraries - I certainly distrust them to a certain extent.
> Having defacto standards like CFFI isn't great either. It would be
> much better to have at least informal standards and preferably formal
> standards.
>
> I think I'm preaching to the converted here though.
I don't trust standards either, no matter whether formal or informal.
There are enough examples of bad standards out there.
I am not saying that standards don't have advantages. But they don't
guarantee any level of quality. To the contrary, standardized technology
is more often than not preferred over better technology, just because
the former is standardized. That's irrational.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Rob Thorpe wrote:
> > Pascal Costanza wrote:
> >> Rob Thorpe wrote:
> >>> Pascal Bourguignon wrote:
> >>>> "Rob Thorpe" <·············@antenova.com> writes:
> >>>>
> >>>>> Ken Tilton wrote:
> >>>>>> Anton van Straaten wrote:
> >>>>>>> Ken Tilton wrote:
> >>>>>> More briefly, i wold love to hear of a language innovation that could
> >>>>>> not be implemented in ansi CL.
> >>>>> FFI
> >>>> CFFI
> >>> CFFI isn't ansi CL it depends on extensions on every Lisp on which it
> >>> works.
> >> There is surely a difference between implemented _in_
> >
> > Yes, but the original question was what can be implemented in CL.
> >
> >> and implemented
> >> _for_ ANSI Common Lisp. However, it is relatively straightforward to
> >> implement such compatibility layers in Common Lisp, so the distinction
> >> doesn't matter much in practice. The fact that Common Lisp is a
> >> relatively large language already helps here. Especially the package
> >> system and the de-facto-standard system definition facilities are very
> >> valuable in this regard. The situation in Scheme will probably improve
> >> here with R6RS because of the inclusion of a module system.
> >
> > The situation in Scheme and CL with respect to this isn't really any
> > different. The implementation can extend the language however it likes
> > at some level invisible to the user then reveal that functionality in
> > more standard ways.
> >
> > The compatability layers exist but that is not a good solution. Ken
> > already decried this approach in the context of Scheme, often people do
> > not trust libraries - I certainly distrust them to a certain extent.
> > Having defacto standards like CFFI isn't great either. It would be
> > much better to have at least informal standards and preferably formal
> > standards.
> >
> > I think I'm preaching to the converted here though.
>
> I don't trust standards either, no matter whether formal or informal.
> There are enough examples of bad standards out there.
True, but in many cases a bad standard is better than no standard at
all. Chapters 5 & 6 of "Art of the Meta-object Protocol" for example
start by saying that they are not a standard. The existence of this
sub-standard standard is still far better than 7 independently cooked
up incompatible MOPs.
> I am not saying that standards don't have advantages. But they don't
> guarantee any level of quality. To the contrary, standardized technology
> is more often than not preferred over better technology, just because
> the former is standardized. That's irrational.
Not necessarily. Many people have been caught adopting good,
non-standard technology only to see the vendor of that product go out
of business or change business strategy. Standardisation is good if it
means that you get vendor neutrality and independence from unrelated
problems that a specific vendor suffers. It's worth taking quite a lot
of pain in exchange for this freedom.
Ken Tilton <·········@gmail.com> writes:
> More briefly, i wold love to hear of a language innovation that
> could not be implemented in ansi CL.
Threads.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Marcin 'Qrczak' Kowalczyk wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>
>>More briefly, i wold love to hear of a language innovation that
>>could not be implemented in ansi CL.
>
>
> Threads.
>
That's a library, you dork, not a language innovation. Try
"continuations" or something.
:)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Marcin 'Qrczak' Kowalczyk <······@knm.org.pl> writes:
> Ken Tilton <·········@gmail.com> writes:
>
>> More briefly, i wold love to hear of a language innovation that
>> could not be implemented in ansi CL.
>
> Threads.
Bordeaux-Threads.
--
__Pascal Bourguignon__ http://www.informatimago.com/
You're always typing.
Well, let's see you ignore my
sitting on your hands.
"Pascal Bourguignon" <···@informatimago.com> wrote:
> >> More briefly, i wold love to hear of a language innovation that
> >> could not be implemented in ansi CL.
> >
> > Threads.
>
> Bordeaux-Threads.
And it is implemented in _ANSI CL_, right ?
In fact, everything which requires a global transformation of a program
(threads, continuations, series, ...) cannot be implemented in a portable
way.
patro
"patro" <·····@ortap.com> writes:
> "Pascal Bourguignon" <···@informatimago.com> wrote:
>
>> >> More briefly, i wold love to hear of a language innovation that
>> >> could not be implemented in ansi CL.
>> >
>> > Threads.
>>
>> Bordeaux-Threads.
>
> And it is implemented in _ANSI CL_, right ?
>
> In fact, everything which requires a global transformation of a program
> (threads, continuations, series, ...) cannot be implemented in a portable
> way.
It can, metalinguistically.
But since they still want performance, these examples just show that:
- all (or mostly most) implementations have already these extensions anyways,
- it's possible to design a uniform interface to them.
Of course, it would be better if the implementations provided an
uniform interface in the first place, but this will come with a second
round of (de-facto) standardization.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon wrote:
> "patro" <·····@ortap.com> writes:
>
> > "Pascal Bourguignon" <···@informatimago.com> wrote:
> Of course, it would be better if the implementations provided an
> uniform interface in the first place, but this will come with a second
> round of (de-facto) standardization.
I think that's exactly the point this subthread is making. Role on the
second round of standardization!
Rob Thorpe wrote:
> Pascal Bourguignon wrote:
>
>>"patro" <·····@ortap.com> writes:
>>
>>
>>>"Pascal Bourguignon" <···@informatimago.com> wrote:
>>
>>Of course, it would be better if the implementations provided an
>>uniform interface in the first place, but this will come with a second
>>round of (de-facto) standardization.
>
>
> I think that's exactly the point this subthread is making. Role on the
> second round of standardization!
>
There is no need. You are looking for libraries, not language mods. CFFI
has become the standard /library/ for FFI. F as in "foreign" as in
"outside the language". Without changing CL. And with very little use of
implementation-specific stuff. Try to come up to speed on all this
before yammering any more about libraries.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> writes:
> Rob Thorpe wrote:
>> Pascal Bourguignon wrote:
>>
>>>"patro" <·····@ortap.com> writes:
>>>
>>>
>>>>"Pascal Bourguignon" <···@informatimago.com> wrote:
>>>
>>>Of course, it would be better if the implementations provided an
>>>uniform interface in the first place, but this will come with a second
>>>round of (de-facto) standardization.
>> I think that's exactly the point this subthread is making. Role on
>> the
>> second round of standardization!
>>
>
> There is no need. You are looking for libraries, not language
> mods. CFFI has become the standard /library/ for FFI. F as in
> "foreign" as in "outside the language". Without changing CL. And with
> very little use of implementation-specific stuff. Try to come up to
> speed on all this before yammering any more about libraries.
Of course. However, what I have in mind, for this class of
"libraries" that basically do:
#+implementation-2 (defun adapt (c) ...)
(defun library:do-something (a b c)
#+implementation-1(implem-specific:do-something b a c)
#+implementation-2(ab-ext-specific:something-todo a (adapt c) :b b)
#+implementation-3(system:doing-something a :r (list c b)) )
is that perhaps future versions of these incompatible implementations
will choose to implement directly the library API, in order to render
it as useless as a library named "common-lisp.lisp".
--
__Pascal Bourguignon__ http://www.informatimago.com/
Until real software engineering is developed, the next best practice
is to develop with a dynamic system that has extreme late binding in
all aspects. The first system to really do this in an important way
is Lisp. -- Alan Kay
Pascal Bourguignon wrote:
> Ken Tilton <·········@gmail.com> writes:
>
> > Rob Thorpe wrote:
> >> Pascal Bourguignon wrote:
> >>
> >>>"patro" <·····@ortap.com> writes:
> >>>
> >>>
> >>>>"Pascal Bourguignon" <···@informatimago.com> wrote:
> >>>
> >>>Of course, it would be better if the implementations provided an
> >>>uniform interface in the first place, but this will come with a second
> >>>round of (de-facto) standardization.
> >> I think that's exactly the point this subthread is making. Role on
> >> the
> >> second round of standardization!
> >>
> >
> > There is no need. You are looking for libraries, not language
> > mods. CFFI has become the standard /library/ for FFI. F as in
> > "foreign" as in "outside the language". Without changing CL. And with
> > very little use of implementation-specific stuff. Try to come up to
> > speed on all this before yammering any more about libraries.
>
> Of course. However, what I have in mind, for this class of
> "libraries" that basically do:
>
> #+implementation-2 (defun adapt (c) ...)
>
> (defun library:do-something (a b c)
> #+implementation-1(implem-specific:do-something b a c)
> #+implementation-2(ab-ext-specific:something-todo a (adapt c) :b b)
> #+implementation-3(system:doing-something a :r (list c b)) )
>
> is that perhaps future versions of these incompatible implementations
> will choose to implement directly the library API, in order to render
> it as useless as a library named "common-lisp.lisp".
Exactly, that would be very useful. Especially since it would bring
FFI under the remit of the implementation's regression tests. As it
is, if some FFI stopped working under some version of CL implementation
it may not be spotted.
"Pascal Bourguignon" <···@informatimago.com> wrote:
> >> Bordeaux-Threads.
> >
> > And it is implemented in _ANSI CL_, right ?
> >
> > In fact, everything which requires a global transformation of a program
> > (threads, continuations, series, ...) cannot be implemented in a
> > portable way.
>
> It can, metalinguistically.
No, it cannot. Just because the structure of an environment object has not
been standardized.
> But since they still want performance, these examples just show that:
I think, the real issue is not about the performance, but about the ability
of such transformed programs to be debugged.
patro
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Sean SCC wrote:
>>
>>> Thanks to everyone who replied to my previous post!
>>>
>>> I am still trying to decide between Lisp and Scheme. Keeping in mind
>>> that I will be developing in Windows, and code speed is fairly
>>> important I have another question, which is:
>>>
>>> Is there anything relevant to programming in the real world that Lisp
>>> is able to do that Scheme cannot, without significant effort and
>>> vice-versa?
>>
>>
>> No.
>
> Are you mad? Or an academic?
The latter.
> Scheme does not have objects, it does not
> have usable macros, and it does not know that nil is false. They brag
> about not having much of a spec, which translates to not having much of
> a language. of course, it has a fine core so I can begin my application
> project by first erecting a language like Common Lisp atop Scheme, but
> then I have violated the "without significant effort" Prime Directive.
>
> Excuse me if I just use Common Lisp and just get to work on my
> application /this/ year.
>
> Of course it is possible your answer was aimed at programmers who do not
> want to write applications, which is why I offered the exemption for
> academics.
There are several Scheme implementations that are similarly complete as
Common Lisp. If you don't care about portability across Scheme
implementations, then the situation is roughly the same as in Common Lisp.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Ken Tilton wrote:
> Pascal Costanza wrote:
> > Sean SCC wrote:
> >
> >> Thanks to everyone who replied to my previous post!
> >>
> >> I am still trying to decide between Lisp and Scheme. Keeping in mind
> >> that I will be developing in Windows, and code speed is fairly
> >> important I have another question, which is:
> >>
> >> Is there anything relevant to programming in the real world that Lisp
> >> is able to do that Scheme cannot, without significant effort and
> >> vice-versa?
> >
> >
> > No.
>
> Are you mad? Or an academic? Scheme does not have objects, it does not
> have usable macros, and it does not know that nil is false. They brag
> about not having much of a spec, which translates to not having much of
> a language. of course, it has a fine core so I can begin my application
> project by first erecting a language like Common Lisp atop Scheme, but
> then I have violated the "without significant effort" Prime Directive.
The world and his wife have written object systems, macro systems,
widget systems, io systems etc for Scheme. You get one or many of
these with almost every Scheme implementation. Full PLT Scheme is a
much larger language than CL for example.
The problem is all are different and none are standard. You have to
decide which you want to use, which means you have to pick an
implementations. This is evil in my opinion, since writing
implementation specific code put you at the mercy of the implementation
vendor.
The true trade-off between Scheme and CL are that if you pick Scheme
you get a clearer core language, but take the risk that your
implementation goes south. With CL you get a larger core language,
even if that core is not a work of art.
Rob Thorpe wrote:
> Ken Tilton wrote:
>
>>Pascal Costanza wrote:
>>
>>>Sean SCC wrote:
>>>
>>>
>>>>Thanks to everyone who replied to my previous post!
>>>>
>>>>I am still trying to decide between Lisp and Scheme. Keeping in mind
>>>>that I will be developing in Windows, and code speed is fairly
>>>>important I have another question, which is:
>>>>
>>>>Is there anything relevant to programming in the real world that Lisp
>>>>is able to do that Scheme cannot, without significant effort and
>>>>vice-versa?
>>>
>>>
>>>No.
>>
>>Are you mad? Or an academic? Scheme does not have objects, it does not
>>have usable macros, and it does not know that nil is false. They brag
>>about not having much of a spec, which translates to not having much of
>>a language. of course, it has a fine core so I can begin my application
>>project by first erecting a language like Common Lisp atop Scheme, but
>>then I have violated the "without significant effort" Prime Directive.
>
>
> The world and his wife have written object systems, macro systems,
> widget systems, io systems etc for Scheme.
Good trap, IIDSSM. I thought it was too obvious, but I was
overestimating you clowns.
:)
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Rob Thorpe wrote:
> The true trade-off between Scheme and CL are that if you pick Scheme
> you get a clearer core language, but take the risk that your
> implementation goes south.
This seems basically the same as the state of affairs with
Python or Perl, for example. Picking, say, PLT as one's Scheme
seems as safe as either of those. Safer, maybe, since at least
the core language semantics are specified.
> With CL you get a larger core language,
> even if that core is not a work of art.
OTOH it seems that practical things like threads and
GUI toolkits are as implementation-specific for CL as
for Scheme, so you're still at the implementor's mercy for
some fairly important functionality. At least, that's my
impression after looking around for Lisps and Schemes that
can replace Python for me on W32, Linux, and OSX. (I haven't
investigated commercial CLs -- no $$. So while I could try
an "evaluation" edition of Allegro or LispWorks, I'd hate it
if I loved it, 'cause I still couldn't afford it.)
-- JK
Joe Knapka wrote:
> OTOH it seems that practical things like threads and
> GUI toolkits are as implementation-specific for CL as
> for Scheme, so you're still at the implementor's mercy for
> some fairly important functionality.
For threads there exist compatibility layers, for example
bordeaux-threads. For GUIs, you can use for example LTK or use a web
browser as a front end.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Joe Knapka wrote:
>
>> OTOH it seems that practical things like threads and
>> GUI toolkits are as implementation-specific for CL as
>> for Scheme, so you're still at the implementor's mercy for
>> some fairly important functionality.
>
>
> For threads there exist compatibility layers, for example
> bordeaux-threads. For GUIs, you can use for example LTK or use a web
> browser as a front end.
I appreciate the response, and I'll check out bordeaux-threads.
But wrt to GUI stuff, I'm not entirely satisfied with those
options.
For highly dynamic stuff (eg games), using a web browser
is not so wonderful. I'd rather not have to write
Flash or Javascript in Lisp ('cause I'd have to go learn
those, for one thing). OTOH LTK is yet another wrapper
around Tk, and Tk is just... I don't know, kind of rustic,
by today's standards. Though it is better than nothing.
I saw a video recently of a demonstration of a multi-point
touch-screen GUI; the user can use all ten fingers to
grab, stretch, and juggle objects on the screen. It's
incredibly cool, and seems like exactly the kind of
interface that one would like to have an enormously
powerful Lisp app hidden behind (because it gives the
user powerful ways to interact with the system, not
because it would take a lot of power to implement; although
I guess it would, come to think of it). But I can't see it
happening with Tk. I nearly giggled when I wrote that,
in fact.
(The name of the guy doing the touchscreen demo was Jeff Han,
I think. The video's available on line somewhere.)
-- JK
On Mon, 21 Aug 2006 21:31:10 GMT, Joe Knapka <·········@kneuro.net>
wrote:
>I saw a video recently of a demonstration of a multi-point
>touch-screen GUI; the user can use all ten fingers to
>grab, stretch, and juggle objects on the screen. It's
>incredibly cool, and seems like exactly the kind of
>interface that one would like to have an enormously
>powerful Lisp app hidden behind (because it gives the
>user powerful ways to interact with the system, not
>because it would take a lot of power to implement; although
>I guess it would, come to think of it). But I can't see it
>happening with Tk.
http://mrl.nyu.edu/~jhan/ftirtouch/
It wouldn't really be any different from manipulating 10 mouse clicks.
FTIR touch screens simply have the ability to provide data for
multiple touch locations rather than just a single one. The neatest
thing about them is that they also measure Z-axis deflection ... so
now abusive kiosk programs can directly measure user frustration
levels by how hard the user pokes the screen ;)
George
--
for email reply remove "/" from address
George Neuner wrote:
> On Mon, 21 Aug 2006 21:31:10 GMT, Joe Knapka <·········@kneuro.net>
> wrote:
>
>
>>I saw a video recently of a demonstration of a multi-point
>>touch-screen GUI; the user can use all ten fingers to
>>grab, stretch, and juggle objects on the screen. It's
>>incredibly cool, and seems like exactly the kind of
>>interface that one would like to have an enormously
>>powerful Lisp app hidden behind (because it gives the
>>user powerful ways to interact with the system, not
>>because it would take a lot of power to implement; although
>>I guess it would, come to think of it). But I can't see it
>>happening with Tk.
>
>
> http://mrl.nyu.edu/~jhan/ftirtouch/
>
>
> It wouldn't really be any different from manipulating 10 mouse clicks.
From a programming perspective, you're right. From a
user-experience perspective, it seems quite different.
> FTIR touch screens simply have the ability to provide data for
> multiple touch locations rather than just a single one. The neatest
> thing about them is that they also measure Z-axis deflection ... so
> now abusive kiosk programs can directly measure user frustration
> levels by how hard the user pokes the screen ;)
(when (> (user-frustration-level) 75)
(invoke-eliza))
-- JK
Joe Knapka wrote:
> OTOH it seems that practical things like threads and
> GUI toolkits are as implementation-specific for CL as
> for Scheme, so you're still at the implementor's mercy for
> some fairly important functionality. At least, that's my
> impression after looking around for Lisps and Schemes that
> can replace Python for me on W32, Linux, and OSX. (I haven't
> investigated commercial CLs -- no $$. So while I could try
> an "evaluation" edition of Allegro or LispWorks, I'd hate it
> if I loved it, 'cause I still couldn't afford it.)
No, no! There is one GUI toolkit which runs on almost any known
Common Lisp :) (see link below)
Peter
--
Ltk, the easy lisp gui http://www.peter-herth.de/ltk/
I only get to play with the good languages during my hobby time, and
I've stuck to CL because I just love the feel of the language. Scheme
seems nice, too, but my heart's already taken.
It's always bothered me though that CL doesn't have continuations. From
my limited knowledge, that seems like the one deep concept Scheme has
that CL doesn't. And since Lisp for me is play time, I want access to
all the toys.
So some questions for the two camps, and especially those with a foot
in both camps:
1. How much do Schemers actually use continuations?
2. I believe there's at least one library that tries to provide
continuations in CL. How close is it to the "real thing"?
3. How hard is it to take some continuation-heavy Scheme code and port
it to CL? Is it usually straightforward to find a CL way to accomplish
the same things?
joh wrote:
> I only get to play with the good languages during my hobby time, and
> I've stuck to CL because I just love the feel of the language. Scheme
> seems nice, too, but my heart's already taken.
>
> It's always bothered me though that CL doesn't have continuations. From
> my limited knowledge, that seems like the one deep concept Scheme has
> that CL doesn't. And since Lisp for me is play time, I want access to
> all the toys.
"Toys", this is good, you already know your "need" for continuations is
idiotic.
>
> So some questions for the two camps, and especially those with a foot
> in both camps:
>
> 1. How much do Schemers actually use continuations?
I would have asked that question first. <hint>
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> > 1. How much do Schemers actually use continuations?
> I would have asked that question first. <hint>
Heh.
(a) I seem to recall (i.e., can't remember well enough to
give a cite) some small implementations for embedded
systems that use continuations for coroutines. Probably
there are other cases where they have been used for
coroutines. Generally, coroutines don't need the full
power of continuations and this technique for implementing
them works nicely iff continuations happen to be fast
in your particular implementation. Continuations tend to
be relatively fast in your implementation only if your
implementation is either very complicated or not a real
speed daemon.
(b) These days (cites are very easy to find) some people use
them for web programming. This is an interesting case
because, unlike coroutines, this does use the full power
of continuations. I think it is safe to say that
the jury has not yet returned a verdict on whether or not
this is a good technique for web programming -- there
are dissenting voices and it does seem, at least to
me, a dubious approach.
(c) Boy, continuations sure are handy for writing some
kinds of search (which is well known). A lot of programs
can be well expressed in terms of search. In some cases,
the use of continuations in search is just for coroutines.
In other cases (think prolog-ish, for example) it is handy
to have some calls return multiple times.
(d) One *can* use continuations to implement exception
handling mechanisms (which is again, well known).
But, if continuations are not cheap in your implemenation
(which is a common case) you will probably want to
choose a different technique.
Aside from the complexity of implementing continuations well,
especially on stock hardware, especially when mixing with C,
continuations have at least one major problem from a language
design perspective: they interact very poorly with modularity.
They are not worth, in my opinion, building into a general
purpose language.
If I write a Scheme library and that library makes a call to some
other module, what is the Right Thing to do? My choices are
to make sure my code behaves reasonably if that call returns
more than once, or simply to document somewhere that my
code doesn't behave reasonably in that case and hope others
heed the warning. Neither is a great option.
I think the best of both worlds is achieved by making continuation
support optional and explicitly confining it to certain regions of the
call graph. In other words:
Suppose I want to write a search algorithm that uses
continuations. All of the continuation captures and calls
will be entirely within code within this one module. Fully
general continuations are not needed. So: either write the
search functions in explicit continuation passing style or
automatically translate them to that style. The top-level
entry point to search may be called with a continuation that
can't or won't be captured but, internally, my search functions
will have access to call/cc or a moral equivalent.
If we accept that that is the only way we would ever want
to use continuations then there is no need for call/cc in the
language -- just closures and tail calls. In other words,
not every procedure application needs to involve a
potentially capturable continuation.
Of course, given just closures and tail calls, RnRS can be
implemented as a sub-language Within routines written
entirely in that sub-language call/cc will work as specified
but calls into them, from the host language, will involve
uncapturable continuations.
Sometimes people argue that continuations belong in
Scheme because continuations are a single, general
construct in terms of which coroutines, exception handling,
and search (and more!) can all be expressed. That
is a false generalization because the presence of first
class continuations implies *all* local variables (other
than in known "leaf procedures") are captured in
potentially upwards-escaping closures. Neither threads
or exception handling has the property. Search has
that property internally but not with respect to the locals
of callers. Continuations are not a simpler, more general
construct out of which coroutines, exception handlers, etc
may be built. On the contrary, continuations are a
more complicated, more expensive construct the restricted
use of which happens to reduce to something semantically
isomorphic to coroutines, exception handlers, etc.
-t
"Tom Lord" <····@emf.net> wrote/schrieb <························@p79g2000cwp.googlegroups.com>:
> If we accept that that is the only way we would ever want
> to use continuations then there is no need for call/cc in the
> language -- just closures and tail calls.
Does "tail calls" mean that tail call elimination is mandatory? Ok,
fine and enough for me, even if that encourages to write in CPS. In
case that a function should return mutiple values, I often find CPS
source code nicer than the corresponding Scheme source code using
call/cc, values and call-with-values.
Regards
Thomas
Ken Tilton wrote:
> "Toys", this is good, you already know your "need" for continuations is
> idiotic.
Mmmhmmm. Just like C programmers think the need for garbage collection
is idiotic.
Bear
Ray Dillinger wrote:
> Ken Tilton wrote:
>
>> "Toys", this is good, you already know your "need" for continuations
>> is idiotic.
>
>
> Mmmhmmm. Just like C programmers think the need for garbage collection
> is idiotic.
Argument from analogy! I love these. they are just like... seedless grapes?
Look, without even meaning to I implemented breadth-first search
requiring persistent state in my current application project, just as
the continuations thing was breaking out again here on c.l.l. I had to
laugh. A humble application programmer does continuations just by
working on his application!
Face it, a continuation is just a cute trick for managing state, such
that one need not think about it because it is all on the stack. I
concede the trick -- hey, no need to think out what state to preserve,
but then the counterpoint is, well, when I accidentally did my faux
continuations i did not have to think out the state because the
requisite data structures were already in place for other reasons.
Getting back you your analogy... uh, why not talk about continuations?
Not defensible on their own? trying to hitch the continuations wagon to
the GC wagon? Excellent tactic. :)
kenneth
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton <·········@gmail.com> wrote:
+---------------
| Face it, a continuation is just a cute trick for managing state, such
| that one need not think about it because it is all on the stack. I
| concede the trick -- hey, no need to think out what state to preserve,
| but then the counterpoint is, well, when I accidentally did my faux
| continuations i did not have to think out the state because the
| requisite data structures were already in place for other reasons.
+---------------
And this is also exactly why "real" [in the Scheme sense] continuations
are not what you need [or maybe even want!] in web programming, either.
Yes, in the *very simplest* cases using "real" continuations lets you
blindly ignore what state you want to save [with all the potential
problems that implies!], but in practice with complex sites you have
so much other state you have to manage explicitly anyway [including such
things as aging (timeouts) and GC-ing SQL connections, "sessions", etc.]
that using "real" continuations just gets in the way, e.g.:
http://www.ccs.neu.edu/scheme/pubs/ase2001-gfkf.pdf
...
Several months of actual experience using the server for an
outreach project's Web sites [ref] revealed that problems with
timeouts matter in practice.
As you say, in practice "the requisite data structures [are usually]
already in place for other reasons", so emulating the user-visible
*behavior* of continuations [which is what I'm understanding your
"faux continuations" are doing] is all you really need to do. Plus,
if you want to store *lots* of continuations, then you need to be
able to externalize them [in a database or something], in which case
your "faux continuations" (what some people call "manually CPS'd" code)
are much easier to handle.
Don't get me wrong: I still think the "web continuations" *model*
is a great way to think about the user/server interactions -- it
"does the right thing" when a user has multiple browser windows
open to the same site [unlike cookies, which lose big in that case!]
and when the user likes the "Back" and "Open in New Window/Tab" buttons.
I want to thank Queinnec, Felleisen, Krishnamurthy, and various others
who have written so eloquently on the subject. But just because "web
continuations" are a good model for *designing* the navigation and
interactions doesn't mean that "real" continuations are actually the
right way to *implement* the site. These days, I happend to think
they aren't. But then, I code my sites in Common Lisp, so I *have*
to think that way, right? ;-}
But seriously, folks, there's usually a *lot* of DBMS & "business
logic" & HTML-generating code between desired continuation points,
so manually CPS-transforming your code [and then tagging each procedure
with an externalizable marker] isn't a great strain, at least, not
in my experience.
-Rob
p.s. As I posted here a couple of weeks ago, I do use a
BUILD-CONTINUATION function all over the place in HTML
form-generating code, that simply sets one or more hidden
form variables (one of them almost always named "state"!).
See <·········································@speakeasy.net>
for a small code example.
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Ken Tilton <·········@gmail.com> wrote:
> +---------------
> | Face it, a continuation is just a cute trick for managing state, such
> | that one need not think about it because it is all on the stack. I
> | concede the trick -- hey, no need to think out what state to preserve,
> | but then the counterpoint is, well, when I accidentally did my faux
> | continuations i did not have to think out the state because the
> | requisite data structures were already in place for other reasons.
> +---------------
>
> And this is also exactly why "real" [in the Scheme sense] continuations
> are not what you need [or maybe even want!] in web programming, either.
Ah, I forgot to mention that we were still waiting for a report from the
LispVan* shoot-out in which Certified Web God Marc Battyani was going to
try stamping out once and forever the "Web & Continuations Perfect
Together" myth.
Ah, why wait?:
>
> Yes, in the *very simplest* cases using "real" continuations lets you
> blindly ignore what state you want to save [with all the potential
> problems that implies!], but in practice with complex sites you have
> so much other state you have to manage explicitly anyway [including such
> things as aging (timeouts) and GC-ing SQL connections, "sessions", etc.]
Oh, yeah, there is a recipe for software success, half the state on the
stack, half in data structures, and ne'er the twain world views can be
known to be consistent.
Continuations certainly are clever, but if we learned anything from the
rejection of the cover art for "Smell the Glove", it is that "there is a
fine line between stupid... and clever".
> that using "real" continuations just gets in the way, e.g.:
>
> http://www.ccs.neu.edu/scheme/pubs/ase2001-gfkf.pdf
> ...
> Several months of actual experience using the server for an
> outreach project's Web sites [ref] revealed that problems with
> timeouts matter in practice.
>
> As you say, in practice "the requisite data structures [are usually]
> already in place for other reasons", so emulating the user-visible
> *behavior* of continuations [which is what I'm understanding your
> "faux continuations" are doing] is all you really need to do. Plus,
> if you want to store *lots* of continuations, then you need to be
> able to externalize them [in a database or something], in which case
> your "faux continuations" (what some people call "manually CPS'd" code)
> are much easier to handle.
>
> Don't get me wrong: I still think the "web continuations" *model*
> is a great way to think about the user/server interactions -- it
> "does the right thing" when a user has multiple browser windows
> open to the same site [unlike cookies, which lose big in that case!]
> and when the user likes the "Back" and "Open in New Window/Tab" buttons.
> I want to thank Queinnec, Felleisen, Krishnamurthy, and various others
> who have written so eloquently on the subject. But just because "web
> continuations" are a good model for *designing* the navigation and
> interactions doesn't mean that "real" continuations are actually the
> right way to *implement* the site. These days, I happend to think
> they aren't. But then, I code my sites in Common Lisp, so I *have*
> to think that way, right? ;-}
Yes, we may be making a virtue of necessity, but I do not think so.
Another objection to continuations (I am guessing) is that the stack can
contain pointers to mutable structures. Or does Scheme do a deep copy of
any Scheme object when a continuation is built? If not, is there not the
possibility of a, well, non-continuing continuation?
I have seen this a million times in software development. Some clever
programmer hits on a cute trick, falls in love with it, and then as the
issues roll in just keeps hacking and hacking as needed to preserve the
cute trick. All the code around the trick has to contort itself to
preserve the cute trick. I totally expected this to happen with Cells,
btw, and was surprised when it did not.
>
> But seriously, folks, there's usually a *lot* of DBMS & "business
> logic" & HTML-generating code between desired continuation points,
> so manually CPS-transforming your code [and then tagging each procedure
> with an externalizable marker] isn't a great strain, at least, not
> in my experience.
>
>
> -Rob
>
> p.s. As I posted here a couple of weeks ago, I do use a
> BUILD-CONTINUATION function all over the place in HTML
> form-generating code, that simply sets one or more hidden
> form variables (one of them almost always named "state"!).
There ya go.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> I have seen this a million times in software development. Some clever
> programmer hits on a cute trick, falls in love with it, and then as the
> issues roll in just keeps hacking and hacking as needed to preserve the
> cute trick. All the code around the trick has to contort itself to
> preserve the cute trick. I totally expected this to happen with Cells,
> btw, and was surprised when it did not.
This is the history of life. Isn't it true that computers themselves
are cute tricks? What are you doing reading and writing to these
newsgroups? Aren't you "keeping hacking and hacking as needed to
preserve the cute trick" which represent Lisp, and... Cells? ;-)
Javier wrote:
> Ken Tilton wrote:
>
>>I have seen this a million times in software development. Some clever
>>programmer hits on a cute trick, falls in love with it, and then as the
>>issues roll in just keeps hacking and hacking as needed to preserve the
>>cute trick. All the code around the trick has to contort itself to
>>preserve the cute trick. I totally expected this to happen with Cells,
>>btw, and was surprised when it did not.
>
>
> This is the history of life. Isn't it true that computers themselves
> are cute tricks? What are you doing reading and writing to these
> newsgroups? Aren't you "keeping hacking and hacking as needed to
> preserve the cute trick" which represent Lisp, and... Cells? ;-)
>
Cells generally gets smaller and more lucid when I enhance it. The data
integrity scheme complicated everything, but then it was bringing in
something new. That's allowed, because it is simple itself.
I meant what I said and said what I meant. Not only am I not hacking and
hacking at cute tricks, I have learned that that is Occam's Code Razor:
no matter how cute something seems at first, one or two hiccups and out
it goes (good stuff stuff never hiccups).
In case that is still not clear: ease of use is exactly how I judge my
own code design. (Productivity is what motivates it.)
As you can imagine, it is nice working with a code base built that way.
It is not nice working with OpenGL, to which I return now...
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
[...]
Ken, it is usually better to only worry about our own preferences, and
find people with the same ones, than having to worry all the time about
how everybody out there is thinking. It might be nice to do it
sometimes... but doing it all the time is in the edge of paranoic.
Scheme continuations is a respetable thing, the same as your Cell
system is. It hasn't got any sense to enter into fights for everything
we don't like... not even for that horrible OpenGL API... :)
Javier wrote:
> Ken Tilton wrote:
> [...]
>
> Ken, it is usually better to only worry about our own preferences, and
> find people with the same ones, than having to worry all the time about
> how everybody out there is thinking.
You are aware that this is Usenet? We are here to exchange ideas, and if
I am not mistaken that may lead at some point to consideration of how
everybody out there is thinking.
> It might be nice to do it
> sometimes... but doing it all the time is in the edge of paranoic.
Why do you want to change from a discussion of the technical
justification for continuations to this personal/human/emotional... oh,
of course.
> Scheme continuations is a respetable thing, the same as your Cell
> system is.
Ah, it's "shiny happy faces" time? This is to avoid further discussion
on the merits?
But you are confused. Continuations are fine. The question is, is it a
big deal whether a language supports them? If they are, in fact, a
pointless clever hack, then no. If their defenders can sell us on some
profound programming purpose, then yes.
This is of special interest to because the port of Croma from CL to C
was motivated by a desire to support continuations. So, sorry, shiny
happy faces won't cut it. The issue has serious implications.
> It hasn't got any sense to enter into fights for everything
> we don't like...
Fights? You mean the kind of thing you and Bear are trying to start by
getting personal?
I made a simple point. Continuations do nothing but let me preserve
state without thinking much about it. No argument, I guess. I made a
followup point. I have data structures anyway. So do you, I guess. What
I did not say was, "You want me to think about what state defines this
computation?! Can we go shopping?" ie, Even if someone did not already
have for other reasons sufficient data structures to resume a
computation, um, they should work that out. Might do them some good.
I look forward to any technical, merits-oriented continuation of this
thread.
:)
kenneth
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Rob Warnock wrote:
> Don't get me wrong: I still think the "web continuations" *model*
> is a great way to think about the user/server interactions -- it
> "does the right thing" when a user has multiple browser windows
> open to the same site [unlike cookies, which lose big in that case!]
> and when the user likes the "Back" and "Open in New Window/Tab" buttons.
> I want to thank Queinnec, Felleisen, Krishnamurthy, and various others
> who have written so eloquently on the subject. But just because "web
> continuations" are a good model for *designing* the navigation and
> interactions doesn't mean that "real" continuations are actually the
> right way to *implement* the site.
You're right about the model being good, but beyond that, there's a big
red flag in the above claim. It suggests that having developed a model
based on continuations, the only way to effectively implement that model
is to manually map it onto an implementation in which (some of) the
continuations have been made explicit.
But what makes you think that this mapping can't be automated? We
should be careful to distinguish between the limitations of R5RS
Scheme's particular definition of first-class continuations, vs. the
general possibilities in this area.
Scheme implementations, in conjunction with theoretical work, have been
addressing these issues very successfully. For example, SISC and Gambit
support serializable continuations, and Scheme48 provides native support
for delimited continuations. These two natural extensions of Scheme's
continuations address many, perhaps most, of the concerns which people
raise against first-class continuations.
Coming back to the question of mapping from a continuation-based model
to an implementation, we shouldn't forget that we have tools which are
capable of transforming code written in one style into code written in
another style. They're called "compilers". It's perfectly possible to
automatically transform code written with implicit continuations into
code which makes the continuations explicit in data stored on web pages,
for example. To do this, all that is required is the well-known and
easy-to-implement CPS transformation. This ends up being equivalent to
having support for serializable, first-class continuations, but it
provides a different way to think about it, which can be helpful.
Anton
There have been almost no defenses of continuations at
the language level in this thread. Isn't this different from,
say, 5 or 10 years ago? Perhaps it is about time to
drop them from Scheme?
Closest thing to a defense may be:
Anton van Straaten wrote:
> But what makes you think that this mapping can't be automated? We
> should be careful to distinguish between the limitations of R5RS
> Scheme's particular definition of first-class continuations, vs. the
> general possibilities in this area.
Ok.
> Scheme implementations, in conjunction with theoretical work, have been
> addressing these issues very successfully. For example, SISC and Gambit
> support serializable continuations, and Scheme48 provides native support
> for delimited continuations. These two natural extensions of Scheme's
> continuations address many, perhaps most, of the concerns which people
> raise against first-class continuations.
Isn't it the case that call/cc can be implemented in terms of
delimited continuations and vice versa? I gather that this
was briefly in doubt for a time but is no longer.
I don't see how the act of describing the idea of delimited
continuations changes anything.
While serializability may make this or that program slightly simpler,
I am not aware of any concerns about continuations that are actually
resolved by that. The potential externalizability of some
continuations
was never in doubt, was it?
Rather than these (supposedly) "natural extensions ... [addressing]
many, perhaps most, of the concerns ...." I don't see how they
address *any* of the concerns.
-t
Tom Lord wrote:
> There have been almost no defenses of continuations at
> the language level in this thread. Isn't this different from,
> say, 5 or 10 years ago? Perhaps it is about time to
> drop them from Scheme?
"other languages moving towards Common Lisp" in extremis?
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Tom Lord wrote:
> There have been almost no defenses of continuations at
> the language level in this thread. Isn't this different from,
> say, 5 or 10 years ago? Perhaps it is about time to
> drop them from Scheme?
I didn't bother to defend them because it's not necessary. First-class
continuations have demonstrated their usefulness over and over, in the
web context and elsewhere. The only factually supportable criticisms
that have been raised boil down to "but they're not perfect for every
situation". I agree with that observation, but for me it argues for
expanding support for continuations, not eliminating it.
Call/cc can be thought of as a high-level tool that supports language
design. Not everyone wants to do language design, so it's a specialized
tool that not everyone has a direct need for. Aside from its use to
theoreticians, it's most likely to be useful to developers of embedded
languages, frameworks, and similar tools. See Kanren for a nice example
of where it's useful.
For people who don't have such requirements, there's not usually much
point trying to justify continuations to them, unless they genuinely
want to learn about them.
>>Scheme implementations, in conjunction with theoretical work, have been
>>addressing these issues very successfully. For example, SISC and Gambit
>>support serializable continuations, and Scheme48 provides native support
>>for delimited continuations. These two natural extensions of Scheme's
>>continuations address many, perhaps most, of the concerns which people
>>raise against first-class continuations.
>
>
> Isn't it the case that call/cc can be implemented in terms of
> delimited continuations and vice versa? I gather that this
> was briefly in doubt for a time but is no longer.
Implementing a delimited continuation in terms of call/cc buys you the
desired behavior, but when you serialize such a continuation, unless the
delimited functionality is supported natively, you won't just get the
delimited part of the continuation. Aside from any efficiency issues,
this gives you unwanted data, which can result in undesired behavior,
and it constrains the contexts in which you can reify that continuation.
> I don't see how the act of describing the idea of delimited
> continuations changes anything.
One of the objections to continuations is that they capture state which
you don't want to capture. Delimited continuations address that.
> While serializability may make this or that program slightly simpler,
> I am not aware of any concerns about continuations that are actually
> resolved by that. The potential externalizability of some
> continuations was never in doubt, was it?
Of course it wasn't, but people use lack of serializability in R5RS and
in some implementations as a critique of continuations in general.
> Rather than these (supposedly) "natural extensions ... [addressing]
> many, perhaps most, of the concerns ...." I don't see how they
> address *any* of the concerns.
Which concerns don't they address?
Regarding naturalness, serialization is as natural an operation for
continuations as it is for almost any other non-trivial structure. As
for delimited continuations, their operational semantics is really
simple and obvious (well, at least in hindsight). Their intuitive
description in terms of real code is also simple: basically, marking a
segment of stack that can be manipulated.
Anton
Anton van Straaten wrote:
> Call/cc can be thought of as a high-level tool that supports language
> design. Not everyone wants to do language design, so it's a specialized
> tool that not everyone has a direct need for. Aside from its use to
> theoreticians, it's most likely to be useful to developers of embedded
> languages, frameworks, and similar tools. See Kanren for a nice example
> of where it's useful.
Where's that? I see just one use of call/cc in MiniKanren, and it
appears not to be essential.
··········@gmail.com wrote:
> Anton van Straaten wrote:
>
>>Call/cc can be thought of as a high-level tool that supports language
>>design. Not everyone wants to do language design, so it's a specialized
>>tool that not everyone has a direct need for. Aside from its use to
>>theoreticians, it's most likely to be useful to developers of embedded
>>languages, frameworks, and similar tools. See Kanren for a nice example
>>of where it's useful.
>
>
> Where's that? I see just one use of call/cc in MiniKanren, and it
> appears not to be essential.
That was a mistake, I was actually thinking of Schelog.
Followup-To: comp.lang.scheme
Anton van Straaten <·····@appsolutions.com> writes:
> The only factually supportable criticisms that have been raised boil
> down to "but they're not perfect for every situation".
A problem with call/cc is that it exhibits aspects of code which
would otherwise be private implementation choices, it distinguishes
programming choices which would otherwise be equivalent.
See http://sisc.sourceforge.net/r5rs_pitfall.php - many of these
pitfalls are related to call/cc. In other words, some code would be
correct if call/cc was not available. Here only interactions with some
R5RS constructs is described, but the same applies to regular Scheme
code.
Call/cc is not the only feature with this property. Exceptions have
a similar effect, threads too, and asynchronous exceptions. In each
case, the usefullness of the feature must be weighted against the
problem it causes for writers of code which doesn't even use that
feature but want to be composable with other code which does.
* * *
Another problem is interaction with other features affecting the
control flow. The classic example is unwind-protect.
When a continuation captured outside unwind-protect is invoked inside
unwind-protect, there are two possibilities for the intention:
1. The continuation is used to abort the computation prematurely,
playing the role of an exception.
In this case the unwind-protect cleanup should be performed,
there will be no further chance.
2. The continuation is used to temporarily switch to a different task,
playing the role of a coroutine.
In this case unwind-protect should not trap the switch. The
computation will return, will want to continue using resources
released by unwind-protect.
Unfortunately it's impossible to distinguish these intentions
automatically, so code can't accomodate both uses of continuations.
The problem can be solved by using more specialized constructs instead
of call/cc, e.g. exceptions and threads.
* * *
The third problem is interaction with other languages, most of which
don't support call/cc. Implementing a part of the program in a
different language has an observable impact in disallowing certain
uses of continuations.
Again, there are analogous issues with other control flow features,
and their usefulness must be weighted against the problems.
For these reasons my personal opinion is slightly against call/cc.
> Regarding naturalness, serialization is as natural an operation for
> continuations as it is for almost any other non-trivial structure.
Serializing continuations is as tricky as serializing functions,
and has serious theoretical and practical problems.
Functions and continuations are unusual in that there is no natural
semantics of serializing them across programs. With most data it is
clear which subobjects belong to the datum, and thus it's clear what
to serialize. But functions and continuations are opaque; they refer
to program code, which is not partitioned into objects in the usual way.
The code can refer to various global values, including other code.
What exactly it refers to, or which parts are global, can depend on
optimization.
So, which data to serialize along with a function or continuation?
It makes little sense conceptually.
Besides, the common implementation technique of generating machine
code provides no way to serialize functions.
--
__("< Marcin Kowalczyk
\__/ ······@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Anton van Straaten <·····@appsolutions.com> wrote:
+---------------
| Rob Warnock wrote:
| > Don't get me wrong: I still think the "web continuations" *model*
| > is a great way to think about the user/server interactions ...
| > But just because "web
| > continuations" are a good model for *designing* the navigation and
| > interactions doesn't mean that "real" continuations are actually the
| > right way to *implement* the site.
|
| You're right about the model being good, but beyond that, there's a big
| red flag in the above claim. It suggests that having developed a model
| based on continuations, the only way to effectively implement that model
| is to manually map it onto an implementation in which (some of) the
| continuations have been made explicit.
+---------------
Unfortunately, that's already the case. The browser user may be
presented with a single HTML page [a single "call" to the user by
the server, in the web continuations model], but if that page contains
*multiple* HTML forms you end up with the user being able to choose
between as many different continuations as there are HTML forms!!
This means that in the server a "call" to the user has to be able to
reify not just one but *multiple* continuations, something that classic
CALL/CC isn't capable of [at least, not without significant extension].
Now with CPS-transformed code, on the other hand, this all becomes
trivial. One merely does a "jump-with-arguments" (a.k.a. tail call)
to the subroutine [the browser user, in this case] with whatever
arguments are needed, any or all of which can be continuations!!
Problem solved!
But if one is going to CPS-transform the server/user interaction
anyway to accomodate multiple continuations, then there is no longer
any need for "real" continuations on the server side -- the sort
of "faux continuations" that Kenny [and I] talked about are fine.
You still have the *idea* of continuations, but all they are is
an identified set of routines to dispatch to depending on which
HTML form was triggered.
+---------------
| But what makes you think that this mapping can't be automated?
+---------------
Oh, it can be, even in Common Lisp [which is what I've been coding
my "web continuations" code]. E.g., see Paul Graham's book "On Lisp"
for macros to do multi-use continuations in CL. It's just that given
the existence of "calls" to the user that need to provide *multiple*
continuations simultaneously, the simple-minded CALL/CC model becomes
*less* convenient than explicit CPS-conversion!! [IMHO. YMMV.]
And by the way, there is at least one classic programming language
which has shown that programmers are quite able to handle explicit
representation of multiple continuations in the source language: SNOBOL.
In SNOBOL, *every* statement can be explicitly provided with two
continuations, called SUCCESS & FAIL [or a single continuation of
unconditional GOTO or the default of fall-through to the next statement].
The extension to multiple web continuations per HTML page is obvious
and direct.
Or said yet another way, once one has to deal with "calls" containing
multiple continuations, one is half-way an explicit event-driven
finite state machine. To me, the lines between CALL/CC-style
continuations, manual CPS-transformed code, and event-driven finite
state machines are in practice quite blurry -- it's more of a
continuum than a hard choice.
+---------------
| Scheme implementations, in conjunction with theoretical work, have been
| addressing these issues very successfully. For example, SISC and Gambit
| support serializable continuations, and Scheme48 provides native support
| for delimited continuations. These two natural extensions of Scheme's
| continuations address many, perhaps most, of the concerns which people
| raise against first-class continuations.
+---------------
But how do you provide *multiple* continuations using CALL/CC syntax?
+---------------
| Coming back to the question of mapping from a continuation-based model
| to an implementation, we shouldn't forget that we have tools which are
| capable of transforming code written in one style into code written in
| another style. They're called "compilers". It's perfectly possible to
| automatically transform code written with implicit continuations into
| code which makes the continuations explicit in data stored on web pages,
| for example. To do this, all that is required is the well-known and
| easy-to-implement CPS transformation. This ends up being equivalent to
| having support for serializable, first-class continuations, but it
| provides a different way to think about it, which can be helpful.
+---------------
No argument. [See my comments above.] And of course, the Lisp family
of languages make writing such "compilers" relatively simple --
sometimes as simple as an appropriate set of declarative macros!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> To me, the lines between CALL/CC-style
> continuations, manual CPS-transformed code, and event-driven finite
> state machines are in practice quite blurry -- it's more of a
> continuum than a hard choice.
I agree with this. And because manipulation of control flow is
important in computer programs, I'd like to see that continuum enriched
with more continuation-related tools, of which call/cc is only one.
> +---------------
> | Scheme implementations, in conjunction with theoretical work, have been
> | addressing these issues very successfully. For example, SISC and Gambit
> | support serializable continuations, and Scheme48 provides native support
> | for delimited continuations. These two natural extensions of Scheme's
> | continuations address many, perhaps most, of the concerns which people
> | raise against first-class continuations.
> +---------------
>
> But how do you provide *multiple* continuations using CALL/CC syntax?
To illustrate using your form example, you can define a macro along
these lines:
(define-syntax form-let
((_ ((form make-form handle-form)) body ...)
(let ((form (call/cc make-form)))
(if (form? form)
(begin body ...)
(handle-form form)))))
This is adapted from real code, but is more of a specification than
working code - a working version would require at least a minimal web
framework, and in that context the calls to call/cc would be replaced
with wrappers which deal with HTTP requests, etc.
You can use it like this:
(form-let ((form1 make-form1 handle-form1)
(form2 make-form2 handle-form2))
(send/suspend (make-page form1 form2)))
The make-form procedures take a continuation argument, and generates an
sexp representation of a form with a reference to (or serialization of)
the continuation embedded in the form. The sexp form representation
needs to respond to the form? predicate with #t.
The handle-form procedures take a single argument, which is the result
of the user submitting that form (which would typically be an alist or
some other structured representation of the request).
When evaluated, the example calls make-form1 with a continuation, and
calls make-form2 with another continuation. It then evaluates the body,
which constructs a page from the two forms and delivers it to the client.
When either of the two forms is submitted by the client, the
corresponding continuation is invoked. This restarts execution at the
point at which either form1 or form2 was bound, setting them to the
result of the form submission. The form? test detects that it has been
given something other than a form (i.e. it has a result), and the
corresponding handler is invoked. Once the handler completes, execution
would continue "after" the form-let expression, i.e. the form-let
expression's continuation is invoked with the result returned by the
form handler.
I set up this example for ease of illustration, but it's easy enough to
make a more integrated version to support e.g. constructing a page with
multiple forms as a single inline sexp, without requiring procedures
such as make-form.
Anton
Anton van Straaten <·····@appsolutions.com> wrote:
+---------------
| Rob Warnock wrote:
| > But how do you provide *multiple* continuations using CALL/CC syntax?
|
| To illustrate using your form example, you can define a macro along
| these lines: (define-syntax form-let ...[elided]... )
|
| You can use it like this:
| (form-let ((form1 make-form1 handle-form1)
| (form2 make-form2 handle-form2))
| (send/suspend (make-page form1 form2)))
+---------------
Neat! By hoisting the building of the forms into the FORM-LET,
you get to generate multiple continuations. Now why didn't *I*
think of that...? ;-} ;-}
[Answer: Because I use an s-expr-based HTML-generator (HTOUT,
but it could be CL-WHO or HTMLGEN or others), I tend to generate
the forms sequentially inline, and thus was thinking that there
was only one possible continuation to SEND-SUSPEND.]
+---------------
| When either of the two forms is submitted by the client, the
| corresponding continuation is invoked. This restarts execution at the
| point at which either form1 or form2 was bound, setting them to the
| result of the form submission. The form? test detects that it has been
| given something other than a form (i.e. it has a result), and the
| corresponding handler is invoked. Once the handler completes, execution
| would continue "after" the form-let expression, i.e. the form-let
| expression's continuation is invoked with the result returned by the
| form handler.
+---------------
I suspect another reason I didn't think of this approach is that,
using it, the usual default continuation created by SEND/SUSPEND is
*abandoned* completely, since that continuation is never invoked.
+---------------
| I set up this example for ease of illustration, but it's easy enough to
| make a more integrated version to support e.g. constructing a page with
| multiple forms as a single inline sexp, without requiring procedures
| such as make-form.
+---------------
Sure. Just initialize a collection at the start of the page generation,
and as each form is generated push its continuation onto the collection,
and (SEND/SUSPEND (APPLY #'MAKE-PAGE COLLECTED-FORMS)) at the end.
[But as above, the default continuation created by SEND/SUSPEND is
abandoned if any of the forms is submitted.]
Thanks for the tip. Some of the ideas apply even if one *isn't*
using "real" continuations on the server...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Neat! By hoisting the building of the forms into the FORM-LET,
> you get to generate multiple continuations. Now why didn't *I*
> think of that...? ;-} ;-}
I know that feeling all too well! ;)
> [Answer: Because I use an s-expr-based HTML-generator (HTOUT,
> but it could be CL-WHO or HTMLGEN or others), I tend to generate
> the forms sequentially inline, and thus was thinking that there
> was only one possible continuation to SEND-SUSPEND.]
To arrive at the solution I gave, the "standard" behavior of
send/suspend itself may also be misleading, since it assumes that a
continuation needs to be captured at the point at which it's invoked.
However, the regular send/suspend can be used to implement the more
general send/suspend/dispatch approach to handling multiple
continuations, which PLT uses.
> I suspect another reason I didn't think of this approach is that,
> using it, the usual default continuation created by SEND/SUSPEND is
> *abandoned* completely, since that continuation is never invoked.
Actually, I included the send/suspend in my example code just to
communicate the idea of sending a response to the client. In practice,
for my approach you don't need to use a procedure that captures a
continuation at that point. You're still abandoning an implicit
continuation, but you don't have to capture it first.
Anton
Ken Tilton wrote:
>
>
> Ray Dillinger wrote:
>
>> Ken Tilton wrote:
>>
>>> "Toys", this is good, you already know your "need" for continuations
>>> is idiotic.
>>
>>
>>
>> Mmmhmmm. Just like C programmers think the need for garbage collection
>> is idiotic.
>
>
> Argument from analogy! I love these. they are just like... seedless grapes?
>
Nah, it's just the kind of argument I make when I don't care
enough about arguing to try to sew it up. Programmers who
use languages that don't have X (for whatever X) obviously
are among the set that don't think X is valuable. That's
because if they did think X were valuable they would be using
languages that had X. IOW, you and that C programmer already
have your minds made up; what's the use of trying to convince
you?
What I'm saying was not specifically to do with whether or not
these things are valuable; what I'm saying is that I have
better things to do with my time than argue about it.
Bear
--
"Never try to teach a pig to sing.
It wastes your time and annoys the pig." - R.A.H.
Ray Dillinger wrote:
> Ken Tilton wrote:
>
>>
>>
>> Ray Dillinger wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>> "Toys", this is good, you already know your "need" for continuations
>>>> is idiotic.
>>>
>>>
>>>
>>>
>>> Mmmhmmm. Just like C programmers think the need for garbage collection
>>> is idiotic.
>>
>>
>>
>> Argument from analogy! I love these. they are just like... seedless
>> grapes?
>>
>
> Nah, it's just the kind of argument I make when I don't care
> enough about arguing to try to sew it up. Programmers who
> use languages that don't have X (for whatever X) obviously
> are among the set that don't think X is valuable. That's
> because if they did think X were valuable they would be using
> languages that had X.
Nah, there are other considerations in the choice (I like a big spec,
for example, and nil /is/ false) so continuations alone would not make
me change horses. Again, this indirect form of discussion is as bad as
analogy, I wish you super-logical Schemers could just discuss the apples
when someone brings up apples. :)
> IOW, you and that C programmer already
> have your minds made up; what's the use of trying to convince
> you?
This is very disappointing. I have tried to make simple, technical
points precisely to avoid personal bias. Look at the frickin subject:
someone asked "Lisp or Scheme?". Continuations are one great honking
difference between Lisp and Scheme. You are not here to persuade me, you
are here to inform the OP.
I have made solid technical arguments against continuations, you have
attacked my open-mindedness. Thanks for that, btw. When in fact,
whenever this comes up, I really do run the thought experiment of asking
myself what I would be doing/thinking if CL had continuations. That is
why it was funny this time when I looked down at my code and saw I was
working on code that was continuation-like. Using extant data structures.
You offered the Web as a killer app for continuations. Apparently not,
based on reports from serious Web app developers (not me!). Why not
defend your offering? On the merits. Instead you retreat to a defense in
which /we/ are the ones not willing to discuss things objectively.
Talk about cute tricks. :)
>
> I have
> better things to do with my time than argue about it.
It is hard not to. This is just my way of taking a break from coding
without getting so far away from the keyboard that I lose momentum. And
I think you meant to say, Phhhhhhhhhhhhht!
:)
ken
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> That is
> why it was funny this time when I looked down at my code and saw I was
> working on code that was continuation-like. Using extant data structures.
So what? This is the argument Java people tend do use
to justify that they do not need first-class full closures, which
were left out of Java based on what are also considered
"good technical arguments" by some.
> You offered the Web as a killer app for continuations. Apparently not,
> based on reports from serious Web app developers (not me!).
How would they even know the answer, be it yes or no, or for that matter,
would it even occur to someone to ask the question, if Scheme did not
have call/cc? A large part of the purpose of Scheme is to allow this
kind of research, so that even a negative answer in this particular
instance would be an argument in favour of having call/cc in Scheme.
> Why not
> defend your offering? On the merits.
Continuations are an abstraction device. It allows one to
concisely express many useful control abstractions. Examples
include throw/catch, generators, enumerators, representing monads,
etc.
Like any abstraction device, you can do without the device
if you are willing to open-code what they achieve. In this regard,
I will refer to the usual arguments against abstraction of whatever
kind, and to their standard refutations.
There is no question that call/cc has a mind-broadening effect,
allowing new abstractions to be formulated and tried. Anyone is of course
welcome to limit himself to "oldspeak" if he wishes to more
effecttively reduce the probability of new ideas occurring to him.
Andre wrote:
> Ken Tilton wrote:
>
>
>>That is
>>why it was funny this time when I looked down at my code and saw I was
>>working on code that was continuation-like. Using extant data structures.
>
>
> So what? This is the argument Java people tend do use
> to justify that they do not need first-class full closures, which
> were left out of Java based on what are also considered
> "good technical arguments" by some.
I understand, but this is the problem with argument by analogy. Are the
two actually analogues of each other? Guess what my opinion is on that.
:) Here it comes:
I blithely toss off lambdas high and low all over the place. The code I
write captures variables left and right. So it is huge that I do not
have to think about it (and stop to cobble together an ad hoc class (of
course a Lispnik could just bung together a list, but I digress)).
Are Schemers using continuations with the same heavy frequency /
ubiquity? If a Schemer got their hands on my code base*, how many roles
for continuations would they find? We all know that Greenspun's Tenth is
no joke: the Lisp in a sufficiently complex C application just jumps out
at us. Same with CL code and continuations?
Final note on the analogy: no kidding, I did /not/ have to do anything
special to change the depth-first search into breadth-first search. But
maybe my mileage varies since I like OO and my Cells hack /really/
encourages me to use objects for everything.
Hmm, no opinion yet, I'll wait for the feedback.
kt
* Come to think of it, most of it is available on common-lisp.net.
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
joh wrote:
> I only get to play with the good languages during my hobby time, and
> I've stuck to CL because I just love the feel of the language. Scheme
> seems nice, too, but my heart's already taken.
>
> It's always bothered me though that CL doesn't have continuations. From
> my limited knowledge, that seems like the one deep concept Scheme has
> that CL doesn't. And since Lisp for me is play time, I want access to
> all the toys.
>
> So some questions for the two camps, and especially those with a foot
> in both camps:
>
> 1. How much do Schemers actually use continuations?
>
> 2. I believe there's at least one library that tries to provide
> continuations in CL. How close is it to the "real thing"?
>
> 3. How hard is it to take some continuation-heavy Scheme code and port
> it to CL? Is it usually straightforward to find a CL way to accomplish
> the same things?
It's not true that CL doesn't have continuations at all. First some
terminology:
- There are one-shot and multi-shot continuations. The difference is
that a one-shot continuations is only called once while a multi-shot
continuation is called several times.
- There are escaping and non-escaping continuations. If you grab a
continuation, for example with call/cc, and during the execution of that
call/cc invoke the continuation, this is called an escaping continuation
because the continuation escapes from the current control flow. If the
execution of that call/cc is already over (either normally or via the
invocation of that continuation), and you call that continuation
(possibly a second time), then this is called a non-escaping
continuation because you are actually returning to a point of execution
that was already "escaped."
Scheme supports one-shot and multi-shot escaping and non-escaping
continuations.
Common Lisp provides the pairs catch/throw and block/return-from which
are one-shot escaping continuations. Common Lisp doesn't support
multi-shot or non-escaping continuations.
It seems to me that in a lot of cases, Scheme's continuations are only
invoked once if at all and are invoked during the extent of the
respective call/cc, so are effectively used as one-shot escaping
continuations. In those cases it is relatively straightforward to
translate the code to Common Lisp, just replace them with the
appropriate constructs (typically block/return-from).
Only if they are used as multi-shot and/or as non-escaping
continuations, then you need to worry more about them. For example, when
continuations are used to simulate threads, or when they are used as
building blocks for web applications, then they are used as non-escaping
continuations.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
"Sean SCC" <···········@googlemail.com> writes:
> Thanks to everyone who replied to my previous post!
>
> I am still trying to decide between Lisp and Scheme. Keeping in mind
> that I will be developing in Windows, and code speed is fairly
> important I have another question, which is:
>
> Is there anything relevant to programming in the real world that Lisp
> is able to do that Scheme cannot, without significant effort and
> vice-versa?
>
> Please, I am not trying to start a flame war.
>
> I know that there are differences between Scheme and Lisp in some areas
> and have done some reading up, but without extensive understanding and
> experience with either one or the other it is almost impossible to know
> if the differences impact on real world programming in any significant
> way as the languages seem to be almost identical in terms of their
> abilities.
>
> Again I emphasize, I know this is an emotional issue with some people
> but it is not my intention at all to "stir the pot". My approach is -
> "what works best in the real world".
Let me be more precise.
(cond
((and (you are programming in lisp)
(you are defining things like
'(defmacro define (name-and-args &body body)
(if (symbolp name-and-args)
`(defparameter ,name-and-args ,body)
`(defun ,(first name-and-args) ,(rest name-and-args)
,@body)))))
(you better switch to scheme))
((and (you are programming in scheme)
(you are defining things like
'(define-syntax defun
(syntax-rules ()
((defun name arguments . body)
(define (name . arguments) . body))))))
(you better switch to lisp))
(t
(stay with your current language)))
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
Sean SCC wrote:
> Thanks to everyone who replied to my previous post!
>
> I am still trying to decide between Lisp and Scheme. Keeping in mind
> that I will be developing in Windows, and code speed is fairly
> important I have another question, which is:
>
> Is there anything relevant to programming in the real world that Lisp
> is able to do that Scheme cannot, without significant effort and
> vice-versa?
>
> Please, I am not trying to start a flame war.
>
> I know that there are differences between Scheme and Lisp in some areas
> and have done some reading up, but without extensive understanding and
> experience with either one or the other it is almost impossible to know
> if the differences impact on real world programming in any significant
> way as the languages seem to be almost identical in terms of their
> abilities.
>
> Again I emphasize, I know this is an emotional issue with some people
> but it is not my intention at all to "stir the pot". My approach is -
> "what works best in the real world".
>
That's okay. Seems like flamewars are trying to spark up anyway ;-)
However I'll try to shed a little light on your question. For a lot of
people who are coming to Sheme or Lisp from other programming languages,
especially the more "business" oriented languages, it's all about the
development environment. People who used Eclipse or Visual Studio or
JBuilder or your flavor of the day IDE tend to look for something
similar, and the closest you're going to get to graphical debugger and
code-completion and runtime syntax checking is PLT's DrScheme. It's not
any of the aforementioned IDEs, but it has a lot of features that make
keeping track of what your doing easier than other environments for
beginners. The Check Syntax button works very well, checks for dangling
variables and some of the more heinous errors as well as builds a nice
little map of where all your variables are used and defined within a
program (much like Eclipse 3.0's variable highlighting feature), even
managing variables defined from module imports. The debug button
doesn't do what you expect from Eclipse or VS, but it does work well,
and once you learn it and learn to make use of the trace.ss module (also
available in other Schemes), you'll be well on your way to efficient
debugging. The DrScheme environment is graphical and its MrEd makes
programming graphical applications palatable, if that's your thing. It
includes a webserver (with servlets). If you use Swindle, also
included, then it includes an object system and a lot of other
conveniences. DrScheme isn't the fastest Scheme around, but anything
written in DrScheme will compile in MzScheme, PLT's non-cuddly scheme
environment, and will run much, much faster.
Common Lisp is almost always faster than Scheme when compiled, at least
if you're using a commercial implementation (nods to Bigloo and Chicken
for being the fastest of the free Scheme environments) and includes
type-predicates, an industrial strength object system, and other things
that you'll find useful down the road, but if you're just interested in
starting out, you can move to CL from Scheme without too much work.
Just forget that continuations exist, change the kinds of macros you
want to write, and misspell 'define' and you have a significant subset
of Lisp learned (not enough to be super-productive, but learning it's
like moving from C to Perl -- not all that much work). The thing about
Common Lisp, though, is that if you want a free implementation, your
choices of environments in which to program are limited. Emacs with
Slime seems to be the consensus "standard" for most of the Lisp
developers I meet. It works, and works well, but it's not near as
"cuddly" as DrScheme.
Give both a try, though, and see what you think...
-- Jeff
Jeff Heard wrote:
> Common Lisp is almost always faster than Scheme when compiled, at least
> if you're using a commercial implementation (nods to Bigloo and Chicken
> for being the fastest of the free Scheme environments)
There are at least eight compiled implementations of Scheme
available for Windows, and at least seven are free. From the
benchmarks I've run, I'd say Bigloo is one of the faster
compiled systems, and Chicken one of the slower. (Eli
Barzilay's benchmark results, posted in comp.lang.scheme
a few days ago, are relevant also.)
Will
Jeff Heard skrev:
> Common Lisp is almost always faster than Scheme when compiled, at least
> if you're using a commercial implementation (nods to Bigloo and Chicken
> for being the fastest of the free Scheme environments)
Have you ever the commercial version of Chex Scheme?
--
Jens Axel S�gaard
Jens Axel S�gaard wrote:
> Jeff Heard skrev:
>
>> Common Lisp is almost always faster than Scheme when compiled, at
>> least if you're using a commercial implementation (nods to Bigloo and
>> Chicken for being the fastest of the free Scheme environments)
>
> Have you ever the commercial version of Chex Scheme?
>
No, I'd love to, but I don't have the money. Right now, it's PLT all
the way for me.
Jeff Heard wrote:
> Sean SCC wrote:
>> Thanks to everyone who replied to my previous post!
>>
>> I am still trying to decide between Lisp and Scheme. Keeping in mind
>> that I will be developing in Windows, and code speed is fairly
>> important I have another question, which is:
>>
>> Is there anything relevant to programming in the real world that Lisp
>> is able to do that Scheme cannot, without significant effort and
>> vice-versa?
>>
>> Please, I am not trying to start a flame war.
>>
>> I know that there are differences between Scheme and Lisp in some areas
>> and have done some reading up, but without extensive understanding and
>> experience with either one or the other it is almost impossible to know
>> if the differences impact on real world programming in any significant
>> way as the languages seem to be almost identical in terms of their
>> abilities.
>>
>> Again I emphasize, I know this is an emotional issue with some people
>> but it is not my intention at all to "stir the pot". My approach is -
>> "what works best in the real world".
>>
>
> That's okay. Seems like flamewars are trying to spark up anyway ;-)
> However I'll try to shed a little light on your question. For a lot of
> people who are coming to Sheme or Lisp from other programming languages,
> especially the more "business" oriented languages, it's all about the
> development environment. People who used Eclipse or Visual Studio or
> JBuilder or your flavor of the day IDE tend to look for something
> similar, and the closest you're going to get to graphical debugger and
> code-completion and runtime syntax checking is PLT's DrScheme. It's not
> any of the aforementioned IDEs, but it has a lot of features that make
> keeping track of what your doing easier than other environments for
> beginners. The Check Syntax button works very well, checks for dangling
> variables and some of the more heinous errors as well as builds a nice
> little map of where all your variables are used and defined within a
> program (much like Eclipse 3.0's variable highlighting feature), even
> managing variables defined from module imports. The debug button
> doesn't do what you expect from Eclipse or VS, but it does work well,
> and once you learn it and learn to make use of the trace.ss module (also
> available in other Schemes), you'll be well on your way to efficient
> debugging. The DrScheme environment is graphical and its MrEd makes
> programming graphical applications palatable, if that's your thing. It
> includes a webserver (with servlets). If you use Swindle, also
> included, then it includes an object system and a lot of other
> conveniences. DrScheme isn't the fastest Scheme around, but anything
> written in DrScheme will compile in MzScheme, PLT's non-cuddly scheme
> environment, and will run much, much faster.
>
> Common Lisp is almost always faster than Scheme when compiled, at least
> if you're using a commercial implementation (nods to Bigloo and Chicken
> for being the fastest of the free Scheme environments) and includes
> type-predicates, an industrial strength object system, and other things
> that you'll find useful down the road, but if you're just interested in
> starting out, you can move to CL from Scheme without too much work. Just
> forget that continuations exist, change the kinds of macros you want to
> write, and misspell 'define' and you have a significant subset of Lisp
> learned (not enough to be super-productive, but learning it's like
> moving from C to Perl -- not all that much work). The thing about
> Common Lisp, though, is that if you want a free implementation, your
> choices of environments in which to program are limited. Emacs with
> Slime seems to be the consensus "standard" for most of the Lisp
> developers I meet. It works, and works well, but it's not near as
> "cuddly" as DrScheme.
>
> Give both a try, though, and see what you think...
>
> -- Jeff
Ok, foo on me for not researching the fastest Windows Schemes out there.
Sorry about that. However, it is fairly well-founded to say that
compiled Scheme is not as fast as compiled Lisp, assuming you're using
the full capabilities of Scheme, because compiler abstractions for first
class continuations and such like that are not as far along yet. Chez
Scheme may well have compiled code speeds close to Common Lisp, but it's
not open, so I haven't evaluated it.
Jeff Heard wrote:
> Sorry about that. However, it is fairly well-founded to say that
> compiled Scheme is not as fast as compiled Lisp, assuming you're using
> the full capabilities of Scheme, because compiler abstractions for first
> class continuations and such like that are not as far along yet.
Oh.
Will
Jeff Heard wrote:
>Sorry about that. However, it is fairly well-founded to say that
>compiled Scheme is not as fast as compiled Lisp, assuming you're using
>the full capabilities of Scheme, because compiler abstractions for first
>class continuations and such like that are not as far along yet.
You are claiming that a feature Common Lisp _doesn't_have_ slows
down Scheme compilers in compiling programs which require it.
Forgive me for pointing this out, but for programs that require
it, won't the scheme implementations be a lot faster anyway?
Bear
Ray Dillinger wrote:
> Jeff Heard wrote:
>
>> Sorry about that. However, it is fairly well-founded to say that
>> compiled Scheme is not as fast as compiled Lisp, assuming you're using
>> the full capabilities of Scheme, because compiler abstractions for first
>> class continuations and such like that are not as far along yet.
>
>
> You are claiming that a feature Common Lisp _doesn't_have_ slows
> down Scheme compilers in compiling programs which require it.
>
> Forgive me for pointing this out, but for programs that require
> it, won't the scheme implementations be a lot faster anyway?
>
> Bear
>
>
Last time I checked, continuations aren't *required* for any program...
I'm not claiming at all that simply having first-class continuations
as part of what your compiler can handle will slow it down.
As for the idea that using a first-class continuation in Scheme would
naturally produce a faster solution than kludgeing out a workaround in
Common Lisp... well, of course it would. The point, however, would be
that if you're writing Common Lisp, you should write Common Lisp and not
Scheme kludged into Common Lisp.
Jeff Heard wrote:
> Ray Dillinger wrote:
> > Jeff Heard wrote:
> >
> >> Sorry about that. However, it is fairly well-founded to say that
> >> compiled Scheme is not as fast as compiled Lisp, assuming you're using
> >> the full capabilities of Scheme, because compiler abstractions for first
> >> class continuations and such like that are not as far along yet.
> >
> >
> > You are claiming that a feature Common Lisp _doesn't_have_ slows
> > down Scheme compilers in compiling programs which require it.
> >
> > Forgive me for pointing this out, but for programs that require
> > it, won't the scheme implementations be a lot faster anyway?
> >
> > Bear
> >
> >
> Last time I checked, continuations aren't *required* for any program...
> I'm not claiming at all that simply having first-class continuations
> as part of what your compiler can handle will slow it down.
>
> As for the idea that using a first-class continuation in Scheme would
> naturally produce a faster solution than kludgeing out a workaround in
> Common Lisp... well, of course it would. The point, however, would be
> that if you're writing Common Lisp, you should write Common Lisp and not
> Scheme kludged into Common Lisp.
I think you miss the point slightly.
If you program Scheme and use no continuations then you have the option
of using very fast compilers such as Bigloo and Stalin.
In the small area of continuations Scheme has more capabilities than
CL, but this ought not to be thought of as a negative just because if
you decide to use them then your code may be slower.
Sean SCC wrote:
> Thanks to everyone who replied to my previous post!
>
> I am still trying to decide between Lisp and Scheme.
Having separate "value cells" and "function cells" (to use the "street
language" way of saying it) was one of the most unfortuanate issues.
We did not want to break pre-existing programs that had a global
variable named "foo" and a global function named "foo" that were
distinct. We at Symbolics were forced to insist on this, in the face
of everyone's knowing that it was not what we would have done absent
compatibility constraints. It's hard for me to remember all the
specific things like this, but if we had had fewer compatibility
issues, I think it would have come out looking more like Scheme in
general. --- Daniel Weinreb
Lisp2 means that all kinds of language primitives have to exist in two
versions, or be parameterizable as to whether they are talking about
the value cell or function cell. It makes the language bigger, and
that's bad in and of itself. --- Daniel Weinreb
--
The CL effort resembles a bunch of spoiled children,
each insisting "include my feature or I'll pull out, and then we'll all
go down the tubes". Everybody had vested interests, both financial
and emotional. --- Jeffrey M. Jacobs
"William James" <·········@yahoo.com> writes:
> Sean SCC wrote:
>> Thanks to everyone who replied to my previous post!
>>
>> I am still trying to decide between Lisp and Scheme.
>
>
> Having separate "value cells" and "function cells" (to use the "street
> language" way of saying it) was one of the most unfortuanate issues.
> We did not want to break pre-existing programs that had a global
> variable named "foo" and a global function named "foo" that were
> distinct. We at Symbolics were forced to insist on this, in the face
> of everyone's knowing that it was not what we would have done absent
> compatibility constraints. It's hard for me to remember all the
> specific things like this, but if we had had fewer compatibility
> issues, I think it would have come out looking more like Scheme in
> general. --- Daniel Weinreb
>
> Lisp2 means that all kinds of language primitives have to exist in two
> versions, or be parameterizable as to whether they are talking about
> the value cell or function cell. It makes the language bigger, and
> that's bad in and of itself. --- Daniel Weinreb
>
> The CL effort resembles a bunch of spoiled children,
> each insisting "include my feature or I'll pull out, and then we'll all
> go down the tubes". Everybody had vested interests, both financial
> and emotional. --- Jeffrey M. Jacobs
These old citations are funny, nowadays.
Nobody even remember anything else than CL and Scheme. Who are these
spoiled children or these edenly lisps they refer to? They only exist
in history books and lost any relevance. ;-)
Happily, what are we left with? A lisp that gathers the best features
of these old lisps! :-)
--
__Pascal Bourguignon__
Pascal Bourguignon wrote:
>
> Nobody even remember anything else than CL and Scheme. Who are these
> spoiled children or these edenly lisps they refer to? They only exist
> in history books and lost any relevance. ;-)
I'm not yet an exhibit in the Computer Museum (although my Lisp Machine
is).
It has been a long time, but I remember how lame Common Lisp seemed
next to Zetalisp, and how weird InterLisp was.
> Happily, what are we left with? A lisp that gathers the best features
> of these old lisps! :-)
And a few grizzled malcontents.
Joe Marshall wrote:
> Pascal Bourguignon wrote:
> >
> > Nobody even remember anything else than CL and Scheme. Who are these
> > spoiled children or these edenly lisps they refer to? They only exist
> > in history books and lost any relevance. ;-)
>
> I'm not yet an exhibit in the Computer Museum (although my Lisp Machine
> is).
>
> It has been a long time, but I remember how lame Common Lisp seemed
> next to Zetalisp, and how weird InterLisp was.
You probably miss the integer default read base of 8 in ZetaLisp? ;-)
>
> > Happily, what are we left with? A lisp that gathers the best features
> > of these old lisps! :-)
>
> And a few grizzled malcontents.
Pascal Bourguignon wrote:
> "William James" <·········@yahoo.com> writes:
>
> > Sean SCC wrote:
> >> Thanks to everyone who replied to my previous post!
> >>
> >> I am still trying to decide between Lisp and Scheme.
> >
> >
> > Having separate "value cells" and "function cells" (to use the "street
> > language" way of saying it) was one of the most unfortuanate issues.
> > We did not want to break pre-existing programs that had a global
> > variable named "foo" and a global function named "foo" that were
> > distinct. We at Symbolics were forced to insist on this, in the face
> > of everyone's knowing that it was not what we would have done absent
> > compatibility constraints. It's hard for me to remember all the
> > specific things like this, but if we had had fewer compatibility
> > issues, I think it would have come out looking more like Scheme in
> > general. --- Daniel Weinreb
> >
> > Lisp2 means that all kinds of language primitives have to exist in two
> > versions, or be parameterizable as to whether they are talking about
> > the value cell or function cell. It makes the language bigger, and
> > that's bad in and of itself. --- Daniel Weinreb
> >
> > The CL effort resembles a bunch of spoiled children,
> > each insisting "include my feature or I'll pull out, and then we'll all
> > go down the tubes". Everybody had vested interests, both financial
> > and emotional. --- Jeffrey M. Jacobs
>
> These old citations are funny, nowadays.
And you're the guy that knows no language invented after
the 1950s? I.e., nothing other than Lisp, FORTRAN, APL,
COBOL.
One or more of these is true:
1. You are dishonest.
2. You are ignorant.
The quotes by Daniel Weinreb are from Feb. 2003.
Here's a Paul Graham statement from the same year:
Do you really think people in 1000 years want to be
constrained by hacks that got put into the foundations of
Common Lisp because a lot of code at Symbolics depended on
it in 1988?
Paul Graham in 2001:
A hacker's language is terse and hackable. Common Lisp is not.
The good news is, it's not Lisp that sucks, but Common Lisp.
Historically, Lisp has been good at letting hackers have their
way. The political correctness of Common Lisp is an aberration.
Early Lisps let you get your hands on everything.
Organic growth seems to yield better technology and richer founders
than the big bang method. If you look at the dominant technologies
today, you'll find that most of them grew organically.
This pattern doesn't only apply to companies. You see it in
sponsored research too. Multics and Common Lisp were big-bang
projects, and Unix and MacLisp were organic growth projects.
"William James" <·········@yahoo.com> writes:
> Pascal Bourguignon wrote:
>> These old citations are funny, nowadays.
>
> And you're the guy that knows no language invented after
> the 1950s? I.e., nothing other than Lisp, FORTRAN, APL,
> COBOL.
Am I?
> One or more of these is true:
>
> 1. You are dishonest.
> 2. You are ignorant.
>
> The quotes by Daniel Weinreb are from Feb. 2003.
>
> Here's a Paul Graham statement from the same year:
>
> Do you really think people in 1000 years want to be
> constrained by hacks that got put into the foundations of
> Common Lisp because a lot of code at Symbolics depended on
> it in 1988?
>
> Paul Graham in 2001:
>
> A hacker's language is terse and hackable. Common Lisp is not.
CL is hackable. CL is terse enough (it has CAR and CDR in addition to
FIRST and REST).
I'd agree that some implementation of CL are less hackable than
others, and I'd even agree that we could design an implementation of
CL more hackable.
The first implementations of Common Lisp, were actually other lisps
(lisps you'd like more, I guess), and CL was implemented as a
compatibility layer to be able to run CL conformant programs from the
other implementations. Nothing prevents implementers to design
another lisp and to provide a CL layer to allow it run CL conformant
programs and libraries nowadays. Why are they all just implementing
directly a CL? (They still provide a number of implementation
specific packages and features).
For example, emacs lisp provides such a compatibility layer emacs-cl:
You can run Common Lisp programs in emacs lisp.
http://www.cliki.net/emacs-cl
The only thing I reproach to lisps such as Lush, Scheme (R1RS had the
excuse of precedence but R5RS?) or newLISP, is that they don't have
this compatibility layer. ;-)
> The good news is, it's not Lisp that sucks, but Common Lisp.
>
> Historically, Lisp has been good at letting hackers have their
> way. The political correctness of Common Lisp is an aberration.
> Early Lisps let you get your hands on everything.
>
> Organic growth seems to yield better technology and richer founders
> than the big bang method. If you look at the dominant technologies
> today, you'll find that most of them grew organically.
> This pattern doesn't only apply to companies. You see it in
> sponsored research too. Multics and Common Lisp were big-bang
> projects, and Unix and MacLisp were organic growth projects.
Where is MacLisp today? Where is ZetaLisp? I'd even ask where is
LeLisp?
Too bad we cannot fork past alternate universes, because my bet is
that if Common Lisp hadn't been standardized when it has, nobody would
be programming in lisp anymore today.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
Pascal Bourguignon wrote:
> Too bad we cannot fork past alternate universes, because my bet is
> that if Common Lisp hadn't been standardized when it has, nobody would
> be programming in lisp anymore today.
I don't think so. You would have Scheme. :)
Pascal Bourguignon <···@informatimago.com> writes:
>
> For example, emacs lisp provides such a compatibility layer emacs-cl:
> You can run Common Lisp programs in emacs lisp.
> http://www.cliki.net/emacs-cl
That's pretty cool, although I see that it lacks CLOS & pretty printing.
Isn't there an implementation of CLOS out there written on top of CL? I
imagine that there must be a pretty-printer out there as well. Mix 'em
all together and one would have a nice approximation to a CL
environment. Probably dog-slow, but it's neat nonetheless.
--
Robert Uhl <http://public.xdi.org/=ruhl>
I must study politics and war that my sons may have liberty to study
mathematics and philosophy. --John Adams
William James wrote:
> Pascal Bourguignon wrote:
>> "William James" <·········@yahoo.com> writes:
>>
>>> Sean SCC wrote:
>>>> Thanks to everyone who replied to my previous post!
>>>>
>>>> I am still trying to decide between Lisp and Scheme.
>>>
>>> Having separate "value cells" and "function cells" (to use the "street
>>> language" way of saying it) was one of the most unfortuanate issues.
>>> We did not want to break pre-existing programs that had a global
>>> variable named "foo" and a global function named "foo" that were
>>> distinct. We at Symbolics were forced to insist on this, in the face
>>> of everyone's knowing that it was not what we would have done absent
>>> compatibility constraints. It's hard for me to remember all the
>>> specific things like this, but if we had had fewer compatibility
>>> issues, I think it would have come out looking more like Scheme in
>>> general. --- Daniel Weinreb
>>>
>>> Lisp2 means that all kinds of language primitives have to exist in two
>>> versions, or be parameterizable as to whether they are talking about
>>> the value cell or function cell. It makes the language bigger, and
>>> that's bad in and of itself. --- Daniel Weinreb
>>>
>>> The CL effort resembles a bunch of spoiled children,
>>> each insisting "include my feature or I'll pull out, and then we'll all
>>> go down the tubes". Everybody had vested interests, both financial
>>> and emotional. --- Jeffrey M. Jacobs
[...]
> The quotes by Daniel Weinreb are from Feb. 2003.
>
> Here's a Paul Graham statement from the same year:
>
> Do you really think people in 1000 years want to be
> constrained by hacks that got put into the foundations of
> Common Lisp because a lot of code at Symbolics depended on
> it in 1988?
>
> Paul Graham in 2001:
>
> A hacker's language is terse and hackable. Common Lisp is not.
>
> The good news is, it's not Lisp that sucks, but Common Lisp.
>
> Historically, Lisp has been good at letting hackers have their
> way. The political correctness of Common Lisp is an aberration.
> Early Lisps let you get your hands on everything.
>
> Organic growth seems to yield better technology and richer founders
> than the big bang method. If you look at the dominant technologies
> today, you'll find that most of them grew organically.
> This pattern doesn't only apply to companies. You see it in
> sponsored research too. Multics and Common Lisp were big-bang
> projects, and Unix and MacLisp were organic growth projects.
There are lots of varying opinions about all kinds of languages from all
kinds of people. The fact that Common Lisp (and Scheme) are still alive
and kicking means that their users appreciate these languages. And this
is the case in the face of having many, no, lots of alternatives which
are also Lisp/Scheme-based, including switching from Common Lisp to
Scheme, or from Scheme to Common Lisp (which indeed happens in both
directions).
This proves that these languages seem to do something right. You have to
live with the fact that people choose these (both!) languages because of
their features, not in spite of them, even if you don't understand the
specifics.
The quotes you have cited state things like "Lisp-2 is unfortunate",
"bigger languages are bad", "Common Lisp was designed by spoiled
children", "Common Lisp is not hackable", "Common Lisp is politically
correct", "Common Lisp is not organically grown", and speculate about
languages in 1000 years from now on. That's about it. Just hot air. No
discussion of the actual technical issues.
So what's your goal again?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/