Lisp or Scheme?
Sean SCC
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".
Pascal Bourguignon
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."
Pascal Costanza
> 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 Bourguignon
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)))
Sean SCC
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 Costanza
> 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
Wade Humeniuk
> 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
Ken Tilton
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
Abdulaziz Ghuloum
Sean SCC wote:
> ...
> Please, I am not trying to start a flame war.
Funny :-)
Aziz,,,
arnuld
> 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"
Jeff Heard
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
Anton van Straaten
> 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
> 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
Ken Tilton
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
Jens Axel Søgaard
> 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
Brandon J. Van Every
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.
>
> > 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
Brandon J. Van Every
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
Pascal Costanza
>
>
> 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.
William D Clinger
> 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
John Stoneham
> ... 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.
Jeff Heard
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.
William D Clinger
> 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
Ray Dillinger
>
>
> 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
Hermann Jurksch
> 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
Jeff Heard
No, I'd love to, but I don't have the money. Right now, it's PLT all
the way for me.
Ray Dillinger
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
Brandon J. Van Every
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
Ken Tilton
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
Anton van Straaten
>
>
> 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
Jeff Heard
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.
Ken Tilton
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
Anton van Straaten
> 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
Ken Tilton
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.
Rob Thorpe
> 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?
> >
> >
>
> 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
> 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
> 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.
Chris Barts
>
> 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 =----
Rob Thorpe
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.
Marcin 'Qrczak' Kowalczyk
> More briefly, i wold love to hear of a language innovation that
> could not be implemented in ansi CL.
Threads.
--
__("< Marcin Kowalczyk
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
Rob Thorpe
> 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 Warnock
+---------------
| 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 <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Pascal Bourguignon
> 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
> Ken Tilton <kent...@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
> 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.
patro
> >> 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
Pascal Bourguignon
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
Rob Thorpe
> "Rob Thorpe" <robert...@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
> "patro" <pa...@ortap.com> writes:
>
> > "Pascal Bourguignon" <p...@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!
Pascal Costanza
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/
patro
> >> 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
Rob Thorpe
> Rob Thorpe wrote:
> > Pascal Bourguignon wrote:
> >> "Rob Thorpe" <robert...@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.
Jens Axel Søgaard
> There is never a need to justify beer.
Light beer need no justification?
--
Jens Axel Søgaard
Pascal Costanza
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.
Rob Thorpe
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
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
Ken Tilton
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.
:)
Ken Tilton
Marcin 'Qrczak' Kowalczyk wrote:
> Ken Tilton <kent...@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
Ken Tilton
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
Duane Rettig
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 du...@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
Pascal Bourguignon
> Rob Thorpe wrote:
>> Pascal Bourguignon wrote:
>>
>>>"patro" <pa...@ortap.com> writes:
>>>
>>>
>>>>"Pascal Bourguignon" <p...@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".
Rob Thorpe
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.
Robert Uhl
>
> 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
Joe Knapka
> 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
Pascal Costanza
> 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.
Joe Knapka
> 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
John Stoneham
> 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.
John Thingstad
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/
Pascal Costanza
> On Mon, 21 Aug 2006 23:47:56 +0200, John Stoneham
> <captnja...@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...
Mallor
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
> > 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
George Neuner
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
Peter Herth
> 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/
Joe Knapka
> On Mon, 21 Aug 2006 21:31:10 GMT, Joe Knapka <jk.u...@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
Lars
> 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.
>
>
> 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?
Pascal Costanza
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.)
Rob Thorpe
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.
Duane Rettig
> 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.
Pascal Costanza
> Pascal Costanza <p...@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.
Marcin 'Qrczak' Kowalczyk
> (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
\__/ qrc...@knm.org.pl
^^ http://qrnik.knm.org.pl/~qrczak/
joh
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?
Pascal Costanza
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 Costanza
> Duane Rettig <du...@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.
Joe Marshall
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.
Ken Tilton
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>
samth
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
Eli Barzilay
> 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!
Tom Lord
> > 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
Joe Marshall
I stand corrected!
Thomas Hafner
> 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
> 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
Pascal Bourguignon
> "Rob Thorpe" <robert...@antenova.com> wrote/schrieb <1156351259.1...@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__
William D Clinger
> 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
Hermann Jurksch
> "Rob Thorpe" <robert...@antenova.com> wrote/schrieb
> <1156351259.1...@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
Ray Dillinger
> "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
Ken Tilton
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
Rob Warnock
+---------------
| 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 <URL:news:j4GdnazAuoV9MEfZ...@speakeasy.net>
for a small code example.
-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Ken Tilton
Rob Warnock wrote:
> Ken Tilton <kent...@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".
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
Rob Thorpe
> "Rob Thorpe" <robert...@antenova.com> wrote/schrieb <1156351259.1...@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.
Anton van Straaten
> 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
Javier
> 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? ;-)
Ray Dillinger
>
>
> 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.
Ken Tilton
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