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.
Regards John
Centuries ago, Nostradamus foresaw a time when Shelly Somerville would say:
>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
········@ntlug.org - - <http://www.ntlug.org/~cbbrowne/lsf.html>
In article <·················@uniserve.com>,
Shelly Somerville <··········@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.
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?
Best Regards,
:) will
In article <·················@pindar.com>,
········@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
Sent via Deja.com http://www.deja.com/
Before you buy.
Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
>In article <·················@uniserve.com>,
> Shelly Somerville <··········@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 <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
In article <·············@counter.bik-gmbh.de>,
········@counter.bik-gmbh.de (Martin Cracauer) wrote:
> Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
>
> >In article <·················@uniserve.com>,
> > Shelly Somerville <··········@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
Sent via Deja.com http://www.deja.com/
Before you buy.
In article <············@nnrp1.deja.com>,
Andrew Cooke <······@andrewcooke.free-online.co.uk> wrote:
>(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 found threads conceptually simpler than continuations at first,
perhaps because threads were explained in terms of processes while
continuations weren't explained in terms of anything I understood.
On second thought, I think threads are still conceptually simpler than
continuations, but maybe that's because my mind is hopelessly
imperative.
You can do some things with continuations that threading doesn't do ---
for example, throw/catch is doable with continuations. (call/cc is
analogous to if (setjmp()), and calling the continuation is analogous
to longjmp(), in this case.)
I'm not sure what upward continuations are good for, though, other than
cooperative multithreading and deliberately obscure code. There are
surely some things.
--
<······@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
In article <······················@news-east.usenetserver.com>,
······@dnaco.net (Kragen Sitaker) wrote:
> You can do some things with continuations that threading doesn't do
> for example, throw/catch is doable with continuations. (call/cc is
> analogous to if (setjmp()), and calling the continuation is analogous
> to longjmp(), in this case.)
i see your point, but here's an interesting variation:
i'm looking at oz/mozart which appears (i've not even finished reading
the docs and haven't written a line of code so take this with a large
pinch of salt) to have *very* lightweight threads (lightweight to the
point where you use one whenever it takes your fancy) and the concept of
spaces which are hierarchical collections of state (if you're running in
a subspace then any new values in the subspace shadow higher space
values, but are invisible to threads in higher levels).
spaces let you do a calculation (in a subspace) and then either discard
it or merge the subspace (take the results into the parent space).
i think this lets you do the same kind of thing as throw/catch (by
discarding the subspace) without continuations. alternatively, you
could argue that spaces are continuations looked at in a mirror.
since oz/mozart also has exceptions my reasoning seems even more
muddled, but i hope you get my drift...
andrew
ps http://www.mozart-oz.org/
Sent via Deja.com http://www.deja.com/
Before you buy.
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> Andrew Cooke <······@andrewcooke.free-online.co.uk> writes:
>
> >In article <·················@uniserve.com>,
> > Shelly Somerville <··········@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
In article <············@nnrp1.deja.com>,
Andrew Cooke <······@andrewcooke.free-online.co.uk> wrote:
> In article <·················@uniserve.com>,
> Shelly Somerville <··········@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.
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
Sent via Deja.com http://www.deja.com/
Before you buy.
* 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.)
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
> 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
······@chucko.com (text only please) ········@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.
* Chuck Fry
| 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".
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.no> writes:
> * 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
David Bakhash <·····@alum.mit.edu> writes:
> 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 <···@bewoner.dma.be>
If there are aliens, they play Go. -- Lasker
You are partially correct. FORTH has suffered just for the reason you
give; however several superb versions of FORTH exist, (or did exist).
Some amongst others were Laboratory Microsystems Inc., and FORTH Inc.
among others. I think the same thing happened with Prolog, I own several
dogs i.e. implementations which did not perform as promised, and because
of this the language lost its appeal to me.
Returning to Common Lisp: I was attracted to CL because of the
perfomance of XLisp-Stat. It gives a real feel for Object oreinted
programming and makes the solution of problems quite tractable. I find
it much harder to arrive at any conclusion regarding commercial
implementations. The crippled versions offered as freeware or shareware
are incomplete with respect to documentation: documentation is poor, not
up-to-date with respect to the current version, or it is in hypertext
which is not the best in my view.
I apologize for the diversions.
Regards John
Lieven Marchand wrote:
> David Bakhash <·····@alum.mit.edu> writes:
>
> > 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 <···@bewoner.dma.be>
> If there are aliens, they play Go. -- Lasker
Chuck Fry wrote:
> 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 == ·······@kenan.com == standard disclaimer ==
== documentation group, kenan systems corp., cambridge, ma ==
In article <·················@kenan.com>,
Seth Gordon <·······@kenan.com> wrote:
>Chuck Fry wrote:
>> 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. [...]
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)?
-- Chuck
--
Chuck Fry -- Jack of all trades, master of none
······@chucko.com (text only please) ········@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.
In article <··············@nntp1.ba.best.com>,
Chuck Fry <······@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, ······@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.
* 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"
(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.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.no> writes:
> [...]
> 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 <···@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.
#:Erik
--
If this is not what you expected, please alter your expectations.
Erik Naggum <····@naggum.no> writes:
> * 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 <···@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).
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.cs.cornell.edu/eli/meaning.html Maze is Life!
* Eli Barzilay <···@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.
| 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.
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <················@naggum.no>, Erik Naggum <····@naggum.no> wrote:
>* Eli Barzilay <···@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.
--
Barry Margolin, ······@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.
Barry Margolin <······@genuity.net> writes:
> > ... 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.
In article <··············@todday.aiai.ed.ac.uk>,
Jeff Dalton <····@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.
--
Barry Margolin, ······@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.
Barry Margolin <······@genuity.net> writes:
> In article <··············@todday.aiai.ed.ac.uk>,
> Jeff Dalton <····@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.
The question I was addressing was the stability of the "function
position" - that's how we got to talking about binding of names rather
than about a million other things - and I was replying most directly
to a message from you in which your own words were:
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.
-- j
Erik Naggum <····@naggum.no> wrote in message
·····················@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"
> (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.
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
* "Harley Davis" <·············@nospam.museprime.com>
| 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.
I disagree. Reading Scheme code, I have to check for these things
all the time -- especially if I have to do so in order to assess the
programmer as "wise enough" to avoid the problem, _and_ he's aware
of the vocabulary of "standard names" that I subscribe to. (Lacking
a package system and a language useless without extensions, this is
not the same, simple issue it is in Common Lisp.)
Common Lisp has a simple rule that you can't modify the meaning of
symbols in the Common Lisp package globally. This lets me sleep
well and read code with confidence. With Scheme, I have no idea
what anything means unless I have checked. That makes me nervous,
and because it's so utterly pointless to push this and many other
problems on me as a (potential) user, I have come to dislike Scheme.
| 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.
Sometimes, the margins are all that keeps us from ... Never mind. :)
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <················@naggum.no>,
Erik Naggum <····@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"?
>
> 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
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
* ··@inferno.nirvananet (Hartmann Schaffer)
| 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.
#:Erik
--
If this is not what you expected, please alter your expectations.
In article <················@naggum.no>,
Erik Naggum <····@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.
Sent via Deja.com http://www.deja.com/
Before you buy.
* Andrew Cooke <······@andrewcooke.free-online.co.uk>
| 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.
#:Erik
--
If this is not what you expected, please alter your expectations.
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).
* Shelly Somerville <··········@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
--
If this is not what you expected, please alter your expectations.
Yesterday someone asked me to recommend a good Lisp book. I recommended
"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 <··········@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
> --
> If this is not what you expected, please alter your expectations.
>>>>> "Andrew" == Andrew K Wolven <·······@redfernlane.org> writes:
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 ········@interhack.net http://www.interhack.net/people/cmcurtin/
Matt Curtin wrote:
> >>>>> "Andrew" == Andrew K Wolven <·······@redfernlane.org> writes:
>
> 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.
>
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.
>
> --
> Matt Curtin ········@interhack.net http://www.interhack.net/people/cmcurtin/
Thank you. Do you have a reccomendation for a Scheme interpreter?
Erik Naggum wrote:
> * Shelly Somerville <··········@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
> --
> If this is not what you expected, please alter your expectations.
Centuries ago, Nostradamus foresaw a time when Shelly Somerville would say:
>Thank you. Do you have a reccomendation for a Scheme interpreter?
One of the better "somewhat integrated" environments for Scheme is
DrScheme.
It runs on U*IX, Win32, and MacOS, which represents most of the platforms
that people care about anymore. It provides a fairly sophisticated
Emacs-like editor. It has an integrated help system. It provides rather
a lot of extensions not entirely dissimilar in scope to the stuff Common
Lisp provides, and is being actively worked on.
It can also run in "CLI" mode, which means you can run it inside an
Emacs buffer, which is one of the best ways of running a Lisp session.
--
When I die, I'd like to go peacefully in my sleep like my grandfather,
not screaming in terror like his passengers...
········@ntlug.org - - <http://www.hex.net/~cbbrowne/scheme.html>
* Shelly Somerville <··········@uniserve.com>
| Thank you. Do you have a reccomendation for a Scheme interpreter?
Since I read and worked with the first edition of SICP, I am partial
to the _very_ good MIT Scheme implementation, which was also used in
the book. Since then, the second edition of SICP is out and it uses
R5RS� Scheme, MIT Scheme was no longer supported on the platforms I
use (only Microsoft-free computers!) the last time I checked, and I
have come to dislike Scheme intensely over the past 6 years or so.
I would recommend that you ask in comp.lang.scheme, and request info
on Scheme environments that are actually supported, not just toys or
research vehicles. I haven't been following the Scheme "evolution"
closely for quite some time, and wouldn't know which environments
are the better these days. All I have noticed is that there is no
change to the plethora of _really_ crummy ones implemented by people
who get a fascination with the implementability of the language
rather than its usability. (This is a reason not to use Scheme!)
Please note that although "interpreter" is not strictly _wrong_,
both Lisp and Scheme are usually compiled these days, and you are
better off if you avoid interpreter-only environments. A good
native compiler is hard to write and unlikely to be a crummy
implementation of Scheme, while an interpreter is much too easy.
Good luck with SICP, and if you decide not to hang around while you
study with Scheme: welcome back when you're ready to graduate into
Common Liop.
#:Erik
-------
� Expands to Revised Revised Revised Revised Revised Report on Scheme.
--
If this is not what you expected, please alter your expectations.
Centuries ago, Nostradamus foresaw a time when Erik Naggum would say:
> Please note that although "interpreter" is not strictly _wrong_,
> both Lisp and Scheme are usually compiled these days, and you are
> better off if you avoid interpreter-only environments. A good
> native compiler is hard to write and unlikely to be a crummy
> implementation of Scheme, while an interpreter is much too easy.
One problem with most of the Schemes is that the way they generate
_machine code_ (versus some form of byte compiled code, which is
fairly common) is via generating C, which then needs to be
"GCCed into submission." Rather unsatisfactory...
--
"There is no reason anyone would want a computer in their home". --
Ken Olson, Pres. and founder of Digital Equipment Corp. 1977
········@hex.net - - <http://www.ntlug.org/~cbbrowne/lsf.html>
In article <·······················@knuth.brownes.org>,
Christopher Browne <········@hex.net> wrote:
>One problem with most of the Schemes is that the way they generate
>_machine code_ (versus some form of byte compiled code, which is
>fairly common) is via generating C, which then needs to be
>"GCCed into submission." Rather unsatisfactory...
Doing some toy microbenchmarks --- the old doubly-recursive fibonacci
trick --- I found that the combined running time for gcc and the C
version was less than that of nearly all the interpreters I tried,
including IIRC three Scheme interpreters.
I'd be perfectly happy GCCing my Scheme code into submission if I could
put gcc into a bubble universe where its filesystem actions were
isolated from my real filesystem. (And where I could count on proper
tail-recursion elimination...!)
I second your recommendation of DrScheme, by the way. For toy
programs, it is far nicer than any other implementation of any language
I have ever used in my life.
--
<······@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
Erik Naggum <····@naggum.no> writes:
> * Shelly Somerville <··········@uniserve.com>
> | Thank you. Do you have a reccomendation for a Scheme interpreter?
>
> Since I read and worked with the first edition of SICP, I am partial
> to the _very_ good MIT Scheme implementation, which was also used in
> the book. Since then, the second edition of SICP is out and it uses
> R5RS� Scheme, MIT Scheme was no longer supported on the platforms I
> use (only Microsoft-free computers!) the last time I checked, and I
> have come to dislike Scheme intensely over the past 6 years or so.
>
> I would recommend that you ask in comp.lang.scheme, and request info
> on Scheme environments that are actually supported, not just toys or
> research vehicles. I haven't been following the Scheme "evolution"
> closely for quite some time, and wouldn't know which environments
> are the better these days. All I have noticed is that there is no
> change to the plethora of _really_ crummy ones implemented by people
> who get a fascination with the implementability of the language
> rather than its usability. (This is a reason not to use Scheme!)
>
> Please note that although "interpreter" is not strictly _wrong_,
> both Lisp and Scheme are usually compiled these days, and you are
> better off if you avoid interpreter-only environments. A good
> native compiler is hard to write and unlikely to be a crummy
> implementation of Scheme, while an interpreter is much too easy.
>
> Good luck with SICP, and if you decide not to hang around while you
> study with Scheme: welcome back when you're ready to graduate into
> Common Lisp.
>
While I doubt there is anything that could ameliorate Erik's intense
hatred for Scheme, I'll point out that accoding to the MIT Scheme site,
http://www.swiss.ai.mit.edu/projects/scheme/
MIT Scheme is a complete programming environment that runs on many
unix platforms, as well as Microsoft Windows and IBM OS/2. It features
a rich runtime library, a powerful source-level debugger, a
native-code compiler, and an integrated Emacs-like editor.
MIT Scheme 7.5 is available for Intel-architecture (x86) machines
running GNU/Linux, FreeBSD, IBM OS/2 or Microsoft Windows 9x/NT.
MIT Scheme 7.4 is available for Intel-architecture (x86) machines
running GNU/Linux, FreeBSD, NetBSD, BSDI BSD/OS, IBM OS/2 or Microsoft
Windows.
MIT Scheme 7.3 is available for DEC Alpha running OSF/1, DEC MIPS
running Ultrix, HP 68000 and PA machines running HP-UX 9, IBM RS-6000
running AIX, NeXT, SGI MIPS running Irix 4 or 6, Sun 3, or Sun SPARC
running SunOS 4.1.
I think the MIT Scheme implementation should still be of high enough
quality to satisfy even Erik's standards.
The DrScheme (PLT) environment from Rice university is quite nice as
well, especially from a pedagogical point of view.
--
~jrm
Centuries ago, Nostradamus foresaw a time when Joe Marshall would say:
>The DrScheme (PLT) environment from Rice university is quite nice as
>well, especially from a pedagogical point of view.
Pedagogically quite nice; the GUI is also quite nice, and there are some
slick debugging tools.
Startup time is surprisingly _bad_. I rewrote a script (processing
a chunk of News spool) today, moving from DrScheme-Jr to CLISP, and
despite the "huge CL environment," the time required to load the
interpreter fell from about 6s to less than 1. CLISP isn't the "most
loved" implementation, but apparently outspeeds DrScheme. (And it's
not just load time where it wins...)
--
Rules of the Evil Overlord #225. "I will explain to my guards that
most people have their eyes in the front of their heads and thus while
searching for someone it makes little sense to draw a weapon and
slowly back down the hallway." <http://www.eviloverlord.com/>
········@hex.net - - <http://www.ntlug.org/~cbbrowne/lsf.html>
········@knuth.brownes.org (Christopher Browne) writes:
>Centuries ago, Nostradamus foresaw a time when Joe Marshall would say:
>>The DrScheme (PLT) environment from Rice university is quite nice as
>>well, especially from a pedagogical point of view.
>Pedagogically quite nice; the GUI is also quite nice, and there are some
>slick debugging tools.
>Startup time is surprisingly _bad_.
Huh? For me, libscheme - derivates like mzscheme are surprisingly
fast in startup when compared to scm, guile, scheme48 etc.
Are you possibly running a drscheme-capable mzscheme that does some
initialization work for drscheme? Please try a "naked" mzscheme.
> I rewrote a script (processing
>a chunk of News spool) today, moving from DrScheme-Jr to CLISP, and
>despite the "huge CL environment," the time required to load the
>interpreter fell from about 6s to less than 1. CLISP isn't the "most
>loved" implementation, but apparently outspeeds DrScheme. (And it's
>not just load time where it wins...)
Clisp is fast in a number of ways. It may not have a native compiler,
but startup, bignums etc. are all well-tought off and large chunks are
written in C anyway.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/