Yoann Padioleau wrote:
> I am not sure call/cc was in scheme from the beginning.
Continuations were in Scheme from the beginning, or at least from the
earliest papers about Scheme.
The 1975 paper, "Scheme - An Interpreter for Extended Lambda Calculus", MIT
AI Lab Memo No. 349, talks explicitly about continuations, shows programs
implemented in continuation-passing style, and references a related 1972
Reynolds paper which apparently discusses continuations.
The Scheme language at that time had an escape operator called CATCH, which
was very similar to call/cc: (CATCH tag thunk) invoked thunk with a variable
'tag' which was bound to the current continuation. This can be defined in
R5RS Scheme as follows:
(define-syntax CATCH
(syntax-rules ()
((CATCH cont-tag thunk)
(call/cc (lambda (cont-tag) (thunk))))))
> Many things were added to lisp after (true closure, oo, multimethod,
macro, ...)
> and lisp is still a good langage.
Yes, Scheme and Lisp share many of the features that make it possible to do
this. Many other languages are not as fortunate.
> > which along with a built-in syntax reader,
> > contributes to the ability for programs to easily read and manipulate
other
> > programs.
>
> perl have eval which allow too this kind of thing.
You misunderstand. Write me a Perl program which reads another Perl program
and makes meaningful transformations to it. Then we'll compare that to an
equivalent Scheme program.
> > * A very regular syntax,
>
> many people dont like that at all.
That's their choice, but they limit their options by that choice - it
doesn't make the benefits of such a syntax disappear.
> > * Related to the above point, code and data are represented using the
same
> > syntax, which aside from the benefits for automated manipulation of
> > programs, also makes it very easy to persist high-level structures in a
very
>
> can do that easyly too with perl eval and Data::Dumper.
That might be true if Perl *had* usable high-level structures. Perl's
reference semantics tend to limit its use of sophisticated structures, in
practice.
Also, using eval for this purpose is overkill, and goes to my point about
Scheme's performance. You shouldn't need eval to read syntax.
> > Macros take advantage of this capability, but it can be
>
> sure, that is what i said, the only true advantage of scheme over other
langage
> is its powerful macro system.
...
> True (related to the powerful macro system).
One of the points of my message is that the powerful macro system is
essentially an offshoot of lower-level design decisions in Scheme, including
the regular syntax, the ability to automatically manipulate code, etc.
These features are useful independent of macros, and macros are only one
possible application of these features. Related to this, macros would not
be as useful or support as many possible extensions if it weren't for other
features of Scheme, and the way in which they are all integrated.
So, to say that:
"the only true advantage of scheme over other langages is its powerful
macro system"
...is the same as saying:
"the only true advantages of scheme over other langages are the
well-integrated set of features which work together to support a powerful
macro system",
which is the same as saying:
"the only true advantages of scheme over other langages are the
well-integrated set of features of the scheme language".
(which is more or less what the SCSH FAQ is trying to say in that section :)
> > This
> > is partly because the functional paradigm supports automated "algebraic"
> > program transformations that can be performed by compilers in order to
> > achieve better performance, and allows programs to be translated into
> > lower-level languages in the most efficient possible ways.
>
> Hmmm, functionnal zealots say this for about 20 years, and never
> succeed i think.
I think you think wrong. Modern compilers make use of these techniques even
for non-functional languages, such as C++, by converting source code into
forms such as Static Single Assignment (SSA) form, a mutation-free
functional form. They do this so that they can benefit from the algebraic
transformations that then become possible.
As David Rush pointed out, some of the fastest compilers around are
functional. See Doug Bagley's shootout (e.g.
http://www.bagley.org/~doug/shootout/craps.shtml) for some demonstrations of
this. The point is not that these compilers are always faster than C -
although they can be, for non-trivial applications - but that they are very
high-level, so enable the programmer to develop in a high-level style,
making use of sophisticated abstractions, and yet still obtain excellent
performance.
Anton
|