Lisp & SICP
Shelly Somerville
Question: If one is to undertake studying SICP is it best to use Scheme or
translate the exercises to Lisp, given that I know little of Scheme.
Regards John
Christopher Browne
>I often read that SICP is a 'must' for a programmer's reading list.
>Question: If one is to undertake studying SICP is it best to use Scheme or
>translate the exercises to Lisp, given that I know little of Scheme.
SICP doesn't use terribly "deep" aspects of Scheme; certainly nothing
that would be greatly injurious of your moving to Lisp.
It would probably be a not-too-bad idea to translate the exercises to
Lisp; that has the merit of better understanding some of the differences
between Scheme and CL.
--
"The wrath of Holloway is nothing compared to the wrath of Moon."
-- Fred Drenckhahn
cbbr...@ntlug.org - - <http://www.ntlug.org/~cbbrowne/lsf.html>
Andrew Cooke
Shelly Somerville <somer...@uniserve.com> wrote:
> I often read that SICP is a 'must' for a programmer's reading list.
> Question: If one is to undertake studying SICP is it best to use
Scheme or
> translate the exercises to Lisp, given that I know little of Scheme.
Translating would be easy, apart from the code that uses continuations
(which exist in Scheme, but not Common Lisp, afaik). Similarly,
learning Scheme would be easy - it's pretty much a subset of Common Lisp
"plus" a single namespace (hence no need for apply etc) and
continuations (it may have other stuff, but those were the only
differences I noticed when I read SICP). The book includes an
introduction to Scheme.
It's also a pretty good read even if you don't do any of the
programming.
Andrew
PS Incidentally, I'd rate the book by Cousineau and Mauny (with
"Functional Programming" in the title) as similar in quality, with the
differences that it's more rigorous (more abstract notation, more maths
in the code) and uses a dialect of ML (I won't say whether these are
advantages or disadvantages :-) - I think I've learned from both (if
you're going to read both, read SICP first).
Sent via Deja.com http://www.deja.com/
Before you buy.
Erik Naggum
| I often read that SICP is a 'must' for a programmer's reading list.
| Question: If one is to undertake studying SICP is it best to use
| Scheme or translate the exercises to Lisp, given that I know little
| of Scheme.
You'll learn Scheme from the book. It is best to do the exercises
in Scheme and go with the flow of the book rather than try to map it
to a real Lisp. The concepts are very well taught within the Scheme
framework, but they must be reapplied in the Common Lisp framework.
In my opinion, the book is a must because it does such a good job of
teaching its concepts in its own well-established context, but the
choice of Scheme is a very serious drawback to applying some of the
concepts to non-Scheme contexts, such as the real world. The same
argument applies to Donald Knuth: The Art of Computer Programming
and its choice of the MIX assembler, which it is also a mistake to
translate into different languages while reading.
#:Erik
--
If this is not what you expected, please alter your expectations.
William Deakin
> ...Incidentally, I'd rate the book by Cousineau and Mauny (with
> "Functional Programming" in the title)...
Is this `The Functional Approach to Programming' by Guy Cousineau and Michel
Mauny?
Best Regards,
:) will
Martin Cracauer
>In article <391E9C25...@uniserve.com>,
> Shelly Somerville <somer...@uniserve.com> wrote:
>> I often read that SICP is a 'must' for a programmer's reading list.
>> Question: If one is to undertake studying SICP is it best to use
>Scheme or
>> translate the exercises to Lisp, given that I know little of Scheme.
>Translating would be easy, apart from the code that uses continuations
>(which exist in Scheme, but not Common Lisp, afaik).
I'm afraid I have to disagree here. Many interesting things in SICP
use continuations and you can't leave them out since later things
build on the knowledge you gained.
You could use the call/cc - emulating Common Lisp macros from Norvig,
Graham or Siskind to do the SICP things in Common Lisp, but that is
really an advanced programming task. It certainly can't be done
without understand the concepts that SICP tries to communicate.
So, to learn programming using SICP, I'd say you have to use Scheme.
If you want to deepen your understanding of the paradigms in SICP and
the other advanced Lisp books, it would be a great exercise to do SICP
with Common Lisp like I outlined above. Afterwards.
Having said this, while I don't question the quality of SICP, I found
it hard to do through for myself since I always need a larger
application requirement for a paradigm until I can understand it. My
brain can't make use of paradigms that I didn't feel a need for in
advance.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <crac...@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Andrew Cooke
w.de...@pindar.com wrote:
> Andrew Cooke wrote:
>
> > ...Incidentally, I'd rate the book by Cousineau and Mauny (with
> > "Functional Programming" in the title)...
>
> Is this `The Functional Approach to Programming' by Guy Cousineau and
Michel
> Mauny?
yep, that's it. it's available in english translation (actually, the
translation could be better, but it's not bad).
thanks,
andrew
Andrew Cooke
crac...@counter.bik-gmbh.de (Martin Cracauer) wrote:
> Andrew Cooke <and...@andrewcooke.free-online.co.uk> writes:
>
> >In article <391E9C25...@uniserve.com>,
> > Shelly Somerville <somer...@uniserve.com> wrote:
> >> I often read that SICP is a 'must' for a programmer's reading list.
> >> Question: If one is to undertake studying SICP is it best to use
> >Scheme or
> >> translate the exercises to Lisp, given that I know little of
Scheme.
>
> >Translating would be easy, apart from the code that uses
continuations
> >(which exist in Scheme, but not Common Lisp, afaik).
>
> I'm afraid I have to disagree here. Many interesting things in SICP
> use continuations and you can't leave them out since later things
> build on the knowledge you gained.
Sorry - I couldn't remember how much used continuations (isn't it "just"
a Prolog-like thing?).
(Am I alone in wondering if continuations are a poor-mans substitute for
decent multi-threading? Is this just because I don't know much about
them, but have used threads a fair amount in Java? Do others find
continuations conceptually simpler than threads? Can continuations do
something that threads don't? I do realise that threads are still not
sufficiently lightweight for many cases where continuations might be
useful, but to the extent that SICP is a teaching book, would threads
have made things easier to understand?)
But as I also said, you can pick up a lot without typing anything (you
learn enough Scheme on the way to read it).
> Having said this, while I don't question the quality of SICP, I found
> it hard to do through for myself since I always need a larger
> application requirement for a paradigm until I can understand it. My
> brain can't make use of paradigms that I didn't feel a need for in
> advance.
Having read something still helps, doesn't it? Maybe it's just me, but
it often takes a few good shoves to get a new idea solidly stuck inside
my head. Reading something helps prepare the way - when you come to
write a program that does require something you've read about you (well,
I) get a kind of "ahhh, yes, of course" feeling, rather than - if this
is the first time I've met the idea - a "oh god, what on earth is this"
sinking in the stomach...
Andrew
Michael Hudson
> Andrew Cooke <and...@andrewcooke.free-online.co.uk> writes:
>
> >In article <391E9C25...@uniserve.com>,
> > Shelly Somerville <somer...@uniserve.com> wrote:
> >> I often read that SICP is a 'must' for a programmer's reading list.
> >> Question: If one is to undertake studying SICP is it best to use
> >Scheme or
> >> translate the exercises to Lisp, given that I know little of Scheme.
>
> >Translating would be easy, apart from the code that uses continuations
> >(which exist in Scheme, but not Common Lisp, afaik).
>
> I'm afraid I have to disagree here. Many interesting things in SICP
> use continuations and you can't leave them out since later things
> build on the knowledge you gained.
>
> You could use the call/cc - emulating Common Lisp macros from Norvig,
> Graham or Siskind to do the SICP things in Common Lisp, but that is
> really an advanced programming task. It certainly can't be done
> without understand the concepts that SICP tries to communicate.
Umm, SICP doesn't use call/cc. It uses continuations in some of the
evaluators in chapter 4, but they work in a kind of CPS. I fail to
see why they'd be difficult to translate to Common Lisp, but you'd
need to make sure you were getting the tail-call optimisation before
it made sense.
Cheers,
M.
--
6. Symmetry is a complexity-reducing concept (co-routines include
subroutines); seek it everywhere.
-- Alan Perlis, http://www.cs.yale.edu/~perlis-alan/quotes.html
John Clonts
Andrew Cooke <and...@andrewcooke.free-online.co.uk> wrote:
> In article <391E9C25...@uniserve.com>,
> Shelly Somerville <somer...@uniserve.com> wrote:
> > I often read that SICP is a 'must' for a programmer's reading list.
> > Question: If one is to undertake studying SICP is it best to use
> Scheme or
> > translate the exercises to Lisp, given that I know little of Scheme.
>
> Translating would be easy, apart from the code that uses continuations
> learning Scheme would be easy - it's pretty much a subset of Common
Lisp
> "plus" a single namespace (hence no need for apply etc) and
> continuations (it may have other stuff, but those were the only
> differences I noticed when I read SICP). The book includes an
> introduction to Scheme.
Hmmm, okay, I'm learning scheme studying SICP. I think I understand
what you mean that scheme has the single namespace where lisp has
various namespaces. But, why does it follow that "hence no need for
apply etc"? (I see that it *has* apply--??) And, what are some of the
"etceteras" that you refer to that are also needed or not needed because
of the multiple-vs-single-namespace difference in the two languages.
Thank you in advance for elaborating on this...
Cheers,
John
Erik Naggum
| I think I understand what you mean that scheme has the single
| namespace where lisp has various namespaces. But, why does it
| follow that "hence no need for apply etc"?
He's seriously confused. It's _funcall_ that's missing from Scheme.
It obviously still needs, and has, apply, which is why omitting
funcall is just plain silly. (Note to Scheme zealots: Just because
you can define it doesn't mean the _language_ has it. Thank you.)
Andrew Cooke
Erik Naggum <er...@naggum.no> wrote:
> * John Clonts -> Andrew Cooke
> | I think I understand what you mean that scheme has the single
> | namespace where lisp has various namespaces. But, why does it
> | follow that "hence no need for apply etc"?
>
> He's seriously confused. It's _funcall_ that's missing from Scheme.
> It obviously still needs, and has, apply, which is why omitting
> funcall is just plain silly. (Note to Scheme zealots: Just because
> you can define it doesn't mean the _language_ has it. Thank you.)
I'm not sure what the difference between confused and seriously confused
is, but sorry for getting the name wrong (not used Lisp for a while) - I
meant that in Common Lisp you have to explicitly call a function when
passed into a routine; in Scheme it's not necessary.
(It makes CL code look comparatively more messy, but how can you cope
without variable names like "list"?! ;-)
Andrew
PS maybe seriously confused means something like "sufficiently clear for
Erik to understand what I meant". In which case I guess the use of
"seriously" leaves me irreverently confused. Or something.
Andrew K. Wolven
"Essentials of Programming Languages" by Friedman, Wand, and Haynes.
Should I get the SICP book?? I am doing CL these days but like Scheme
(for the usual reasons).
What is the best book to reel hackers into Lisp?
Erik Naggum wrote:
> * Shelly Somerville <somer...@uniserve.com>
> | I often read that SICP is a 'must' for a programmer's reading list.
> | Question: If one is to undertake studying SICP is it best to use
> | Scheme or translate the exercises to Lisp, given that I know little
> | of Scheme.
>
> You'll learn Scheme from the book. It is best to do the exercises
> in Scheme and go with the flow of the book rather than try to map it
> to a real Lisp. The concepts are very well taught within the Scheme
> framework, but they must be reapplied in the Common Lisp framework.
> In my opinion, the book is a must because it does such a good job of
> teaching its concepts in its own well-established context, but the
> choice of Scheme is a very serious drawback to applying some of the
> concepts to non-Scheme contexts, such as the real world. The same
> argument applies to Donald Knuth: The Art of Computer Programming
> and its choice of the MIX assembler, which it is also a mistake to
> translate into different languages while reading.
>
Erik Naggum
| I'm not sure what the difference between confused and seriously
| confused is, but sorry for getting the name wrong (not used Lisp for
| a while) - I meant that in Common Lisp you have to explicitly call a
| function when passed into a routine; in Scheme it's not necessary.
If you haven't used Lisp for a while, it's a very good idea to make
sure the answers you give in a public forum are not "buggy".
| (It makes CL code look comparatively more messy, but how can you cope
| without variable names like "list"?! ;-)
Please bad-mouth Common Lisp in comp.lang.scheme -- there's no value
in having random Schemers talk about "messy" here. I'll take care
of bad-mouthing Scheme here in exchange for you take it elsewhere.
Personally, I find it interminably unnerving to see arguments to
functions crop up in the functional position, because it means
whatever is in the functional position everywhere has to be compared
to the arguments, as well as all the lexical bindings. Using a
simple syntactical vehicle like funcall to communicate the intent of
using a _variable_ as a function as opposed to the standard meaning
of the named symbol is obviously a really good idea, and it would
have made Scheme much more palatable had it differentiated between
the "global" values of symbols and the lexical values defined within.
| PS maybe seriously confused means something like "sufficiently clear
| for Erik to understand what I meant".
That's about as smart an explanation as confusing apply with funcall.
If you don't want to be labeled seriously confused, a good thing to
do is to pay more attention to detail, not even less than before.
Chuck Fry
> He's seriously confused. It's _funcall_ that's missing from Scheme.
Maybe I'm ignorant. It seems to me that Scheme has an implicit funcall.
Just how does standard function application in Scheme differ from
funcall?
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
chu...@chucko.com (text only please) chuc...@home.com (MIME enabled)
Lisp bigot, car nut, photographer, sometime guitarist and mountain biker
The addresses above are real. All spammers will be reported to their ISPs.
Erik Naggum
| Maybe I'm ignorant. It seems to me that Scheme has an implicit
| funcall.
To recap: Andrew Cooke said Scheme didn't need _apply_. That's
bogus -- Scheme doesn't "need" funcall because of its "single
namespace" mistake. However, the reduced need for funcall didn't
arise because of the reduction of namespaces -- it makes sense to
retain this mechanism even if you have only one namespace.
I don't think an implicit funcall is anything but a great loss, and
certainly do _not_ think it's a feature. I think it makes code
harder to read and a lot messier by virtue of crowding _my_ brain's
namespace (which matters more to me than the compiler's). Actually,
I think the missing funcall is just one more of Scheme's many, many
misguided shots at a pointless notion of "elegance by taking away".
Seth Gordon
> It seems to me that Scheme has an implicit funcall.
> Just how does standard function application in Scheme differ from
> funcall?
Common Lisp has separate namespaces for functions and variables, whereas Scheme
puts them both in the same namespace. This means that in Scheme, you can write
;;; untested
(define silly
(lambda (switch arg1 arg2)
((if switch + *) arg1 arg2)))
In Scheme, this function will return either the sum or the product of arg1 and
arg2, depending on whether switch is true or false. In Common Lisp, to achieve
the same result, you'd need to do something like this:
;;; untested
(defun (silly switch arg1 arg2)
(funcall (if switch (function +) (function *)) arg1 arg2))
;;; cf. Queinnec, _Lisp In Small Pieces_, p. 37
In Common Lisp, when used as plain old variables rather than as functions, +
returns the last expression read and and * returns the last result returned.
--
--Why is it that most kids are attracted to computers while
most adults are quite wary of computers?
--Most adults are smarter than most kids. ["Ask Uncle Louie"]
== seth gordon == sgo...@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
David Bakhash
> * Chuck Fry
> | Maybe I'm ignorant. It seems to me that Scheme has an implicit
> | funcall.
>
> I don't think an implicit funcall is anything but a great loss, and
> certainly do _not_ think it's a feature. I think it makes code
> harder to read and a lot messier by virtue of crowding _my_ brain's
> namespace (which matters more to me than the compiler's). Actually,
> I think the missing funcall is just one more of Scheme's many, many
> misguided shots at a pointless notion of "elegance by taking away".
admittedly, this is *exactly* how I feel, and why going from Scheme to
Lisp was so pleasureable. I dislike Scheme almost as much as C, though
most CL programmers don't feel this strongly. Granted I prefer Scheme,
but still. the missing funcall "feature" is absolutely annoying to me.
Furthermore, I don't think that:
(funcall func arg1 arg2 arg3)
is messy in the slightest. Nor do I think that something like
(function format)
or the reader macro version:
#'format
is "messy". It tells you that you're dealing with a function. That's a
good thing, for sure. The Scheme people are ass backwards in this
respect, though I agree that it's a matter of opinion.
CL is 10X more readable than Scheme. Also, because Scheme is missing so
many basic features, programmers have to to through hell to write useful
Scheme code, and it's much messier than CL, by far. I'm surprised that
Scheme survived.
Of course, Scheme is much easier to implement, which I think has its
benefit.
dave
Hartmann Schaffer
Erik Naggum <er...@naggum.no> writes:
> * John Clonts -> Andrew Cooke
>| I think I understand what you mean that scheme has the single
>| namespace where lisp has various namespaces. But, why does it
>| follow that "hence no need for apply etc"?
>
> funcall is just plain silly. (Note to Scheme zealots: Just because
why is omitting funcall silly? i thought this was taken care of by the
rule that you can put any expression in the first position of a list
> you can define it doesn't mean the _language_ has it. Thank you.)
>
> #:Erik
--
Hartmann Schaffer
Erik Naggum
| why is omitting funcall silly? i thought this was taken care of by the
| rule that you can put any expression in the first position of a list
I happen to think that rule is silly, too. It has certain merit in
terms of regularity, but in terms of usability, it offers nothing
and saves nothing. On the contrary, using "funcall" as the first
position in a list where the value is variable, as opposed to a
relative constant in that context, communicates a _variable_. Of
course, I realize that this goes against the grain of Scheme, but
then again, I don't like Scheme, and this rule is one of the reasons.
Chuck Fry
Seth Gordon <sgo...@kenan.com> wrote:
>Chuck Fry wrote:
>> It seems to me that Scheme has an implicit funcall.
>> funcall?
>
>Common Lisp has separate namespaces for functions and variables, whereas Scheme
Right, I knew that, plus the fact that in Scheme function calls, the
function position is evaluated same as the argument positions.
So, what I was asking is, how does this differ *semantically* from an
explicit FUNCALL function, discounting the obvious lack of the syntactic
marker (the FUNCALL name)?
Barry Margolin
Chuck Fry <chu...@best.com> wrote:
>So, what I was asking is, how does this differ *semantically* from an
>explicit FUNCALL function, discounting the obvious lack of the syntactic
>marker (the FUNCALL name)?
Very little. There are some minor details like the fact that CL specifies
left-to-right argument evaluation, whereas Scheme doesn't specify the order
of argument evaluation.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Erik Naggum
| So, what I was asking is, how does this differ *semantically* from an
| explicit FUNCALL function, discounting the obvious lack of the syntactic
| marker (the FUNCALL name)?
Which semantics are we using today? If an expression communicates
something different from another expression to human readers, but do
not cause a compiler or interpreter to do anything differently,
arguing that it has no "semantic" difference is ill-conceived, as we
do not program only for the compiler or interpreter. Using funcall
communicates "evaluate the second position for its functional value"
(just like apply). Not using funcall means that the first position
is never "stable" and can never be trusted. This is a semantic
difference in the language communicated to the human readers.
Eli Barzilay
> [...]
> Not using funcall means that the first position is never "stable"
> and can never be trusted. This is a semantic difference in the
> language communicated to the human readers.
Except that you can modify functions, and you have lexical bindings
for functions, which makes it exactly as "stable" as plain variables.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.cs.cornell.edu/eli/meaning.html Maze is Life!
Erik Naggum
| Not using funcall means that the first position is never "stable"
| and can never be trusted. This is a semantic difference in the
| language communicated to the human readers.
* Eli Barzilay <e...@mojave.cs.cornell.edu>
| Except that you can modify functions, and you have lexical bindings
| for functions, which makes it exactly as "stable" as plain variables.
I take exception with "exactly as", but I get the impression that
you still think I'm discussing Scheme in that sentence, where I'm
contrasting real Lisps (which have funcall) to Scheme.
Eli Barzilay
> * Erik Naggum
> | Not using funcall means that the first position is never "stable"
> | and can never be trusted. This is a semantic difference in the
> | language communicated to the human readers.
>
> * Eli Barzilay <e...@mojave.cs.cornell.edu>
> | Except that you can modify functions, and you have lexical bindings
> | for functions, which makes it exactly as "stable" as plain variables.
>
> I take exception with "exactly as", but I get the impression that
> you still think I'm discussing Scheme in that sentence, where I'm
> contrasting real Lisps (which have funcall) to Scheme.
I'm perfectly aware of that - you said in the above that not having
funcall makes the first position be unstable ==> in other words:
having funcall (and seperate function/variable namespaces) makes the
first position stable. I said that this argument is irrelevant since
you can do with function bindings whatever you do with variable
bindings (rebind globals, and have lexical bindings).
So I think that the only thing that is "stable" is the fact that you
have an explicit notation for playing with functions. It looks like
you say that this makes you happy because it is easier for you to read
& write code that way. If this is the case, then all further
discussion is bound to be nothing more than a holy war: others will
say that writing in Scheme gives you easier code capabilities
_because_ of the uniform treatment of all positions (and it will
definitely be a stupid idea to implement funcall in Scheme to prove
any point).
Matt Curtin
Andrew> Should I get the SICP book?? I am doing CL these days but
Andrew> like Scheme (for the usual reasons).
Yes, you should get SICP. It's one of the "must read" texts that
everyone who calls himself a programmer should have read at some
point. If you like Scheme, you'll find it a particularly good read.
I'm not especially fond of Scheme -- I like it much better than many
alternatives, but given my choice between Common Lisp and Scheme, I'll
always choose the former -- but I do recommend the book highly and I
tell people reading the book to learn Scheme so they can do the
exercises. Trying to do them in another language will turn your focus
away from the concepts you're supposed to be dealing with and toward
how to get your-favorite-language(tm) to behave like Scheme so the
exercises can be done.
Andrew> What is the best book to reel hackers into Lisp?
I recommend Graham's ANSI Common Lisp (ACL) as the first book. It
does a nice job of introducing the language and giving a feel for how
Lisp "should" work. I have OnLisp but haven't spent much time with
it. After a cursory look, though, I'd say it's a nice followup to
ACL. From there, I like to point people to other goodies like
Norvig's PAIP. If someone is expecting to be able to read one book
and understand Lisp, this method will be disappointing. But I don't
subscribe to the belief that one can read a single text and really
understand any language.
Languages, whether natural or programming, are best understood _after_
they're initially "learned", by becoming familiar with the history,
culture, and literature of the language and its users. I assert that
reading a single text and hoping to become fluent in Common Lisp is
equally as ridiculous as hoping to become fluent in Russian by reading
a single text.
--
Matt Curtin cmcu...@interhack.net http://www.interhack.net/people/cmcurtin/
Andrew K. Wolven
Matt Curtin wrote:
I would like to point out that I was not interested in computer programing until
I saw Symbolics Genera and read Essentials of Programing Languages.
After I read how lambda calculus works and beta-conversion I felt well armed to
read lisp books of any dialect.
Erik Naggum
| I'm perfectly aware of that - you said in the above that not having
| funcall makes the first position be unstable ==> in other words:
| having funcall (and seperate function/variable namespaces) makes the
| first position stable.
| I said that this argument is irrelevant since you can do with
| function bindings whatever you do with variable bindings (rebind
| globals, and have lexical bindings).
Apparently, the issue here is whether it's "stable" or "stabler". I
don't tend to think in absolute terms in the first place, so it is a
little foreign to me to have to distinguish the two, but it seems
that the "irrelevance" is that there is a mechanism to reduce the
stability of the first position even in real Lisps. The _relevance_
is to which degree this actually happens, and since we don't bind
functional values all that often in Common Lisp, I stand by the
"stable" argument, but if you want me to modify to "stabler", that
makes absolutely no difference to me.
| So I think that the only thing that is "stable" is the fact that you
| have an explicit notation for playing with functions. It looks like
| you say that this makes you happy because it is easier for you to
| read & write code that way. If this is the case, then all further
| discussion is bound to be nothing more than a holy war: others will
| say that writing in Scheme gives you easier code capabilities
| _because_ of the uniform treatment of all positions (and it will
| definitely be a stupid idea to implement funcall in Scheme to prove
| any point).
Look, here's the deal: I don't like Scheme, and I wanted to explain
why in this particular context. If this is how holy wars start, I'd
venture that the propensity to want absolutes has much to do with it.
It is unlikely that I will change my mind on Scheme, by the way. It
is a grand monument to a certain concept of language design, which I
think sucks monumentally and should be left behind, but learned from
if we can so we can avoid similar silly qstunts in the future.
Barry Margolin
>* Eli Barzilay <e...@mojave.cs.cornell.edu>
>| I'm perfectly aware of that - you said in the above that not having
>| funcall makes the first position be unstable ==> in other words:
>| having funcall (and seperate function/variable namespaces) makes the
>| first position stable.
>
>| I said that this argument is irrelevant since you can do with
>| function bindings whatever you do with variable bindings (rebind
>| globals, and have lexical bindings).
>
> Apparently, the issue here is whether it's "stable" or "stabler". I
> don't tend to think in absolute terms in the first place, so it is a
> little foreign to me to have to distinguish the two, but it seems
> that the "irrelevance" is that there is a mechanism to reduce the
> stability of the first position even in real Lisps. The _relevance_
> is to which degree this actually happens, and since we don't bind
> functional values all that often in Common Lisp, I stand by the
> "stable" argument, but if you want me to modify to "stabler", that
> makes absolutely no difference to me.
This argument is somewhat circular.
One of the reasons that Scheme proponents give for the single namespace and
lack of FUNCALL is that they don't want programmers to think of functional
binding as any more special than variable binding. They want to encourage
programming styles that make use of first-class functions by making it as
convenient and natural to use expressions that return functions as it is
when dealing with expressions that return other types of values. As a
result of this, Scheme programmers may be more likely to bind functional
values, so the "degree to which this actually happens" is likely to be
higher in Scheme than CL. Languages and programming paradigms evolve
together.
Lieven Marchand
> Of course, Scheme is much easier to implement, which I think has its
> benefit.
Scheme is in the same situation as Forth, that every programmer starts
with implementing his own version. It has been harmful for both
languages since implementing a stable, mature, fully featured language
environment is not that easy, which makes most implementations
beginners encounter to be underdocumented, underfeatured and unfit for
serious development. And then they blame it generally on the
language. Common Lisp is better off with a few quality
implementations.
--
Lieven Marchand <m...@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
Jeff Dalton
> > ... since we don't bind
> > functional values all that often in Common Lisp, I stand by the
> > "stable" argument, but if you want me to modify to "stabler", that
> > makes absolutely no difference to me.
>
> This argument is somewhat circular.
>
> One of the reasons that Scheme proponents give for the single namespace and
> lack of FUNCALL is that they don't want programmers to think of functional
> binding as any more special than variable binding. They want to encourage
> programming styles that make use of first-class functions by making it as
> convenient and natural to use expressions that return functions as it is
> when dealing with expressions that return other types of values. As a
> result of this, Scheme programmers may be more likely to bind functional
> values, so the "degree to which this actually happens" is likely to be
> higher in Scheme than CL. Languages and programming paradigms evolve
> together.
"Somewhat", ok, but still binding function names to function constants
using FLET or LABELS is as easy in Common Lisp, if not easier, than
using LET/RECLET to bind them in Scheme; and no FUNCALL need be used
to call them.
Indeed, FLET/LABELS and SETF of SYMBOL-FUNCTION are the only ways the
"function position" becomes less than "stable". There's no assignment
to local function names at all, a pretty strong guarantee of
"stability", it seems to me.
Nested DEFINE in Scheme probably is essier than CL LABELS, but not by
much.
So ... that leaves us with the binding of names to computed function
values. That's awkward in Common Lisp (though a little macro could
make it easier), and so it might be a significant reason for more
binding of function names in Scheme. (I wonder how much it actually
is?)
But in the absence of such "little macros", this case doesn't affect
the stability of the function position in Common Lisp at all.
Harold Carr
The Functional Approach to Programming
By Cousineau, Guy / Mauny, Michel
List Price: $41.95 (Softcover)
Published by Cambridge University Press
Date Published: 04/1998
ISBN: 0521576814
>PS Incidentally, I'd rate the book by Cousineau and Mauny (with
>"Functional Programming" in the title) as similar in quality, with the
>differences that it's more rigorous (more abstract notation, more maths
>in the code) and uses a dialect of ML (I won't say whether these are
>advantages or disadvantages :-) - I think I've learned from both (if
>you're going to read both, read SICP first).
Harley Davis
Erik Naggum <er...@naggum.no> wrote in message
news:31674532...@naggum.no...
> * Chuck Fry
> | So, what I was asking is, how does this differ *semantically* from an
> | explicit FUNCALL function, discounting the obvious lack of the syntactic
> | marker (the FUNCALL name)?
>
> Which semantics are we using today? If an expression communicates
> something different from another expression to human readers, but do
> not cause a compiler or interpreter to do anything differently,
> arguing that it has no "semantic" difference is ill-conceived, as we
> do not program only for the compiler or interpreter. Using funcall
> communicates "evaluate the second position for its functional value"
> is never "stable" and can never be trusted. This is a semantic
> difference in the language communicated to the human readers.
Unless you are writing very deeply nested functions and use a lot of
shadowed variable names, or unless you are passing around a lot of functions
as arguments, the functional position in Scheme expressions is quite stable.
If you have doubts you can look up the lexical scope of the expression to
see if there is any shadowing. My experience is that in practice this is
not much of an issue, because most programmers are wise enough not to rebind
standard names, but I have a bias for the multiple namespace system because
I agree that it is marginally clearer for the human to see an explicit
function call when using functional arguments or computed functions.
-- Harley
Barry Margolin
Jeff Dalton <je...@todday.aiai.ed.ac.uk> wrote:
>So ... that leaves us with the binding of names to computed function
>values. That's awkward in Common Lisp (though a little macro could
>make it easier), and so it might be a significant reason for more
>binding of function names in Scheme. (I wonder how much it actually
>is?)
It's not just binding of names that's the issue. Scheme encourages use of
higher-order functions; for instance, you can write:
((complement =) x y)
rather than
(funcall (complement #'=) x y)
To Schemers, the lack of a special marker implies that this is a more
"natural"; FUNCALL suggest "Ooh, watch out, I'm doing something weird
here", and I don't think they want students to think of higher-order
functions as something weird. I haven't read it in a long time, but I
think SICP has sections on higher-order programming, currying, etc. which
take advantage of this.