I am trying to relearn CL after a l-o-o-n-g absence, however am
running into problems, need some advice.
Usually, I dive into 4 books:
1) The Little Lisper
2) The Little Schemer
3) The Seasoned Schemer
4) SICP
...then revert to re-learning Common Lisp from various books.
...then re-visit Scheme for a bit in the advanced:
"Essentials of Programming Languages" book
After all that, I consider myself mildly proficient in CL.<g>
All that, BTW, takes me the better part of a year. (slow learner)
Here are the problems I am running into, need advice on -
1) Because I run the latest Mac OS's, not all Scheme implementations
will run on that for various reasons. I would like a Scheme which is
compliant with the present Scheme standard, has macros, and will run
the exercises in The-Little-Lisper, SICP, etc. Any recommendations?
Yes, I know, I should be asking this in the Scheme NG, but my main
purpose is to re-learn CL, and I only use Scheme as an easy entry-way
into re-learning Common Lisp.
2) Has much changed in CL in the past 5 years while I have been away?
3) Any CL more compliant with the CL Standard than Digitool's MCL?
Thanks for any and all advice,
Mark-
On Fri, Apr 02, 2004 at 04:29:46AM +0000, Mark Conrad wrote:
> Yes, I know, I should be asking this in the Scheme NG, but my main
> purpose is to re-learn CL, and I only use Scheme as an easy entry-way
> into re-learning Common Lisp.
Not that I am trying to stop you from [re-]learning Scheme, but I don't
see how it is related to [re-]learning Common Lisp. If you want to
learn CL, learn CL. There are lots of ways to get started with simple
CL and leave the more advanced features for later.
> 2) Has much changed in CL in the past 5 years while I have been away?
More programmers, more libraries, some attempts to bring the community
together. See sites like http://www.cliki.net/ for example. The
standard itself has not changed.
> 3) Any CL more compliant with the CL Standard than Digitool's MCL?
I would venture to say that SBCL is less likely to have standards
compliance bugs. It has recently been ported to OS X, though I
understand that it is in somewhat of a developmental state. I haven't
gotten a chance to play with it on OS X yet, but I will soon.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
>>>>> "Matthew" == Matthew Danish <·······@andrew.cmu.edu> writes:
>> 2) Has much changed in CL in the past 5 years while I have been away?
Matthew> More programmers, more libraries, some attempts to bring the community
Matthew> together. See sites like http://www.cliki.net/ for example. The
Matthew> standard itself has not changed.
The link should be on cliki.net somewhere but I think it warrants
separate mentioning, so do not forget to check out:
http://www.common-lisp.net
Wrt to texts on CL, there is also
http://www.cse.buffalo.edu/pub/WWW/faculty/shapiro/Commonlisp/
which I picked up somewhere recently (on some blog I think). I have
not read it, but it looks pretty ok.
------------------------+-----------------------------------------------------
Christian Lynbech | christian ··@ defun #\. dk
------------------------+-----------------------------------------------------
Hit the philistines three times over the head with the Elisp reference manual.
- ·······@hal.com (Michael A. Petonic)
In article <······················@mapcar.org>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> Not that I am trying to stop you from [re-]learning Scheme, but I don't
> see how it is related to [re-]learning Common Lisp.
Hi Matthew, thanks for responding.
Oh, just a personal preference about learning a bit of Scheme first.
I like the approach used in the Scheme books, they emphasis different
aspects of computing than my CL books do. I just figured that I was
more likely to get a well rounded education in Lisp than if I ignored
Scheme.
Most of my time will be spent reviewing CL. I have many more CL books
than I have Scheme books. CL is so huge that it will comsume a lot of
my time learning the more obscure functions and techniques.
> I would venture to say that SBCL is less likely to have standards
> compliance bugs. It has recently been ported to OS X, though I
> understand that it is in somewhat of a developmental state. I haven't
> gotten a chance to play with it on OS X yet, but I will soon.
That is interesting, I will Google "SBCL" to try to find out more about
it, thanks.
Mark-
Mark Conrad <············@invalid.com> writes:
> In article <······················@mapcar.org>, Matthew Danish
> <·······@andrew.cmu.edu> wrote:
>
> > I would venture to say that SBCL is less likely to have standards
> > compliance bugs. It has recently been ported to OS X, though I
> > understand that it is in somewhat of a developmental state. I haven't
> > gotten a chance to play with it on OS X yet, but I will soon.
>
> That is interesting, I will Google "SBCL" to try to find out more about
> it, thanks.
I don't recall anyone mentioning the other CL implementations that
work on OS X (I believe that OS X is now the platform on which more
CL implementations run, than any other) ... so for completeness:
Allegro (from Franz) and LispWorks (from Xanalys) both come in free
(as in beer) trial/personal versions (as well as hand-over-your-cash
versions).
OpenMCL (a blood relation of Digitool's MCL, of which you spoke
earlier).
The ubiquitous Clisp.
CMUCL ... has recently been ported to OS X (even more recently than
SBCL).
I'm afraid that I don't have any reliable information about their
standard-compliance status.
In article <··················@pcepsft001.cern.ch>, Jacek Generowicz
<················@cern.ch> wrote:
> I don't recall anyone mentioning the other CL implementations that
> work on OS X (I believe that OS X is now the platform on which more
> CL implementations run, than any other) ... so for completeness:
>
> Allegro (from Franz) and LispWorks (from Xanalys) both come in free
> (as in beer) trial/personal versions (as well as hand-over-your-cash
> versions).
In particular LispWorks has a very nice GUI IDE. If I had the cash to
hand over, I'd hand it over for that :-)
> OpenMCL (a blood relation of Digitool's MCL, of which you spoke
> earlier).
OpenMCL, though not as fast as SBCL, has a "smarter" GC and native
threads.
> The ubiquitous Clisp.
... is not nearly so ubiquitous; in fact it can be downright annoying
to install on OS X. You may want to check fink.
> CMUCL ... has recently been ported to OS X (even more recently than
> SBCL).
CMUCL has many backend bugs in its PowerPC port that have already been
fixed on SBCL. I would not recommend it yet.
Of these, SBCL would be the most standards-compliant and clisp likely
the least (depending on whether the standards tests crash CMUCL).
There's also Armed Bear Lisp:
http://armedbear-j.sf.net/
If you check it out from CVS and ./configure
--with-jdk=/System/Library/Frameworks/JavaVM.framework it should work
fine. It also has an integrated editor ("j").
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
In article <··················@pcepsft001.cern.ch>, Jacek Generowicz
<················@cern.ch> wrote:
Regarding the 'free' CL implementations -
> I'm afraid that I don't have any reliable information about their
> standard-compliance status.
That is what mainly concerns me, in the interest of making 'portable'
code.
One thing I _don't_ like about the for-pay implementations, is that
they charge so darn much for the license to create stand-alone app's
that will run without a Lisp application needing to be present.
Mark-
Mark Conrad <············@invalid.com> writes:
> One thing I _don't_ like about the for-pay implementations, is that
> they charge so darn much for the license to create stand-alone app's
> that will run without a Lisp application needing to be present.
Corman Common Lisp charges nothing. Xanalys charges nothing for
windows and linux platforms (I think I remember that right.)
Franz isn't all that expensive but it depends on how much you value
your immortal soul.
--
~jrm
* Joe Marshall wrote:
> Corman Common Lisp charges nothing. Xanalys charges nothing for
> windows and linux platforms (I think I remember that right.)
You do.
--tim
On Thu, 22 Apr 2004 00:46:24 GMT, Joe Marshall <·············@comcast.net> wrote:
> Xanalys charges nothing for windows and linux platforms (I think I
> remember that right.)
Yes. Also for Mac OS X.
Matthew Danish <·······@andrew.cmu.edu> writes:
> I would venture to say that SBCL is less likely to have standards
> compliance bugs.
I have a question about SBCL, and this is also why I do not use it.
I type:
(defun f (x) (g x))
That is a perfectly reasonable definition. There is nothing
wrong with it. Indeed, most of my code is written in top-down
order with "forward calls".
SBCL doesn't think so. I complains, like this:
; in: LAMBDA NIL
; (G X)
;
; caught STYLE-WARNING:
; undefined function: G
;
; caught STYLE-WARNING:
; This function is undefined:
; G
;
; compilation unit finished
; caught 2 STYLE-WARNING conditions
Why is it doing this?
No other Lisp I have ever used (and that is a lot of Lisps)
has ever made such objections.
SBCL also complains if I define the function in a file,
unless I also define G there.
It does at least let me define F before G.
-- jd
From: Paul F. Dietz
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <DOudnbICBN826_DdRVn-hA@dls.net>
Jeff Dalton wrote:
> I have a question about SBCL, and this is also why I do not use it.
>
> I type:
>
> (defun f (x) (g x))
>
> That is a perfectly reasonable definition. There is nothing
> wrong with it. Indeed, most of my code is written in top-down
> order with "forward calls".
>
> SBCL doesn't think so. I complains, like this:
[...]
> No other Lisp I have ever used (and that is a lot of Lisps)
> has ever made such objections.
Allegro CL will complain if you compile a file containing that definition
if G is not defined in the file (or previously defined).
Paul
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
>> I would venture to say that SBCL is less likely to have standards
>> compliance bugs.
>
> I have a question about SBCL, and this is also why I do not use it.
>
> I type:
>
> (defun f (x) (g x))
>
> That is a perfectly reasonable definition. There is nothing
> wrong with it. Indeed, most of my code is written in top-down
> order with "forward calls".
>
> SBCL doesn't think so. I complains, like this:
Excerpted from the SBCL manual at
<http://www.sbcl.org/manual/idiosyncrasies.html>:
SBCL gives style warnings about various kinds of perfectly legal
code, ...
This causes friction with people who point out that other ways of
organizing code ... are just as aesthetically stylish. However,
these warnings should be read not as "warning, bad aesthetics
detected, you have no style" but "warning, this style keeps the
compiler from understanding the code as well as you might like."
Zach
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sq7jwyqukg.fsf@lambda.dyndns.org>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Matthew Danish <·······@andrew.cmu.edu> writes:
>
>> I would venture to say that SBCL is less likely to have standards
>> compliance bugs.
>
> I have a question about SBCL, and this is also why I do not use it.
> I type:
[ presumably at the repl ]
> (defun f (x) (g x))
>
> That is a perfectly reasonable definition. There is nothing
> wrong with it. Indeed, most of my code is written in top-down
> order with "forward calls".
There is an interesting class of functionality that can be done if the
code comes in the other order; various detections of errors, such as
argument count mismatch, can be performed at compile-time (thus
allowing SBCL to return useful values from COMPILE and COMPILE-FILE).
The top-down style inhibits this ability to detect errors (and other
incidental possibilities, such as elision of argument count checks,
type inference, and so on), which is why the compiler in general emits
a STYLE-WARNING for this style.
> SBCL doesn't think so. I[t] complains, like this:
>
> ; [ much complainage ]
>
> Why is it doing this?
What you see here, assuming that my presumption is right, is an
artifact of SBCL being a compiler-only implementation. In
implementations with interpreters, this typically defines an
interpreted function, and does not perform the usual analysis involved
in compilation; since behind the scenes sbcl is compiling and
executing (lambda () (defun f (x) (g x))), you see the compiler's
output as usual.
As for whether this is desireable for functions typed in at the REPL,
I suspect that many would not disagree with your assertion that it is
not. On the other hand, this is the first I've heard of the fact that
this is the sole reason for not using SBCL; this leads me to suspect
that your needs, or your methods of working, are a little atypical.
Are you usually interacting with the REPL directly? (I thought SBCL's
repl was too painful for that. :-)
> No other Lisp I have ever used (and that is a lot of Lisps)
> has ever made such objections.
>
> SBCL also complains if I define the function in a file,
> unless I also define G there.
Yes. If you have top-down code spanning multiple files, you may be
interested in the WITH-COMPILATION-UNIT macro.
> It does at least let me define F before G.
Isn't it generous?
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > Matthew Danish <·······@andrew.cmu.edu> writes:
> >
> >> I would venture to say that SBCL is less likely to have standards
> >> compliance bugs.
> >
> > I have a question about SBCL, and this is also why I do not use it.
>
> > I type:
> [ presumably at the repl ]
Yes, that's right: at the repl.
(Thanks for so detailed an answer, btw. Very helpful.)
A couple of replies have been about file compilation; and I think
I should have made it clearer that my primary complaint -- and
the reason I don't use SBCL -- is its behaviour when I type things
into the repl.
That's also what I've never seen any other Lisp do.
It's a pain to have that much output when I define a function.
Otherwise I could just ignore it. Things soon scroll off the
top of the window, which is harder to igore. :(
It also sugegsts the implementors either don't write code
in top-down order or else use a setup that isn't the default
but think ordinary users should see these warnings. :(
SBCL doesn't seem to complain if I define f before g but
define both in the same file. :)
> There is an interesting class of functionality that can be done if the
> code comes in the other order; various detections of errors, such as
> argument count mismatch, can be performed at compile-time (thus
> allowing SBCL to return useful values from COMPILE and COMPILE-FILE).
Still, when file-compiling, SBCL doesn't seem to mind the order.
> The top-down style inhibits this ability to detect errors (and other
> incidental possibilities, such as elision of argument count checks,
> type inference, and so on), which is why the compiler in general emits
> a STYLE-WARNING for this style.
Only for not very sophisticated file-compilers. It seemed to me
that SBCL, like CMUCL, had a quite sophisticated compiler and
was just taking individual top-level forms as compilation units a
bit too seriously.
> > Why is it doing this?
>
> What you see here, assuming that my presumption is right, is an
> artifact of SBCL being a compiler-only implementation.
Probably, but that doesn't mean it has to give the warning.
For example, PopLog CL is compiler-only and doesn't do it.
CMUCL gives a warning if I define f and then say (compile 'f),
but doesn't make any claims about style.
OTOH, it still gives 2 warnings for the same thing.
First: Undefined function: G
Then: This function is undefined:
G
> As for whether this is desireable for functions typed in at the REPL,
> I suspect that many would not disagree with your assertion that it is
> not. On the other hand, this is the first I've heard of the fact that
> this is the sole reason for not using SBCL; this leads me to suspect
> that your needs, or your methods of working, are a little atypical.
Why not suspect instead -- which is true -- that I have readily
accessible alternatives?
Perhaps that's atypical.
I still use GCL, CMUCL, sometimes Clisp.
I don't have time these days to learn the ins and outs of particular
implementations (or to keep Emacs modes up to date); so I just want
them to deliver standard Common Lisp in a straightforward way.
> Are you usually interacting with the REPL directly? (I thought SBCL's
> repl was too painful for that. :-)
What's the alternative?
-- jd
From: Roman Belenov
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <ur7v2namh.fsf@intel.com>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> It's a pain to have that much output when I define a function.
> Otherwise I could just ignore it. Things soon scroll off the
> top of the window, which is harder to igore. :(
That's one of the reasons for using better IDE like SLIME - it groups warning
and error messages by categories so you can easily navigate bettween them and
ignore anything you are not interested in.
--
With regards, Roman.
Standard disclaimer: I work for them, but I don't speak for them.
Roman Belenov <·············@intel.com> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > It's a pain to have that much output when I define a function.
> > Otherwise I could just ignore it. Things soon scroll off the
> > top of the window, which is harder to igore. :(
>
> That's one of the reasons for using better IDE like SLIME - it groups warning
> and error messages by categories so you can easily navigate bettween them and
> ignore anything you are not interested in.
How well does SLIME work with random Common Lisps?
I used to use ilisp, but it became too much trouble to keep
adapting new versions and dealing with new version of Emacs.
-- jd
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> How well does SLIME work with random Common Lisps?
The short version is that it works properly with CMUCL, SBCL, OpenMCL,
CLISP, LispWorks, and Allegro CL. By nature it doesn't work at all
with other Lisps that nobody has written a backend for.
Bill Clementson has some special instructions online about how to
install it cleanly with Win32 Lispen that don't run as command-line
programs. You can find the links via http://www.cliki.net/SLIME-HOWTO
There is also a draft of a manual that gives some details of the
supported Lisps and of what you can expect from SLIME as of today. You
can read it at:
http://www.bluetail.com/~luke/misc/lisp/slime.ps.gz
http://www.bluetail.com/~luke/misc/lisp/slime.pdf
The PDF version isn't as pretty as the postscript one at present.
> I used to use ilisp, but it became too much trouble to keep
> adapting new versions and dealing with new version of Emacs.
It sounds like SLIME probably isn't ready for you yet, as detailed in
the introduction to manual. If you want to "install and forget" then
I'd recommend waiting until we have finished so that your first
impression will be a good one.
But if you're feeling adventurous then you're welcome to the party :-)
Cheers,
Luke
Luke Gorrie <····@bluetail.com> wrote in message news:<··············@dodo.bluetail.com>...
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> > I used to use ilisp, but it became too much trouble to keep
> > adapting new versions and dealing with new version of Emacs.
>
> It sounds like SLIME probably isn't ready for you yet, as detailed in
> the introduction to manual. If you want to "install and forget" then
> I'd recommend waiting until we have finished so that your first
> impression will be a good one.
You're being too modest Luke :-)
SLIME is already more featureful and stable than ILISP. I always use
the latest CVS code and rarely have problems. If one wants to be very
conservative and doesn't want to touch their .emacs file very
frequently, one can use the FAIRLY-STABLE version of SLIME.
--
Bill Clementson
Luke Gorrie <····@bluetail.com> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > How well does SLIME work with random Common Lisps?
>
> The short version is that it works properly with CMUCL, SBCL, OpenMCL,
> CLISP, LispWorks, and Allegro CL. By nature it doesn't work at all
> with other Lisps that nobody has written a backend for.
That's excellent, but, unfortunately, I'd want it for GCL.
So it would be the same problem I used to have with ILisp,
that I'd have to make it work myself.
(Perhaps ILisp now handled GCL. I don't know.)
Still, I could try it with CMUCL, SBCL, or CLisp, but
I have all of them as well.
-- jd
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> So it would be the same problem I used to have with ILisp,
> that I'd have to make it work myself.
Or you could make it work for the glory of GCL users everywhere. ;-)
Greetings! I've just downloaded the CVS -- if I can find a few spare
moments I might try my hand at this. Time is tight as we're trying to
get 2.6.2 out the door.
Just a note that gcl comes with an emacs mode -- 'dbl' that works
fairly well but has a number of outstanding issues, especially as it
was designed to work with the cltl1 image and hasn't been updated
since. As GCL compiles code on top of C, once can even run dbl mode
on top of emacs gdb mode if one is so inclined.
Any interested volunteers are encouraged to write to me should they
wish to take this on and need assistance.
Take care,
Luke Gorrie <····@bluetail.com> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > So it would be the same problem I used to have with ILisp,
> > that I'd have to make it work myself.
>
> Or you could make it work for the glory of GCL users everywhere. ;-)
>
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
Camm Maguire <····@enhanced.com> writes:
> Greetings! I've just downloaded the CVS -- if I can find a few spare
> moments I might try my hand at this. Time is tight as we're trying to
> get 2.6.2 out the door. ...
I've used KCL/AKCL/GCL for a long time (since 1985 or so), and
a few years ago, development seemed to cease at an awkward point.
In particular, C-code-loading had stopped working, and later
even loading ordinary compiled code stopped working.
So I'm wondering
1. Is there are GCL that works on FreeBSD that would let me
load C code using si:faslink?
2. How about Linux?
3. Is the C interface still the (IMO) nice one it used to have?
-- jd
Greetings! GCL has seen a lot of development over the past three
years or so. You can follow the progress at ·········@gnu.org.
The C interface is largely the same, with updates for the newer gcc
demands.
faslink has not been enabled yet because no one has asked for it.
It would appear to be straightforward given GCL's other linking
options. If you would like to explore enabling it and have some
specific examples, please let us know. The docs state that faslink is
a rather unportable option, and recommend an alternate method based on
the makefiles. We've simplified the latter option quite a lot, so
that the build tree and makefiles are no longer necessary to link in C
libraries and code, rather the user can use (compiler::link...) from
within GCL proper. Again, if you have a specific example, I can show
you how to link your new image with this function, or you can just
check the docs.
Of course, native compiled lisp object loading is still supported as
always, with dumping via si::save-system preserving these loads on 6
out of 12 Debian platforms (i386 sparc arm m68k ppc s390) and xBSD.
As you probably know, one can insert arbitrary C code into these
modules via (clines ...).
Take care,
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Camm Maguire <····@enhanced.com> writes:
>
> > Greetings! I've just downloaded the CVS -- if I can find a few spare
> > moments I might try my hand at this. Time is tight as we're trying to
> > get 2.6.2 out the door. ...
>
> I've used KCL/AKCL/GCL for a long time (since 1985 or so), and
> a few years ago, development seemed to cease at an awkward point.
>
> In particular, C-code-loading had stopped working, and later
> even loading ordinary compiled code stopped working.
>
> So I'm wondering
>
> 1. Is there are GCL that works on FreeBSD that would let me
> load C code using si:faslink?
>
> 2. How about Linux?
>
> 3. Is the C interface still the (IMO) nice one it used to have?
>
> -- jd
>
--
Camm Maguire ····@enhanced.com
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
From: John Thingstad
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <opr5ubnrkdxfnb1n@news.chello.no>
Frankly, using a function before it's definition annoyes me too.
On Fri, 02 Apr 2004 16:16:15 +0100, Christophe Rhodes <·····@cam.ac.uk>
wrote:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
>> Matthew Danish <·······@andrew.cmu.edu> writes:
>>
>>> I would venture to say that SBCL is less likely to have standards
>>> compliance bugs.
>>
>> I have a question about SBCL, and this is also why I do not use it.
>
>> I type:
> [ presumably at the repl ]
>> (defun f (x) (g x))
>>
>> That is a perfectly reasonable definition. There is nothing
>> wrong with it. Indeed, most of my code is written in top-down
>> order with "forward calls".
>
> There is an interesting class of functionality that can be done if the
> code comes in the other order; various detections of errors, such as
> argument count mismatch, can be performed at compile-time (thus
> allowing SBCL to return useful values from COMPILE and COMPILE-FILE).
> The top-down style inhibits this ability to detect errors (and other
> incidental possibilities, such as elision of argument count checks,
> type inference, and so on), which is why the compiler in general emits
> a STYLE-WARNING for this style.
>
>> SBCL doesn't think so. I[t] complains, like this:
>>
>> ; [ much complainage ]
>>
>> Why is it doing this?
>
> What you see here, assuming that my presumption is right, is an
> artifact of SBCL being a compiler-only implementation. In
> implementations with interpreters, this typically defines an
> interpreted function, and does not perform the usual analysis involved
> in compilation; since behind the scenes sbcl is compiling and
> executing (lambda () (defun f (x) (g x))), you see the compiler's
> output as usual.
>
> As for whether this is desireable for functions typed in at the REPL,
> I suspect that many would not disagree with your assertion that it is
> not. On the other hand, this is the first I've heard of the fact that
> this is the sole reason for not using SBCL; this leads me to suspect
> that your needs, or your methods of working, are a little atypical.
> Are you usually interacting with the REPL directly? (I thought SBCL's
> repl was too painful for that. :-)
>
>> No other Lisp I have ever used (and that is a lot of Lisps)
>> has ever made such objections.
>>
>> SBCL also complains if I define the function in a file,
>> unless I also define G there.
>
> Yes. If you have top-down code spanning multiple files, you may be
> interested in the WITH-COMPILATION-UNIT macro.
>
>> It does at least let me define F before G.
>
> Isn't it generous?
>
> Christophe
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
John Thingstad <··············@chello.no> writes:
> Frankly, using a function before it's definition annoyes me too.
You prefer bottom-up order?
That's interesting, if so. How common is that?
-- jd
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> You prefer bottom-up order?
>
> That's interesting, if so. How common is that?
I would think it is very common. Bottom-up programming allows you to
test the functions as you go along.
--
Robert Strandh
Robert STRANDH wrote:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
>
>>You prefer bottom-up order?
>>
>>That's interesting, if so. How common is that?
>
>
> I would think it is very common. Bottom-up programming allows you to
> test the functions as you go along.
That's probably smarter than my approach, but then I lack the discipline
to work the way I should. When I sit down to write the hugest app I
always begin (in COBOL):
perform 1000-beginning.
perform 2000-middle until done.
perform 9000-end.
Then I like to stand up, do my end-zone dance*, stretch, announce my
coming in under budget, shake a few hands, then sit back down to repeat
that exercise on 2000-middle. beginning and end get filled in when the
middle crashes because I did not open a file, or when my manager says,
"Great, Kenny, but where the %$%$^ is the output file?".
The thing I like about this is that I get to defer the tedious details
as long as possible, generally until a day or two before we go live. The
compiler error listing is my "do list". It tends to get longer and
longer during the first third of development, stay constant for the
middle two thirds, then diminish asymtoptically for the final three thirds.
Any lines still producing compiler errors when it is time to go live I
just comment out.
hth.**
kt
* American football. Showing off after scoring.
** Just kidding, but I do like to work top-down, and I never test
low-level stuff on its own. What if it works? Then that time was wasted.
yes this makes for more and harder debugging, but Lisp is great for
runtime debugging, and debugging is fun, so I have plenty of energy for
it. if I had to test every function after coding it, I would become a
bookkeeper or something else more entertaining. fast and loose, ladies,
fast and loose.
k
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Robert STRANDH wrote:
>
> > Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> >
> >>You prefer bottom-up order?
> >>
> >>That's interesting, if so. How common is that?
> > I would think it is very common. Bottom-up programming allows you to
> > test the functions as you go along.
>
> That's probably smarter than my approach, but then I lack the
> discipline to work the way I should. When I sit down to write the
> hugest app I always begin (in COBOL):
>
> perform 1000-beginning.
> perform 2000-middle until done.
> perform 9000-end.
>
> Then I like to stand up, do my end-zone dance*, stretch, announce my
> coming in under budget, shake a few hands, then sit back down to
> repeat that exercise on 2000-middle. beginning and end get filled in
> when the middle crashes because I did not open a file, or when my
> manager says, "Great, Kenny, but where the %$%$^ is the output file?".
>
> The thing I like about this is that I get to defer the tedious details
> as long as possible, generally until a day or two before we go
> live. The compiler error listing is my "do list". It tends to get
> longer and longer during the first third of development, stay constant
> for the middle two thirds, then diminish asymtoptically for the final
> three thirds.
Hey, if you can put six thirds of your effort into a project, no
wonder you get so much done :-).
--
Rob St. Amant
http://www4.ncsu.edu/~stamant
Robert St. Amant wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>live. The compiler error listing is my "do list". It tends to get
>>longer and longer during the first third of development, stay constant
>>for the middle two thirds, then diminish asymtoptically for the final
>>three thirds.
>
>
> Hey, if you can put six thirds of your effort into a project, no
> wonder you get so much done :-).
No, but I may have lead now on why I have so much trouble estimating
projects.
:)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Robert STRANDH wrote:
>
> > Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> >
> >>You prefer bottom-up order?
> >>
> >>That's interesting, if so. How common is that?
> > I would think it is very common. Bottom-up programming allows you to
> > test the functions as you go along.
>
> That's probably smarter than my approach, but then I lack the
> discipline to work the way I should. When I sit down to write the
> hugest app I always begin (in COBOL):
>
> perform 1000-beginning.
> perform 2000-middle until done.
> perform 9000-end.
> [and on]
This is getting stranger and stranger. Now the top-down order
is getting a response that is essentially an insult, though amusing.
> ** Just kidding, but I do like to work top-down, and I never test
> low-level stuff on its own. What if it works? Then that time was
> wasted. yes this makes for more and harder debugging, but Lisp is
> great for runtime debugging, and debugging is fun, so I have plenty of
> energy for it.
You say you were just kidding, but it doesn't really sound like it.
The way time might be wasted is if the lower-level code turned
out to be unneeded or to not fit into the program in the way
expected when it was written, so that it to has be thrown away or
almost completely rewritten.
But of course, working top-down can go wrong too.
> if I had to test every function after coding it, I
> would become a bookkeeper or something else more entertaining. fast
> and loose, ladies, fast and loose.
I thought today's ideology said to write the tests before the code.
Anyway, it used to be fairly common, at least, in the Lisp world, to
work partly bottom-up (building tools and raising the level of the
language closer to that of the application) and partly top-down.
Moreover, it's sometimes sufficiently clear that certain lower-level
functionality will be needed; and for testing, or to make sure it can
be done, it is written first.
But none of that says the order in which definitions should be placed
in a file should be bottom-up. It's not like editors don't let you
move up and place something earlier.
When people put the lower leves first, I typically have to read their
files backwards, starting at the bottom and working up.
-- jd
Jeff Dalton wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>Robert STRANDH wrote:
>>
>>
>>>Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>>>
>>>
>>>>You prefer bottom-up order?
>>>>
>>>>That's interesting, if so. How common is that?
>>>
>>>I would think it is very common. Bottom-up programming allows you to
>>>test the functions as you go along.
>>
>>That's probably smarter than my approach, but then I lack the
>>discipline to work the way I should. When I sit down to write the
>>hugest app I always begin (in COBOL):
>>
>> perform 1000-beginning.
>> perform 2000-middle until done.
>> perform 9000-end.
>
>
>>[and on]
>
>
> This is getting stranger and stranger. Now the top-down order
> is getting a response that is essentially an insult, though amusing.
PWUAHHAHAHAH. Jeff, I am not joking. When I did COBOL and I was starting
a many-week application, that is exactly what I did, right down to the
end-zone dance. When I did VAX Basic I would do (syntax mad rusty):
bigapp_init()
continue = -1%
while continue
a few lines of code
end-while
Dance unchanged.
> You say you were just kidding, but it doesn't really sound like it.
Uhhh, the "kidding" was stuff like commenting out lines of code that
produced compiler errors to make a production release deadline.
I was /not/ kidding about starting with three lines of COBOL, nor was I
mocking your position, I was supporting it.
Shall we start over? :)
>>if I had to test every function after coding it, I
>>would become a bookkeeper or something else more entertaining. fast
>>and loose, ladies, fast and loose.
>
>
> I thought today's ideology said to write the tests before the code.
Yechh. What if my code works? Wasted time writing the test.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> I was /not/ kidding about starting with three lines of COBOL, nor was
> I mocking your position, I was supporting it.
>
> Shall we start over? :)
Yes, please.
Sorry about that.
I read your COBOL etc as saying that sure, someone using *COLBOL*,
or other losing languages, might write top down.
-- jd
Jeff Dalton wrote:
>
> I read your COBOL etc as saying that sure, someone using *COLBOL*,
> or other losing languages, might write top down.
COBOL is a great language, actually. move-corresponding, copy-replacing,
evaluate, condition names (settable!), transparent string to binary
moves of numerics, perform-vary-until, built-in report-writer,... and,
yes, I am serious. :)
Time has passed it by, but when I see a '57 Chevy I see perfection, not
the obsolete pushrods.
The problem is explaining how McCarthy came up with what looks like the
winner of the 2004 award for Best New Language back in 1957.
Aliens, clearly.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> Jeff Dalton wrote:
>
> > I read your COBOL etc as saying that sure, someone using *COLBOL*,
> > or other losing languages, might write top down.
>
> COBOL is a great language, actually. move-corresponding,
> copy-replacing, evaluate, condition names (settable!), transparent
> string to binary moves of numerics, perform-vary-until, built-in
> report-writer,... and, yes, I am serious. :)
I once worked on a COBOL compiler.
> Time has passed it by, but when I see a '57 Chevy I see perfection,
> not the obsolete pushrods.
Isn't COBOL now object-oriented or something?
> The problem is explaining how McCarthy came up with what looks like
> the winner of the 2004 award for Best New Language back in 1957.
Algols 58 and 60 weren't bad either.
-- jd
Jeff Dalton wrote:
> Isn't COBOL now object-oriented or something?
Yes, and it's my favorite geek joke, "Add 1 to COBOL". And I have seen a
real code snippet. Ah, yes, the Object Division, of course. :)
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton wrote:
<snip>
>>> if I had to test every function after coding it, I
>>> would become a bookkeeper or something else more entertaining. fast
>>> and loose, ladies, fast and loose.
>>
>>
>>
>> I thought today's ideology said to write the tests before the code.
>
>
> Yechh. What if my code works? Wasted time writing the test.
>
> kt
>
I find tests for even fairly simple functions useful for two reasons.
They provide documentation by giving examples of the function in use,
and also for checking behaviour is unchanged when a bottleneck goes from
'simple but slow' to 'fast but complex'.
Alex
Robert STRANDH <·······@labri.fr> writes:
> > You prefer bottom-up order?
> >
> > That's interesting, if so. How common is that?
>
> I would think it is very common. Bottom-up programming allows you to
> test the functions as you go along.
I often test functions as I go along. That doesn't stop me from
having them in files in top-down order.
The order in which I write the text and the order in which
it occurs in the file can be different.
-- jd
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sqoeqab4k2.fsf@lambda.dyndns.org>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Robert STRANDH <·······@labri.fr> writes:
>
>> > You prefer bottom-up order?
>> >
>> > That's interesting, if so. How common is that?
>>
>> I would think it is very common. Bottom-up programming allows you to
>> test the functions as you go along.
>
> I often test functions as I go along. That doesn't stop me from
> having them in files in top-down order.
>
> The order in which I write the text and the order in which
> it occurs in the file can be different.
Forgive me, but that seems particularly perverse. You seem to be
going out of your way to make things difficult for automated tools;
it's not as if I encourage people to follow slavishly convention for
the benefit of compilers or whatnot, but actively subverting them
seems odd. Do you have a reason for writing text in a different order
from its appearance in the file?
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > Robert STRANDH <·······@labri.fr> writes:
> >
> >> > You prefer bottom-up order?
> >> >
> >> > That's interesting, if so. How common is that?
> >>
> >> I would think it is very common. Bottom-up programming allows you to
> >> test the functions as you go along.
> >
> > I often test functions as I go along. That doesn't stop me from
> > having them in files in top-down order.
> >
> > The order in which I write the text and the order in which
> > it occurs in the file can be different.
>
> Forgive me, but that seems particularly perverse. You seem to be
> going out of your way to make things difficult for automated tools;
I am surprised by that remark. Especially in a Lisp context, since
mutually recursive functions (so that one or the other must call a
function whose definition doesn't appear until later) are so common.
Do people really now regard placing their code in bottom-up
order as normal good practice? If so, why? What's happened?
Is this a "generational" change? Have people been brought up
using one-pass compilers?
Automated tools have been able to handle top-down order for
decades.
Sure, in the C world, forward declarations were needed my
many compilers, though even there header files often took
care of it. (That is: something you would do anyway -- put
a declaration in the .h file -- would also allow the actual
definitions to appear in any order.)
> it's not as if I encourage people to follow slavishly convention for
> the benefit of compilers or whatnot, but actively subverting them
> seems odd.
What makes you think they find it difficult?
> Do you have a reason for writing text in a different order
> from its appearance in the file?
Yes. I sometimes write lower-level things first so they can
be tested, or to "raise the level" of the language I'm using.
That doesn't mean I want to read the code in that order
when I come back to it later on.
When reading code, I usually want to get a higher-level look at what's
happening first, before going into lower-level details.
In any case, why should I position code in the file in the order
in which it was written? The placement should reflect logical
structure and provide an order that's good for humans reading
the code.
-- jd
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sqk70yb0kf.fsf@lambda.dyndns.org>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> Forgive me, but that seems particularly perverse. You seem to be
>> going out of your way to make things difficult for automated tools;
>
> I am surprised by that remark. Especially in a Lisp context, since
> mutually recursive functions (so that one or the other must call a
> function whose definition doesn't appear until later) are so common.
Yes, and as we've already discussed mutually-recursive functions
within the same compilation unit do not cause any style warnings in
sbcl, and probably (it's not defined, but it's strongly encouraged by
the standard) not in other compilers either. I would suspect that
mutually recursive functions where each leaf is in a different file,
and where a suitable system definition facility weren't being used,
are rare in the wild.
> Do people really now regard placing their code in bottom-up
> order as normal good practice? If so, why? What's happened?
> Is this a "generational" change? Have people been brought up
> using one-pass compilers?
I suspect, actually, that people regard using a system definition
facility, and tools which aid in dealing with compiler diagnostics, as
more important than typing definitions into a REPL. Just because it's
there doesn't mean it's the best way to do it.
To give a concrete example, my workflow when I start work in the
morning is to start an emacs, load SLIME, and call require on the
systems I am working on; this takes care of loading systems (within a
compilation unit, so forward function uses don't cause warnings :-)
and sets me up so I'm ready to go. Then I continue with the usual
"compile this defun" emacs commands. I fail to see how this crimps my
style.
>> it's not as if I encourage people to follow slavishly convention for
>> the benefit of compilers or whatnot, but actively subverting them
>> seems odd.
>
> What makes you think they find it difficult?
This question appears to have no bearing on what I wrote... what is
"it" in your question?
> In any case, why should I position code in the file in the order
> in which it was written? The placement should reflect logical
> structure and provide an order that's good for humans reading
> the code.
Yes, of course. And within a file, as encouraged by the language
standard, forward uses do not cause compiler warnings.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>
> > Christophe Rhodes <·····@cam.ac.uk> writes:
> >
> >> Forgive me, but that seems particularly perverse. You seem to be
> >> going out of your way to make things difficult for automated tools;
> >
> > I am surprised by that remark. Especially in a Lisp context, since
> > mutually recursive functions (so that one or the other must call a
> > function whose definition doesn't appear until later) are so common.
>
> Yes, and as we've already discussed mutually-recursive functions
> within the same compilation unit do not cause any style warnings in
> sbcl, and probably (it's not defined, but it's strongly encouraged by
> the standard) not in other compilers either.
Just to be clear, this is no longer about the repl. The discussion
moved on to the order of definitions in files a few messages back.
Because of mutual recursion, Lisp compilers have to be able to deal
with definitions that refer to definitions that occur later in the
file, and so there has been little reason for a bottom-up culture to
develop in the Lisp world.
I've made a quick survery of handy Lisp code, none written by me,
from books and Lisp implementations, and all of it was in the sort
of order I'd use, which is largely top-down.
So I'm certainly not alone in writing code that way; and some
well-known Lisp implementors (at least) are with me in this heresy.
> > Do people really now regard placing their code in bottom-up
> > order as normal good practice? If so, why? What's happened?
> > Is this a "generational" change? Have people been brought up
> > using one-pass compilers?
>
> I suspect, actually, that people regard using a system definition
> facility, and tools which aid in dealing with compiler diagnostics, as
> more important than typing definitions into a REPL. Just because it's
> there doesn't mean it's the best way to do it.
Back, briefly, to the repl. The definition was just an example. If I
merely make a spelling mistake in a form, I don't just get a nice
message saying I'm calling an undefined function. I get line after
line of output about "style warnings".
As for defsys, all the ones I've used treat each file as a
unit, and such a defsys is irrelevant to the order of definition
within a file.
For compiler diagnostics, what do you have in mind? Even SBCL
doesn't complain about the definition order.
Are there some optimizations or checks it cannot perform if
the definitions are not in bottom-up order?
If compilers are limited in that way, I'd regard it as a
temporary phenomenon: they're sufficiently sophisticaed
that they can do clever optimization and analysis, but
not to the point where they stop depending on the order
of function definitions in the file.
> >> it's not as if I encourage people to follow slavishly convention for
> >> the benefit of compilers or whatnot, but actively subverting them
> >> seems odd.
> >
> > What makes you think they find it difficult?
>
> This question appears to have no bearing on what I wrote... what is
> "it" in your question?
Sure, I wrote (in reply to someone else -- Robert STRANDH):
... The order in which I write the text and the order in which
it occurs in the file can be different.
I was talking about placing definitions in a file in top-down
order, even if the chronological in which they were written
(and tested) was different.
Your reply said:
Forgive me, but that seems particularly perverse. You seem to be
going out of your way to make things difficult for automated tools;
it's not as if I encourage people to follow slavishly convention for
the benefit of compilers or whatnot, but actively subverting them
seems odd.
So "it" was (or should have been) what I was doing that seemed
perverse and supposedly subverted the tools; and in context that was
(or should have been) using top-down order for the definitions in
files, because that's what I was talking about at that point,
and the message was a reply to what I said there.
> > In any case, why should I position code in the file in the order
> > in which it was written? The placement should reflect logical
> > structure and provide an order that's good for humans reading
> > the code.
>
> Yes, of course. And within a file, as encouraged by the language
> standard, forward uses do not cause compiler warnings.
Which has been common ground from the start.
I said in my original message that SBCL didn't complain if I defined
both functions in the same file.
But I don't know the details of SBCL's implementation. Perhaps it
has some problem with top-down order in files. I'be be surprised
if it did, but I don't know for sure that it doesn't.
-- jd
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sq7jwxbesk.fsf@lambda.dyndns.org>
Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
>> Jeff Dalton <····@todday.inf.ed.ac.uk> writes:
>>
>> > Christophe Rhodes <·····@cam.ac.uk> writes:
>> >
>> >> Forgive me, but that seems particularly perverse. You seem to be
>> >> going out of your way to make things difficult for automated tools;
>> >
>> > I am surprised by that remark. Especially in a Lisp context, since
>> > mutually recursive functions (so that one or the other must call a
>> > function whose definition doesn't appear until later) are so common.
>>
>> Yes, and as we've already discussed mutually-recursive functions
>> within the same compilation unit do not cause any style warnings in
>> sbcl, and probably (it's not defined, but it's strongly encouraged by
>> the standard) not in other compilers either.
>
> Just to be clear, this is no longer about the repl. The discussion
> moved on to the order of definitions in files a few messages back.
>
> Because of mutual recursion, Lisp compilers have to be able to deal
> with definitions that refer to definitions that occur later in the
> file, and so there has been little reason for a bottom-up culture to
> develop in the Lisp world.
They have to be able to deal with forward referring definitions, yes.
They don't have to deal with them terribly well.
Compare the diagnostics emitted for the following non-conforming code
in your various compilers:
(defun f (x)
(g x))
(defun g (x y)
(+ x y))
with that for the equally non-conforming
(defun h (x y)
(+ x y))
(defun i (x)
(h x))
My guess is that at least some will emit a diagnostic for the second
case, but not the first. It is of course possible to treat both cases
in similar ways, but I hope you see that one of them is easier to
signal a diagnostic for than the other.
> So I'm certainly not alone in writing code that way; and some
> well-known Lisp implementors (at least) are with me in this heresy.
Fine.
>> > Do people really now regard placing their code in bottom-up
>> > order as normal good practice? If so, why? What's happened?
>> > Is this a "generational" change? Have people been brought up
>> > using one-pass compilers?
>>
>> I suspect, actually, that people regard using a system definition
>> facility, and tools which aid in dealing with compiler diagnostics, as
>> more important than typing definitions into a REPL. Just because it's
>> there doesn't mean it's the best way to do it.
>
> Back, briefly, to the repl. The definition was just an example. If I
> merely make a spelling mistake in a form, I don't just get a nice
> message saying I'm calling an undefined function. I get line after
> line of output about "style warnings".
As has been pointed out to you, "style warnings" from SBCL do not mean
"you have no style", it means "the style you have chosen to use is
potentially opaque, or we may have a problem with understanding your
meaning". Yes, the compiler messages are probably a little
intimidating; no, I don't think that this is a major blemish. Your
mileage may, of course, vary. (Actually, this discussion has reraised
in my consciousness a possible way of simulating an interpreter a
little more accurately even in a compiler-only implementation: details
on request)
> As for defsys, all the ones I've used treat each file as a
> unit, and such a defsys is irrelevant to the order of definition
> within a file.
There exist some which treat each module or each system as a unit, not
just each file.
> Are there some optimizations or checks it cannot perform if
> the definitions are not in bottom-up order?
(yes, see above)
> If compilers are limited in that way, I'd regard it as a
> temporary phenomenon: they're sufficiently sophisticaed
> that they can do clever optimization and analysis, but
> not to the point where they stop depending on the order
> of function definitions in the file.
Oh, I can believe it's a temporary phenomenon; it stays until the
dependence on the definition order annoys someone sufficiently to work
on removing the dependence. You seem to be sufficiently annoyed, but
maybe not motivated to work on it. :-)
> But I don't know the details of SBCL's implementation. Perhaps it
> has some problem with top-down order in files. I'be be surprised
> if it did, but I don't know for sure that it doesn't.
It doesn't have a problem in the sense that it would generate
incorrect code, no, but in general, short of doing a full two-pass
over the entire contents of a file, there is no way of optimizing
fully something of the form
(defun foo (x)
(1+ (g x)))
(defun g (x)
(declare (type (integer 0 #.(1- most-positive-fixnum)) x))
x)
The call to 1+ can provably be optimized into a fixnum addition, but
only if the compiler goes back and recompiles FOO /after/ having seen
the definitiong of G, as when FOO is encountered, the return value of
G could be any number. This is similar to, but more subtle than, the
obvious dependence on order for inline expansion. I suspect the
overwhelming expectation on the performance characteristics of
COMPILE-FILE is that it is linear in the source, while doing multiple
passes makes it potentially exponential.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Christophe Rhodes wrote:
> I suspect the overwhelming expectation on the performance
> characteristics of COMPILE-FILE is that it is linear in the source,
> while doing multiple passes makes it potentially exponential.
I think you give compiler users too much credit. We're generally a
humble bunch, because we don't understand how the magic (of producing a
correct binary from incorrect source) happens. :-)
The user of an optimizing compiler doesn't, I think, have much of an
expectation that the performance is linear in *anything*.
That said, would it be very difficult for SBCL to slurp all the
definitions into a set, and then to keep pulling out and compiling forms
without references to undefined functions until there aren't anymore,
then do the mutually recursive ones, etcetera? Obviously, a check has to
be made for the pathological user who hands you a 5M source file, but I
think the vast majority of SBCL users would have the RAM for the scheme
to be workable.
Yes, I know: Wishing on Usenet isn't coding.
--
Cameron MacKinnon
Toronto, Canada
File 1 [top-down]:
(defun f (x) (g x))
(defun g (x y) (* x y))
File 2 [bottom-up]:
(defun g (x y) (* x y))
(defun f (x) (g x))
I tested by compiling each file using compile-file in a fresh
Lisp.
CMUCL: Detects the problem in both files. For 1, it says
Warning: Function previously called with one argument, but wants at
least two
For 2, it says
Warning: Function called with one argument, but wants exactly two.
CLisp: complains in both cases with the same message:
G was called with 1 arguments, but it requires 2 arguments.
Franz Lisp (a pre-Common Lisp) with a straightforward compiler:
Detects the problem only for file 2.
GCL 2.3: Doesn't complain in either case.
SBCL: Doesn't complain in either case.
I tried various optimize settings without success.
(That's all I have handy these days.)
So the Franz Lisp compiler was the only one that told me
about the problem only for the bottom-up file. (N.B. Franz
Lisp, a pre-Common relative of MacLisp, *NOT* Franz Inc's
Common Lisp.) And it's not a Common Lisp compiler.
The CMUCL messages suggest an implementation that is straightforward
and should be reasonably efficient: accumulate information about
functions not yet seen when compiling calls to those functions;
then check when the actual definition comes along.
Optimization is obviously a more complex issue, but I would
expect highly-optimizing compilers to do some whole-compilation-
unit analysis.
-- jd
Christophe Rhodes <·····@cam.ac.uk> writes:
> > Because of mutual recursion, Lisp compilers have to be able to deal
> > with definitions that refer to definitions that occur later in the
> > file, and so there has been little reason for a bottom-up culture to
> > develop in the Lisp world.
>
> They have to be able to deal with forward referring definitions, yes.
> They don't have to deal with them terribly well.
>
> Compare the diagnostics emitted for the following non-conforming code
> in your various compilers:
After misunderstanding Kenny Tilton, I want to make sure I'm not
misunderstanding you.
You believe that people should put their code in files in bottom-up
order because of compiler limitations?
That top-down order in files "seems particularly perverse" and
seems to be "going out of your way to make things difficult for
automated tools" and "actively subverting them"?
That making it easier for automatic tools to signal diagnostics
(and optimize) is more important than readability, logical structure,
and so on?
And that Lisp programmers should use bottom-up order even though, say,
Java programmers (those unfortunates) don't have to worry about it,
because even their worst compiler can give the diagnostics with
either order? :(
> > Back, briefly, to the repl. The definition was just an example. If I
> > merely make a spelling mistake in a form, I don't just get a nice
> > message saying I'm calling an undefined function. I get line after
> > line of output about "style warnings".
>
> As has been pointed out to you, "style warnings" from SBCL do not mean
> "you have no style",
I never said, assumed, implied or presupposed (that should cover it :))
that they meant "you have no style".
> it means "the style you have chosen to use is
> potentially opaque, or we may have a problem with understanding your
> meaning". Yes, the compiler messages are probably a little
> intimidating; no, I don't think that this is a major blemish.
SBCL's "STYLE-WARNING"s can't quite mean that, because they also
occur for plain errors such as calling an undefined function.
If I start SBCL and ask it for (f x), I get 21 lines of output related
to "STYLE-WARNING"s, and then something like 14 more useful lines.
And of the 14, some are intended for beginners, and it tells me how to
turn them off.
So the 14 lines, good; the 21 lines, bad. All but 4 of them:
the ones that tell me the undefined function name, the undefined
variable, and where the problem was. Those 4 are good, the rest
should go.
> Your
> mileage may, of course, vary. (Actually, this discussion has reraised
> in my consciousness a possible way of simulating an interpreter a
> little more accurately even in a compiler-only implementation: details
> on request)
Compiler-only implementations do not have to behave the way
SBCL does, and they don't have to simulate an interpreter
in order to avoid so much uninformative diagnostic output.
> > If compilers are limited in that way, I'd regard it as a
> > temporary phenomenon: they're sufficiently sophisticaed
> > that they can do clever optimization and analysis, but
> > not to the point where they stop depending on the order
> > of function definitions in the file.
>
> Oh, I can believe it's a temporary phenomenon; it stays until the
> dependence on the definition order annoys someone sufficiently to work
> on removing the dependence. You seem to be sufficiently annoyed, but
> maybe not motivated to work on it. :-)
Your opinion (below) seems to be that it would have unacceptable
cost.
I used to spend a lot of time ensuring that I had Lisps I wanted to
use on the machines where I wanted to use them, porting
implementations, fixing bugs, and so on.
But I don't have time any more; and it sounds like the SBCL
implementors would be opposed to such a change. So it's
overdetermined that I won't work on it.
> > But I don't know the details of SBCL's implementation. Perhaps it
> > has some problem with top-down order in files. I'be be surprised
> > if it did, but I don't know for sure that it doesn't.
>
> It doesn't have a problem in the sense that it would generate
> incorrect code, no, but in general, short of doing a full two-pass
> over the entire contents of a file, there is no way of optimizing
> fully something of the form
> (defun foo (x)
> (1+ (g x)))
> (defun g (x)
> (declare (type (integer 0 #.(1- most-positive-fixnum)) x))
> x)
> The call to 1+ can provably be optimized into a fixnum addition, but
> only if the compiler goes back and recompiles FOO /after/ having seen
> the definitiong of G, as when FOO is encountered, the return value of
> G could be any number. This is similar to, but more subtle than, the
> obvious dependence on order for inline expansion. I suspect the
> overwhelming expectation on the performance characteristics of
> COMPILE-FILE is that it is linear in the source, while doing multiple
> passes makes it potentially exponential.
I don't mind having some order-dependencies, such as a requirement
that macros be defined before use, or that inline declarations don't
have effects back in time. Perhaps I've just learned to live with
them.
But those are special cases. If Lisp programmers are supposed
to use bottom-up order in general, because of the compilers,
then that's a reason to use some other language rather than
Lisp.
It would be ironic, to say the least, if better Lisp compilers, rather
than giving Lisp programmers greater freedom from micro-efficiency
concerns, led to a triumph of the "C mindset". :(
Cheers.
"Jeff Dalton" <····@todday.inf.ed.ac.uk> wrote in message
····················@todday.inf.ed.ac.uk...
> Christophe Rhodes <·····@cam.ac.uk> writes:
>
> > > Because of mutual recursion, Lisp compilers have to be able to deal
> > > with definitions that refer to definitions that occur later in the
> > > file, and so there has been little reason for a bottom-up culture to
> > > develop in the Lisp world.
> >
> > They have to be able to deal with forward referring definitions, yes.
> > They don't have to deal with them terribly well.
> >
> > Compare the diagnostics emitted for the following non-conforming code
> > in your various compilers:
>
> After misunderstanding Kenny Tilton, I want to make sure I'm not
> misunderstanding you.
>
> You believe that people should put their code in files in bottom-up
> order because of compiler limitations?
>
> That top-down order in files "seems particularly perverse" and
> seems to be "going out of your way to make things difficult for
> automated tools" and "actively subverting them"?
>
> That making it easier for automatic tools to signal diagnostics
> (and optimize) is more important than readability, logical structure,
> and so on?
>
> And that Lisp programmers should use bottom-up order even though, say,
> Java programmers (those unfortunates) don't have to worry about it,
> because even their worst compiler can give the diagnostics with
> either order? :(
Not commenting on Christophe Rhodes POV at all (ie not even what it is or is
not), but my answer to all of your questions is a resounding NO! I too, by
far, prefer to start my file with
(defun solve-world-hunger ()
(produce-food)
(distribute-food)
(feed-people))
and let the details sort themselves out down below. This may or may not be
the way I built the code, but it is the way I will leave it and the way I
want to see it. I'll go a step farther and say that I also think it is The
Right Way.
I am unaware of any drawbacks this may or may not have ever caused my code
to have, but would think less of my tools if I discovered there were any
serious ones. That said, if I had any pressing optimization concerns and my
implementation told me changing the file(s) around would squeeze out the
last bit of juice I would probably do it and not grumble very much.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
From: Bulent Murtezaoglu
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <87llle3yeo.fsf@cubx.internal>
>>>>> "CR" == Christophe Rhodes <·····@cam.ac.uk> writes:
[...]
CR> To give a concrete example, my workflow when I start work in
CR> the morning is to start an emacs, [...]
I'll let starting work in the morning slip but you mean you don't
leave your emacs/lisp context running? My present repl+emacs is
about 30 days old. I occasionally do start a fresh lisp just to make
sure everything compiles and runs just using the files/defsys, but work
happens in the old repl/emacs. I find killing my lisp worlds too painful
as too much valuable context builds up in the heat of productivity
that I wouldn't know how to systematically save, name and label in
files. (foo, real-foo, <expletive>-data and such are fine names for
repl but would have to be named properly and explained in files for
example. Commenting interesting stuff in the huge inferior-lisp
buffer and ctrl-r is much easier). I thought others did this too.
Maybe I am missing something? Is it that you work on the compiler?
Hmm, I just realized I have not really watched any lisper while he
works for any extensive period of time. How do you guys work?
cheers,
BM
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sqfzbmaym0.fsf@lambda.dyndns.org>
Bulent Murtezaoglu <··@acm.org> writes:
>>>>>> "CR" == Christophe Rhodes <·····@cam.ac.uk> writes:
> [...]
> CR> To give a concrete example, my workflow when I start work in
> CR> the morning is to start an emacs, [...]
>
> I'll let starting work in the morning slip but you mean you don't
> leave your emacs/lisp context running? My present repl+emacs is
> about 30 days old. I occasionally do start a fresh lisp just to make
> sure everything compiles and runs just using the files/defsys, but work
> happens in the old repl/emacs. I find killing my lisp worlds too painful
> as too much valuable context builds up in the heat of productivity
> that I wouldn't know how to systematically save, name and label in
> files. (foo, real-foo, <expletive>-data and such are fine names for
> repl but would have to be named properly and explained in files for
> example. Commenting interesting stuff in the huge inferior-lisp
> buffer and ctrl-r is much easier). I thought others did this too.
> Maybe I am missing something?
Well, I work incrementally, yes, but what I do is edit the files
containing my application directly, and send definitions to Lisp with
C-c C-c or similar keystrokes. I tend not to build up important state
in the Lisp independent of definitions within files. Therefore, in
the morning, what happens is that files which contain changed
definitions since the last time get recompiled fully. And then work
begins again.
I don't run long-running lisp sessions during development because I
tend to move around geographically, and so my development machine
happens to be a battery-deprived laptop. I don't feel that I would be
noticeably more productive with a long-lived state, but I haven't
worked that way extensively beyond incremental modification of server
applications.
> Is it that you work on the compiler?
Partly it is. SBCL itself is not a "typical" lisp application,
although for certain modifications I do work incrementally. But yes,
generally work on SBCL itself is more batch-oriented, though I do have
fingers in application work too.
Perhaps partly it's because programming isn't what I do; research is
what I do, and the Lisp development is only incidental.
Cheers,
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
Bulent Murtezaoglu <··@acm.org> writes:
> >>>>> "CR" == Christophe Rhodes <·····@cam.ac.uk> writes:
> [...]
> CR> To give a concrete example, my workflow when I start work in
> CR> the morning is to start an emacs, [...]
>
> I'll let starting work in the morning slip but you mean you don't
> leave your emacs/lisp context running? My present repl+emacs is
> about 30 days old. I occasionally do start a fresh lisp just to make
> sure everything compiles and runs just using the files/defsys, but work
> happens in the old repl/emacs. I find killing my lisp worlds too painful
> as too much valuable context builds up in the heat of productivity
> that I wouldn't know how to systematically save, name and label in
> files. (foo, real-foo, <expletive>-data and such are fine names for
> repl but would have to be named properly and explained in files for
> example. Commenting interesting stuff in the huge inferior-lisp
> buffer and ctrl-r is much easier). I thought others did this too.
> Maybe I am missing something? Is it that you work on the compiler?
>
> Hmm, I just realized I have not really watched any lisper while he
> works for any extensive period of time. How do you guys work?
I used to use a heavily image-based process, where I'd start up a
project, edit files, evaluating forms, testing at the repl, inspecting
things, etc. I'd generally try to keep my Lisp image running, but
would once in a while have to shut it down. So, I'd save an image,
and when I started up work again, for most purposes, it was like I'd
never shut the lisp down.
After a couple of bootstrapping nightmares, I decided that while
that's a good way to work with Squeak, it's not such a good way to
work with CMUCL. So, since then, I've been restarting my Lisp after a
certain amount of work, generally a day to a week's worth. If I hit a
bootstrapping problem, I'm guaranteed that it hasn't been too long
since the system was bootstrappable. But the biggest advantage I've
noticed is how I used to have a ton of state built up in the image.
I'd slowly accrete interesting objects and stuff, in temp variables
with names like >>THE-PROBLEMATIC-TREE (I prepend >> to my temp
variables). Now, I still fiddle with things at the repl, but if I
have something interesting, I put the forms I need to build it in a
scratch file, so the next time I load the system, I can get
>>THE-PROBLEMATIC-TREE back. With nice commands like
inspect-current-defun, I do less and less work at the actual repl,
because I might as well record it in my scratch file.
The big win here is that once I'm pretty confident the system is
working, I have a file full of all those silly little tests that I
wrote to get to that point. At that point, it's easy to harvest from
there to get a decent set of tests, and look like I was extremely
disciplined from the start :-). I put a smiley there, but really, I
suspect that Lispers who test at the repl are losing valuable
information when it scrolls off the screen. Part of the reason you
don't want to write tests is the feeling that you *already* tested the
code. Well, duh, why not save those tests in the first place?
Just my 2 cents.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Tim Bradshaw
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <ey3oeq4gang.fsf@cley.com>
* Christophe Rhodes wrote:
> There is an interesting class of functionality that can be done if the
> code comes in the other order; various detections of errors, such as
> argument count mismatch, can be performed at compile-time (thus
> allowing SBCL to return useful values from COMPILE and COMPILE-FILE).
> The top-down style inhibits this ability to detect errors (and other
> incidental possibilities, such as elision of argument count checks,
> type inference, and so on), which is why the compiler in general emits
> a STYLE-WARNING for this style.
However there is also an interesting class of functionality that is
not possible if the system bitches incessantly and with no easy way of
turning this bitching off. This class of functionality is called
`having a running computer to work on', because the user has become so
angry with the bloody compiler that they have thrown the machine at
the wall and sworn never to use the system again, even when they've
saved up for a new computer to run it on.
A related thing that such systems cannot generally achieve is be
reliably debugged by a human: there are so many warning messages that
it becomes impossible to find the ones that actually count for
something unless you work excessively hard to do so.
I'm serious: these kinds of style warnings for code which is perfectly
legal but which the compiler might not be able to infer something
about should be inhibitable by some simple global switch. Perhaps
they are in SBCL: if they're not I suggest they should be.
--tim
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sq65cczumz.fsf@lambda.dyndns.org>
Tim Bradshaw <···@cley.com> writes:
> However there is also an interesting class of functionality that is
> not possible if the system bitches incessantly and with no easy way of
> turning this bitching off. This class of functionality is called
> `having a running computer to work on', because the user has become so
> angry with the bloody compiler that they have thrown the machine at
> the wall and sworn never to use the system again, even when they've
> saved up for a new computer to run it on.
Yes... use your anger... give in to it... you shall be turned!
Honestly, if the thought of compiler messages irritates you this much,
then by all means feel free not to consider systems which tend to emit
more rather than fewer compiler messages. I'm a little surprised at
your vehemence, though.
> A related thing that such systems cannot generally achieve is be
> reliably debugged by a human: there are so many warning messages that
> it becomes impossible to find the ones that actually count for
> something unless you work excessively hard to do so.
Yes, "impossible". It must be excessively hard to use a functional
IDE, which separates the messages into suitable categories, thanks to
the behaviour defined in the Common Lisp Standard. If the worst comes
to the worst, is
(handler-bind ((style-warning #'muffle-warning))
(defsys:compile-and-load :system))
so hard? Though of course this is a long way from the state of the
art these days.
> I'm serious: these kinds of style warnings for code which is perfectly
> legal but which the compiler might not be able to infer something
> about should be inhibitable by some simple global switch. Perhaps
> they are in SBCL: if they're not I suggest they should be.
Thank you for your thought. As it happens, one of my development
avenues over the last six months or so has been the slow tweaking of
the system such that one can do
(declaim (muffle-conditions style-warning))
to achieve what would seem to place you in a state of Nirvana, or, I
think more usefully,
(defun foo (x y)
(declare (optimize speed))
;; I know this can't be optimized fully, so don't whine
(declare (muffle-conditions compiler-note))
(+ x y))
However, I honestly don't think this is that big a deal; you clearly
do, and that's fine, but fortunately for my sanity I don't feel
obligated to solve everyone else's big deal problems, even if they
show up on USENET criticising design decisions.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Tim Bradshaw
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <ey3n05oelsm.fsf@cley.com>
* Christophe Rhodes wrote:
> Honestly, if the thought of compiler messages irritates you this much,
> then by all means feel free not to consider systems which tend to emit
> more rather than fewer compiler messages. I'm a little surprised at
> your vehemence, though.
I want to distinguish between things that are actually an issue (you
used this deprecated function) and things which are the compiler
muttering about some optimisation which I don't care about in the
least. In particular I want to have my system compile with no warnings
of any kind at all. If it then warns *at all* I know it's a problem
which needs to be addressed, for instance.
> Yes, "impossible". It must be excessively hard to use a functional
> IDE, which separates the messages into suitable categories, thanks to
> the behaviour defined in the Common Lisp Standard. If the worst comes
> to the worst, is
> (handler-bind ((style-warning #'muffle-warning))
> (defsys:compile-and-load :system))
> so hard? Though of course this is a long way from the state of the
> art these days.
That precisely does not solve my problem. I might signal style
warnings of my own in macros, and I don't want to inhibit them. If
there is a documented set of condition classes that are signalled that
are of the `I can't optimise calls to functions I haven't yet seen'
kind, that would be fine.
> Thank you for your thought. As it happens, one of my development
> avenues over the last six months or so has been the slow tweaking of
> the system such that one can do
> (declaim (muffle-conditions style-warning))
> to achieve what would seem to place you in a state of Nirvana, or, I
> think more usefully
Again, that's precisely not what I want: inhibiting STYLE-WARNINGs is
no use at all. I want much finer-grained control than that. It may be
SBCL has this: I didn't mean to imply it doesn't. I think you didn't
really understand what I wrote:
However there is also an interesting class of functionality that is
not possible if the system bitches incessantly and with no easy way
of turning this bitching off.
does not imply that SBCL is such a system. It's trying to encourage
people not to create such systems. Never mind, your response has put
me off SBCL better than any almost amount of trouble using it could
have done.
--tim
From: Christophe Rhodes
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <sq65cckyxm.fsf@lambda.dyndns.org>
Tim Bradshaw <···@cley.com> writes:
> * Christophe Rhodes wrote:
>
>> Yes, "impossible". It must be excessively hard to use a functional
>> IDE, which separates the messages into suitable categories, thanks to
>> the behaviour defined in the Common Lisp Standard. If the worst comes
>> to the worst, is
>> (handler-bind ((style-warning #'muffle-warning))
>> (defsys:compile-and-load :system))
>> so hard? Though of course this is a long way from the state of the
>> art these days.
>
> That precisely does not solve my problem. I might signal style
> warnings of my own in macros, and I don't want to inhibit them. If
> there is a documented set of condition classes that are signalled that
> are of the `I can't optimise calls to functions I haven't yet seen'
> kind, that would be fine.
Right. This is definitely on the roadmap for SBCL (though obviously
given your attitude this is probably no longer of interest to you
personally, it may be of interest to others). It's a much more
interesting issue than that in your original rant, too.
>> Thank you for your thought. As it happens, one of my development
>> avenues over the last six months or so has been the slow tweaking of
>> the system such that one can do
>> (declaim (muffle-conditions style-warning))
>> to achieve what would seem to place you in a state of Nirvana, or, I
>> think more usefully
>
> Again, that's precisely not what I want: inhibiting STYLE-WARNINGs is
> no use at all. I want much finer-grained control than that. It may be
> SBCL has this: I didn't mean to imply it doesn't.
Oh, it doesn't; not beyond a rather crufty OPTIMIZE
SB-EXT:INHIBIT-WARNINGS compiler policy quality, which turns out not
to give sufficient control; I suspect that integral values between 0
and 3 don't count as very fine-grained :)
There are two axes on which fine-grained control is, I think,
desireable; the mechanism I described in my previous post only
addresses one. The one I addressed is fine-grained locality control,
so it is possible to say "I know that the system cannot optimize this
function fully, and I don't care"; "I acknowledge that one of these
code branches is dead"; similar statements, but the key is that the
scope of these statements can be lexical; it does not have to be
global (as it would be with some special variable switch) or dynamic
(with a handler).
The other dimension of desired fine-grained control is the class of
condition signalled; attaching sufficient semantic meaning to sets of
diagnostics that they can be identified by a class beyond the severity
of the condition is of course necessary for full control. Those still
following on at home might be interested by a recent message on the
development mailing list
<http://article.gmane.org/gmane.lisp.steel-bank.devel/2849>, where
just this issue was discussed.
> I think you didn't really understand what I wrote:
>
> However there is also an interesting class of functionality that is
> not possible if the system bitches incessantly and with no easy way
> of turning this bitching off.
>
> does not imply that SBCL is such a system. It's trying to encourage
> people not to create such systems.
Quite. And so I would have thought that my previous response, talking
about what we are looking at to address this concern, including a (to
my knowledge) new mechanism for lexical control, and this one, talking
about what we are looking at to address the concerns raised by my
responses to your concerns, would be counted as a positive
contribution, not a negative one, but... no matter.
Christophe
--
http://www-jcsu.jesus.cam.ac.uk/~csr21/ +44 1223 510 299/+44 7729 383 757
(set-pprint-dispatch 'number (lambda (s o) (declare (special b)) (format s b)))
(defvar b "~&Just another Lisp hacker~%") (pprint #36rJesusCollegeCambridge)
From: Tim Bradshaw
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <ey365cccegv.fsf@cley.com>
* Christophe Rhodes wrote:
> Right. This is definitely on the roadmap for SBCL (though obviously
> given your attitude this is probably no longer of interest to you
> personally, it may be of interest to others). It's a much more
> interesting issue than that in your original rant, too.
It's precisely the same issue: it is important for usability that the
system can be easily persuaded not to complain excessively, where
`excessively' means complaining about things which are non-problems.
Since this definition is obviously user-dependent, this means that the
system needs to have easily adjustable parameters. If these
parameters are hard to adjust, too coarse (inhibit STYLE-WARNINGS), or
require pervasive changes to code (lots of implementation-dependent
declarations in the code), then the system will not be of interest to
significant numbers of people.
For what it's worth, as a random user, I'd consider complaining during
file or system compilation about forward references to be fine
(especially if the system definition tool provides compilation units).
Complaining about forward references during interactive definiton at
the listener would never be OK, unless I explicitly called COMPILE on
something.
--tim
Tim Bradshaw <···@cley.com> writes:
> For what it's worth, as a random user, I'd consider complaining during
> file or system compilation about forward references to be fine
> (especially if the system definition tool provides compilation units).
Do you mean references to functions outside the compilation
unit? Because there is nothing wrong with forward refs in
Lisp within a compilation unit.
The only time I would expect any complaint about them would be
if I was asking for a high degree of optimization and the
compiler ran into a case where it *actually was* producing
less efficient code than it could if the order were reversed.
-- jd
Jeff Dalton <····@todday.inf.ed.ac.uk> wrote in message news:<···············@todday.inf.ed.ac.uk>...
> Do you mean references to functions outside the compilation
> unit? Because there is nothing wrong with forward refs in
> Lisp within a compilation unit.
Yes, that's what I mean
> The only time I would expect any complaint about them would be
> if I was asking for a high degree of optimization and the
> compiler ran into a case where it *actually was* producing
> less efficient code than it could if the order were reversed.
I'd sort-of like this case not to be a STYLE-WARNING, although there
probably is no standard condition type that would be better.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> > The only time I would expect any complaint about them would be
> > if I was asking for a high degree of optimization and the
> > compiler ran into a case where it *actually was* producing
> > less efficient code than it could if the order were reversed.
>
> I'd sort-of like this case not to be a STYLE-WARNING, although there
> probably is no standard condition type that would be better.
Yes, I think it should explicitly say something about optimization
or efficiency.
-- jd
From: Tim Bradshaw
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <ey38ygzhf7i.fsf@cley.com>
* Jeff Dalton wrote:
> Yes, I think it should explicitly say something about optimization
> or efficiency.
You probably mean the same thing, but I specifically want it not to be
a subclass of STYLE-WARNING, so I can wrap things around the
compilation which catch just the conditions I'm interested in - I want
to know about style issues, but I may well not care at all about
optimisation problems.
--tim
Tim Bradshaw <···@cley.com> writes:
> * Jeff Dalton wrote:
>
> > Yes, I think it should explicitly say something about optimization
> > or efficiency.
>
> You probably mean the same thing, but I specifically want it not to be
> a subclass of STYLE-WARNING, so I can wrap things around the
> compilation which catch just the conditions I'm interested in - I want
> to know about style issues, but I may well not care at all about
> optimisation problems.
It would be nice to have a big refactoring of SBCL's compiler
conditions. But, short of that, it makes SBCL a lot more usable if
you set the INHIBIT-WARNINGS optmization setting. I'm not sure if
it's been mentioned in this thread -- you only see notes relevant to
optimization settings >= INHIBIT-WARNINGS. So, eg, if SPEED is 1 and
INHIBIT-WARNINGS is 2, you don't see all the optimization noise. If
you raise SPEED to 2, you do again.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
I just have a general comment on compiler warnings. Based on my prior
programming experience, I treat warnings as errors. Take this classic
C example:
if (a=b) {&body}
Most C compilers emit a style warning on that condition. Quite often,
I really did mean:
if (a==b) {&body}
In the case where I do want the asignment, I do something like this:
if ((a=b) == c) {&body}
So if a style warning tells me something like, "I can't optimize this
thing for reason X" and I can fix X fairly easily, I propbably will.
I am used to conforming to implimentations. If I get 10,000 warnings,
I'm going to be suffering from shock and awe.
Anyway, I'm just offering this up as another data point. So far I
haven't done anything fancy enough to illicit wild warnings. However,
the output from building SBCL from CVS is not yet useful to me. When
I am more comfortable with Lisp, I will pay more attention to that
output because I am interested in the development of SBCL, especially
on PPC Darwin and 64 bit platforms (although I don't have 64 bit
hardware yet).
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
"Christophe Rhodes" <·····@cam.ac.uk> wrote in message
···················@lambda.dyndns.org...
> > A related thing that such systems cannot generally achieve is be
> > reliably debugged by a human: there are so many warning messages that
> > it becomes impossible to find the ones that actually count for
> > something unless you work excessively hard to do so.
>
> Yes, "impossible".
I suspect Tim is being rhetorical there. But isn't it obvious that it is
"harder" and "inconvenient" to find warnings that really matter (like "FOO
refers to undefined BAR" - oops..oh yeah, I still have to....) when there
are many screens full of output?
I have this annoyance with LW too, because it tells me about every top level
form it is compiling. At least there I can search the output for '***' and
read the warnings. (I vaguely recall investigating how to quiet it but do
not recall the outcome)
> It must be excessively hard to use a functional
> IDE, which separates the messages into suitable categories, thanks to
> the behaviour defined in the Common Lisp Standard. If the worst comes
> to the worst, is
> (handler-bind ((style-warning #'muffle-warning))
> (defsys:compile-and-load :system))
> so hard? Though of course this is a long way from the state of the
> art these days.
Why didn't you volunteer this info much earlier?
> > I'm serious: these kinds of style warnings for code which is perfectly
> > legal but which the compiler might not be able to infer something
> > about should be inhibitable by some simple global switch. Perhaps
> > they are in SBCL: if they're not I suggest they should be.
>
> Thank you for your thought. As it happens, one of my development
> avenues over the last six months or so has been the slow tweaking of
> the system such that one can do
> (declaim (muffle-conditions style-warning))
> to achieve what would seem to place you in a state of Nirvana, or, I
> think more usefully,
> (defun foo (x y)
> (declare (optimize speed))
> ;; I know this can't be optimized fully, so don't whine
> (declare (muffle-conditions compiler-note))
> (+ x y))
This is a really bad idea. Tim's suggestion, "a global switch" is the best
way. Keep (setf *muffle-style-warnings* t) in a local init file and when
you are ready to get serious, set it to nil and then wade through the
output. Putting that kind of stuff in function bodies is really the Wrong
Way.
> However, I honestly don't think this is that big a deal; you clearly
> do, and that's fine, but fortunately for my sanity I don't feel
> obligated to solve everyone else's big deal problems, even if they
> show up on USENET criticising design decisions.
It should take as many lines of code as you just tossed off above to correct
this flaw. Your "design decision" is how and what to find and signal as
style warnings and you shouldn't feel criticized about that. Whether to
tell the user or not should be *their* choice.
What we computer geeks never seem to realize, to the detriment of the
industry, is that the programs we write are providing a *service* to
*people* and the old mantra "the customer is always right" needs to have
some considerable weight in what we chose to code. The other thing computer
geeks forget is that other computer geeks are people too.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
>
> What we computer geeks never seem to realize, to the detriment of the
> industry, is that the programs we write are providing a *service* to
> *people* and the old mantra "the customer is always right" needs to have
> some considerable weight in what we chose to code. The other thing computer
> geeks forget is that other computer geeks are people too.
>
Hear, hear! Even though I have sometimes been guilty as charged. 8-}
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
From: Ray Dillinger
Subject: Re: Why does SBCL ...? was Re: "The Little Lisper"
Date:
Message-ID: <4075887D.6A032394@sonic.net>
Coby Beck wrote:
> What we computer geeks never seem to realize, to the detriment of the
> industry, is that the programs we write are providing a *service* to
> *people* and the old mantra "the customer is always right" needs to have
> some considerable weight in what we chose to code. The other thing computer
> geeks forget is that other computer geeks are people too.
What the computer software industry never seems to realize, to its own
detriment, is that many programmers are artists who have no interest
in the customers' needs and only marginal interest in getting paid for
their work. The only way to stop such people from producing free software
is to give them the kind of projects to work on for pay that they want
to produce. Otherwise, these people will produce free code and, if it
*happens* to meet an existing customer need, the industry will then
have to compete with code written by artists - which, absent typical
scheduling demands and 'compatibility' requirements, tends to wind up
being higher quality code.
Bear
"Ray Dillinger" <····@sonic.net> wrote in message
······················@sonic.net...
> Coby Beck wrote:
>
> > What we computer geeks never seem to realize, to the detriment of the
> > industry, is that the programs we write are providing a *service* to
> > *people* and the old mantra "the customer is always right" needs to have
> > some considerable weight in what we chose to code. The other thing
computer
> > geeks forget is that other computer geeks are people too.
>
> What the computer software industry never seems to realize, to its own
> detriment, is that many programmers are artists who have no interest
> in the customers' needs and only marginal interest in getting paid for
> their work. The only way to stop such people from producing free software
> is to give them the kind of projects to work on for pay that they want
> to produce. Otherwise, these people will produce free code and, if it
> *happens* to meet an existing customer need, the industry will then
> have to compete with code written by artists - which, absent typical
> scheduling demands and 'compatibility' requirements, tends to wind up
> being higher quality code.
FWIW, I see no conflict between the above paragraphs (taking your use of the
word customer as literal and mine as just meaning "user").
Unfortunately, I feel that a fantastically elegant and artistically inspired
piece of software with a lousy user interface is rather like Michelangelo
finishing his statue of David by fastening it with twine to an old warehouse
palette.
Art requires discipline.
--
Coby Beck
(remove #\Space "coby 101 @ big pond . com")
"Coby Beck" <·····@mercury.bc.ca> writes:
> "Ray Dillinger" <····@sonic.net> wrote in message
> ······················@sonic.net...
> > Coby Beck wrote:
> >
> > > What we computer geeks never seem to realize, to the detriment of the
> > > industry, is that the programs we write are providing a *service* to
> > > *people* and the old mantra "the customer is always right" needs to have
> > > some considerable weight in what we chose to code. The other thing
> computer
> > > geeks forget is that other computer geeks are people too.
> >
> > What the computer software industry never seems to realize, to its own
> > detriment, is that many programmers are artists who have no interest
> > in the customers' needs and only marginal interest in getting paid for
> > their work. The only way to stop such people from producing free software
> > is to give them the kind of projects to work on for pay that they want
> > to produce. Otherwise, these people will produce free code and, if it
> > *happens* to meet an existing customer need, the industry will then
> > have to compete with code written by artists - which, absent typical
> > scheduling demands and 'compatibility' requirements, tends to wind up
> > being higher quality code.
>
> FWIW, I see no conflict between the above paragraphs (taking your use of the
> word customer as literal and mine as just meaning "user").
>
> Unfortunately, I feel that a fantastically elegant and artistically inspired
> piece of software with a lousy user interface is rather like Michelangelo
> finishing his statue of David by fastening it with twine to an old warehouse
> palette.
>
> Art requires discipline.
>
Indeed it does.
I find the user interface issue particularly thorny - it tends to be
more than bit subjective.
Speaking from experience, two different populations of users tend to
wish for different interfaces, usually with quite valid reasons. And
even if one had sufficient time and budget, does one really wish to
have two (or more) interfaces to support and maintain?
So we tend to end up with one generally usable, lowest common
denominator, recognizable-cousin-to-the-industry-standard interface.
To be quite honest, it has been quite sometime since I ran across a
free/open package that had what I considered to be an atrocious
interface. Overall, most interfaces seem to be pretty vanilla, and
generally useful.
How many architectural wonders can be truly appreciated from outside?
After all, they were meant to be used from the *inside*, and that is
where they tend to be truly magnificent. (There are, of course,
exceptions.)
I tend to consider software in the same light, and I think most
'users' do, as well - as long as the 'doors' and 'windows' behave
fairly predicatably.
--
We learn from history that we do not learn from history.
-- Georg Friedrich Wilhelm Hegel
Christophe Rhodes <·····@cam.ac.uk> writes:
> I don't feel
> obligated to solve everyone else's big deal problems, even if they
> show up on USENET criticising design decisions.
Of course you don't, and rightly so; but is there something wrong
with criticising design decisions?
I've used a lot of different Lisps. At one point, I had about
a dozen different Common Lisps available. SBCL seems to be an
excellent implementation in many ways, but it stands out for
the amount of stuff it throws at me for minor problems.
It's not only the style-warnings, though they're the most
glaring example.
Also, they're not really style warnings.
Because, one, they appear even for some out-and-out errors.
And because, two, you've said that they're because of optimization
issues, rather than style _per se_.
I would have been lot happier if they'd *said* something about
optimisation. Then I'd have felt I was at least getting some
useful information about what this implementation could handle
efficiently. The "feel" would be more like that of CMUCL.
Moreover, top-down style simply isn't bad style. If the
SBCL implementors think it *is* poor style, I'd like to know
why. As I mentioned, top-down order is common in code is
reasonably well regarded.
If there were style warnings about things that *were* generally
considered bad style, then they again would be useful information;
moreover, it would then make sense to turn them on or off as a group,
depending how much the user agreed or disagreed with the style rules.
Letting the style rules be changed would also be useful.
-- jd
In article <······················@mapcar.org>, Matthew Danish
<·······@andrew.cmu.edu> wrote:
> > 3) Any CL more compliant with the CL Standard than Digitool's MCL?
>
> I would venture to say that SBCL is less likely to have standards
> compliance bugs. It has recently been ported to OS X, though I
> understand that it is in somewhat of a developmental state. I haven't
> gotten a chance to play with it on OS X yet, but I will soon.
I would say that SBCL is pretty much production quality (as much as the
rest of the ports) on OS X. It doesn't have the amenities of the
x86/linux version (threads and gencgc), but those don't exist yet on
the other ports either.
OpenMCL is also very good.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Crossposted to comp.lang.scheme, so that Schemers and especially
Matthias.
On Fri, 02 Apr 2004 04:29:46 GMT, Mark Conrad
<············@invalid.com> wrote:
>
>I am trying to relearn CL after a l-o-o-n-g absence, however am
>running into problems, need some advice.
>
>Usually, I dive into 4 books:
>1) The Little Lisper
>2) The Little Schemer
>3) The Seasoned Schemer
>4) SICP
>
OK. now that he is reading, I must say that I found the
Little Listper the best of the "Little" books. After that
they became a bit too frivolous. Plus the existence of exercises help.
>...then revert to re-learning Common Lisp from various books.
>
>...then re-visit Scheme for a bit in the advanced:
> "Essentials of Programming Languages" book
>
>After all that, I consider myself mildly proficient in CL.<g>
>
>All that, BTW, takes me the better part of a year. (slow learner)
>
>Here are the problems I am running into, need advice on -
>
>1) Because I run the latest Mac OS's, not all Scheme implementations
>will run on that for various reasons. I would like a Scheme which is
>compliant with the present Scheme standard, has macros, and will run
>the exercises in The-Little-Lisper, SICP, etc. Any recommendations?
>
>Yes, I know, I should be asking this in the Scheme NG, but my main
>purpose is to re-learn CL, and I only use Scheme as an easy entry-way
>into re-learning Common Lisp.
>
>2) Has much changed in CL in the past 5 years while I have been away?
>
>3) Any CL more compliant with the CL Standard than Digitool's MCL?
>
>Thanks for any and all advice,
>
>Mark-
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
Mark Conrad <············@invalid.com> writes:
> 1) Because I run the latest Mac OS's, not all Scheme implementations
[...]
> 3) Any CL more compliant with the CL Standard than Digitool's MCL?
Everything you ever wanted to know about Common Lisp on Max OS X (by
Rainer Joswig):
http://lispm.dyndns.org:8000/lisp/lisp-and-macosx-2004-03.pdf
Have (de)fun
Paolo
--
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
In article <·······························@invalid.com>, Mark Conrad
<············@invalid.com> wrote:
> 1) Because I run the latest Mac OS's, not all Scheme implementations
> will run on that for various reasons. I would like a Scheme which is
> compliant with the present Scheme standard, has macros, and will run
> the exercises in The-Little-Lisper, SICP, etc. Any recommendations?
I will recommend two: Chicken and Gauche
http://www.call-with-current-continuation.org/
http://www.shiro.dreamhost.com/scheme/gauche/
Both of these are very well developed and run great on OS X. I use both
of them. Chicken in particular features a C translator / compiler using
Cheney on the MTA, and support for a large variety of extra libraries.
It also has an interpreter (csi).
There's also PLT, which has a flashy GUI interface, but is otherwise
mostly unimpressive. I'd rather work in Emacs anyway.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
On Sat, 03 Apr 2004 10:11:53 -0500, Brian Mastenbrook
<····················@cs.indiana.edu> wrote:
>In article <·······························@invalid.com>, Mark Conrad
><············@invalid.com> wrote:
>
>> 1) Because I run the latest Mac OS's, not all Scheme implementations
>> will run on that for various reasons. I would like a Scheme which is
>> compliant with the present Scheme standard, has macros, and will run
>> the exercises in The-Little-Lisper, SICP, etc. Any recommendations?
>
>I will recommend two: Chicken and Gauche
>
>http://www.call-with-current-continuation.org/
>http://www.shiro.dreamhost.com/scheme/gauche/
>
>There's also PLT, which has a flashy GUI interface, but is otherwise
>mostly unimpressive. I'd rather work in Emacs anyway.
That's the annoying thing about Scheme. PLT would be good to sort
of play around doing early prototypes, then go to a more serious
scheme later, but the libraries are incompatible.
BTW I'm looking a Bigloo for Windows but I can't figure out whether
Bee ( the emacs interface ) runs on Windows. Any ideas.
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
TLOlczyk <··········@yahoo.com> writes:
> >There's also PLT, which has a flashy GUI interface, but is otherwise
> >mostly unimpressive. I'd rather work in Emacs anyway.
> That's the annoying thing about Scheme. PLT would be good to sort
> of play around doing early prototypes, then go to a more serious
> scheme later, but the libraries are incompatible.
And what is it that is not serious enough about PLT? The existence of
a flashy GUI can only make it more serious -- since it implies that
the implementation should be serious enough to handle such a big
application, regardless of whether you actually use it or not.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
On 03 Apr 2004 16:46:17 -0500, Eli Barzilay <···@barzilay.org> wrote:
>TLOlczyk <··········@yahoo.com> writes:
>
>> >There's also PLT, which has a flashy GUI interface, but is otherwise
>> >mostly unimpressive. I'd rather work in Emacs anyway.
>> That's the annoying thing about Scheme. PLT would be good to sort
>> of play around doing early prototypes, then go to a more serious
>> scheme later, but the libraries are incompatible.
>
>And what is it that is not serious enough about PLT? The existence of
>a flashy GUI can only make it more serious
No not this GUI. A better word than flashy might be cheesy or maybe
juvenile. Beyond that I'm not answering except to point out that
I was simply agreeing with someone else's opinion. Ask him.
The reason for this is the reason that any successfully married man
knows not to answer the question "Honey, does this dress make me
look fat?", or talk about old girlfriends.
>-- since it implies that
>the implementation should be serious enough to handle such a big
>application, regardless of whether you actually use it or not.
I would hope that the compiler itself is large enough to
demonstrate the ability to handle large applications.
The largest project I worked on was larger than 5 million lines of
code. Most places I worked project started edging towards being
large when they approached 100,000 lines. I doubt the GUI comes
very close to this. From a function point perspective I would say
that the GUI is about a tenth of the function points that most
GUIs support and much less than other programming IDE's,
such a MSVC++, Delphi, C++Builder or Cincom's VisualWorks,
to name just a few.
The reply-to email address is ··········@yahoo.com.
This is an address I ignore.
To reply via email, remove 2002 and change yahoo to
interaccess,
**
Thaddeus L. Olczyk, PhD
There is a difference between
*thinking* you know something,
and *knowing* you know something.
TLOlczyk <··········@yahoo.com> writes:
> On 03 Apr 2004 16:46:17 -0500, Eli Barzilay <···@barzilay.org> wrote:
>
> >TLOlczyk <··········@yahoo.com> writes:
> >
> >And what is it that is not serious enough about PLT? The existence of
> >a flashy GUI can only make it more serious
> No not this GUI. A better word than flashy might be cheesy or maybe
> juvenile.
Oh sorry, you're absolutely right. This does indicate a very
unserious language.
> Beyond that I'm not answering except to point out that I was simply
> agreeing with someone else's opinion. Ask him.
Again, apologies. I don't know what I was thinking slapping someone
else's opinions over your post.
> The reason for this is the reason that any successfully married man
> knows not to answer the question "Honey, does this dress make me
> look fat?", or talk about old girlfriends.
You must be a very good husband. I envy your spouse.
> [blah blah blah] 5 million lines [blah blah blah]
I am ashamed to admit that I really cannot piss too far, certainly not
to compete with you.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
"TLOlczyk" <··········@yahoo.com> wrote:
> The largest project I worked on was larger than 5 million lines of
> code. Most places I worked project started edging towards being
> large when they approached 100,000 lines. I doubt the GUI comes
> very close to this.
In my experience, most commercial projects have code bases at least 4 to 10
times larger than they really ought to be, because they are implemented in
languages with a hard abstraction ceiling, e.g. no support for higher-order
functions, for a start.
A quick check indicates about 50,000 lines of Scheme code in the collections
most closely associated with the DrScheme gui (drscheme, mred, framework),
out of about 230,000 lines total. The DrScheme part would translate to
100,000 to 500,000 lines of commercial code. That includes doing some
things that no commercial environment is currently capable of doing.
> From a function point perspective I would say
> that the GUI is about a tenth of the function points that most
> GUIs support and much less than other programming IDE's,
> such a MSVC++, Delphi, C++Builder or Cincom's VisualWorks,
> to name just a few.
It's ludicrous to make a direct comparison like this. Those are all large
commercial projects, mostly implemented in C or C++, and their development
teams in some cases are orders of magnitude larger than PLT's. Any
comparison in terms of man-years invested would almost certainly demonstrate
that PLT has done an amazing job.
Just the other day, you were asking questions related to scoping and lexical
closure. If you want an environment, tools, and documentation that will
help you learn about these things, you could hardly do better than PLT
Scheme. Once you *have* learned about these things, you will have a better
understanding of why PLT Scheme's GUI is an incredible achievement. You'll
also be able to go and shave a few hundred kilolines off those bloated
commercial projects you're so proud of.
Anton
In article <··············@mojave.cs.cornell.edu>, Eli Barzilay
<···@barzilay.org> wrote:
> And what is it that is not serious enough about PLT? The existence of
> a flashy GUI can only make it more serious -- since it implies that
> the implementation should be serious enough to handle such a big
> application, regardless of whether you actually use it or not.
Everything in PLT feels half-done - like, there's a graphical
programming environment, but no debugger. There's an editor, but it
only accepts a small fraction of emacs keystrokes. And occasionally you
find "what were they thinking?" things about the environment - the
latest one I've noticed being that (expt -1 x) with x satisfying
integer? is not optimized via an odd? check. I think the PLT people are
more interested in having the appearance of a usable environment than
actually writing one, and appearance only goes so far.
--
Brian Mastenbrook
http://www.cs.indiana.edu/~bmastenb/
Brian Mastenbrook <····················@cs.indiana.edu> writes:
> Everything in PLT feels half-done - like, there's a graphical
> programming environment, but no debugger.
Actually what's holding off "the debugger" is the need to do it the
right way. I've put that in quotes because the environment has huge
amounts of debugging tools.
> There's an editor, but it only accepts a small fraction of emacs
> keystrokes.
Right -- the intention was not to provide an Emacs-compatible
environment... It would be nice to have one, but that will take huge
amounts of work which questionable value because Emacs is already
there. But after being skeptical for years, I can tell you that the
debugging aids in this environment make a *huge* difference compared
to the standard hack-in-Emacs approach or similar which is a major
obstacle for newbies. (This is based on my experience on courses that
vary from SCIP-based approach, through MIT's 6.001 and finally a
course with students that have no Scheme experience that would be a
complete disaster without DrScheme.)
> And occasionally you find "what were they thinking?" things about
> the environment - the latest one I've noticed being that (expt -1 x)
> with x satisfying integer? is not optimized via an odd? check.
This issue was raised recently (around november) in c.l.s, and you can
try it now, or believe the following:
| Welcome to MzScheme version 206, Copyright (c) 2004 PLT Scheme, Inc.
| > (time (expt -1 8))
| cpu time: 0 real time: 0 gc time: 0
| 1
| > (time (expt -1 9))
| cpu time: 0 real time: 0 gc time: 0
| -1
| > (time (expt -1 100000000008))
| cpu time: 0 real time: 0 gc time: 0
| 1
| > (time (expt -1 100000000009))
| cpu time: 0 real time: 0 gc time: 0
| -1
| > (time (expt -1 100000000000000000000000000000000000000008))
| cpu time: 0 real time: 0 gc time: 0
| 1
| > (time (expt -1 100000000000000000000000000000000000000009))
| cpu time: 0 real time: 0 gc time: 0
| -1
This is on a 400mhz machine.
> I think the PLT people are more interested in having the appearance
> of a usable environment than actually writing one, and appearance
> only goes so far.
I can enumerate around 5 big projects within PLT that have no relation
to GUI, and 5 more that are only using GUI.
The bottom line is that there is a lot of interest in having a usable
environment -- if you have any additional comments feel free to post
here or c.l.s, or mail the list.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Brian Mastenbrook wrote:
> I think the PLT people are
> more interested in having the appearance of a usable environment
> than actually writing one, and appearance only goes so far.
That's very far from being accurate. PLT Scheme is an impressive system by
a relatively small team (although big for the Scheme world). Like anyone
else, they have priorities, and the educational priorities are clear in the
GUI environment.
But even if you use some other environment to develop PLT code, the DrScheme
environment is an enormously helpful tool. For example, the syntax checker
provides a significant amount of static analysis, with the ability to
graphically and dynamically annotate programs with their lexical structure,
using arrows of various kinds. These are useful features which other
environments don't have.
If you look at DrScheme expecting something to replace a commercial-grade
development environment, or replace emacs, you'll likely be disappointed.
If you look at it to see what it *does* offer, you'll find it's doing things
that no-one else is doing, and doing them the right way.
If you're serious about Scheme, PLT is worth paying serious attention to.
Anton
(we should probably move this discussion to cls)
Eli Barzilay <···@barzilay.org> wrote in message news:<··············@mojave.cs.cornell.edu>...
> TLOlczyk <··········@yahoo.com> writes:
>
> > >There's also PLT, which has a flashy GUI interface, but is otherwise
> > >mostly unimpressive. I'd rather work in Emacs anyway.
> > That's the annoying thing about Scheme. PLT would be good to sort
> > of play around doing early prototypes, then go to a more serious
> > scheme later, but the libraries are incompatible.
>
> And what is it that is not serious enough about PLT? The existence of
> a flashy GUI can only make it more serious -- since it implies that
> the implementation should be serious enough to handle such a big
> application, regardless of whether you actually use it or not.
Correct me if I'm wrong, but PLT Scheme uses Boehm's GC (hack),
compiles to byte code, and in the GUI editor, you can't send one
S-expr to the listener with a single key stroke/combination.
I don't know if PLT is primarily meant to be a teaching aid, but if
this is true, maybe it should come with a flashy warning label that
says so?
BTW, is PLT GUI /configurable/ in scheme?
To add a little to what Mike said:
·············@yahoo.com (David Fisher) writes:
> Correct me if I'm wrong, but PLT Scheme uses Boehm's GC (hack),
By default yes, but it comes with a precise collector and I think that
there was another collector that was used at some point.
> compiles to byte code,
Yes, but also a Scheme->C compiler (and maybe a JIT compiler will come
at some point).
> and in the GUI editor, you can't send one S-expr to the listener
> with a single key stroke/combination.
This can only be written by someone who didn't use the environment.
It is meaningless to send a single expression to the listener. The
philosophy is quite different than Emacs.
> BTW, is PLT GUI /configurable/ in scheme?
And this is related to the above -- the GUI is *written* in Scheme,
and the way DrScheme works is by running user code in its own name
space etc. This means that there is no direct relation between user
Scheme code and the Scheme code that is the implementation.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> wrote in message news:<··············@mojave.cs.cornell.edu>...
> To add a little to what Mike said:
Mike wrote that all I had said "is almost completely wrong". I'll add
*'s to your reply for more drama:
>
> ·············@yahoo.com (David Fisher) writes:
>
> > Correct me if I'm wrong, but PLT Scheme uses Boehm's GC (hack),
>
> By default *yes*, but it comes with a precise collector and I think that
> there was another collector that was used at some point.
Note that what I wrote isn't "wrong". Additionally, the fact that
whomever makes decisions as to which GC to use chose Boehm's tells me
that the available alternative probably wasn't considered to be
better.
> > compiles to byte code,
>
> *Yes* , but also a Scheme->C compiler (and maybe a JIT compiler will come
> at some point).
That's nice, but not very useful to me. I run my programs almost
entirely from REPL. Again, where was I "wrong"?
> > and in the GUI editor, you can't send one S-expr to the listener
> > with a single key stroke/combination.
>
> This can only be written by someone who didn't use the environment.
> It is meaningless to send a single expression to the listener. The
> philosophy is quite different than Emacs.
Interesting logic here. I would have come to the opposite conclusion
in your place. Entertain us. If I never used "the environment", how
did I know about the fact that you can not send one S-expr to the
listener with a single key stroke/combination?
Regarding your claim that this feature is useless, I'll make a
counterclaim: I generally (meaning whatever language, system or
purpose) prefer to send expressions from a *persistent* buffer rather
than typing them in directly (in almost all cases). PLT clears the
listener buffer when I change the "main" source.
> > BTW, is PLT GUI /configurable/ in scheme?
>
> And this is related to the above -- the GUI is *written* in Scheme,
> and the way DrScheme works is by running user code in its own name
> space etc. This means that there is no direct relation between user
> Scheme code and the Scheme code that is the implementation.
Note that I emphasized "configurable", and you told me about and
emphasized "written". It's really not very clear to me if you are
saying it is configurable in Scheme (in the same sense that Emacs is
configurable through ~/.emacs in Emacs Lisp - this is what I meant by
"configurable").
FWIW, a number of people who program in PLT Scheme use both DrScheme and
Emacs for working on their code.
Personally, as a hardcore Emacs user for about 15 years, I mostly use
that beast, but fire up DrScheme whenever I need the various edit-time
static analysis tools they provide.
I can see moving almost exclusively to DrScheme (or a derivative) for
Scheme editing in a year or so. There are some Emacs features I want to
add to DrScheme first, which shouldn't be too hard to add once I make
time. (All my Scheme hacking right now is directly related to
job-hunting on Internet, social software, ontology, Semantic Web, XML,
etc. Generic Scheme tools hacking on Emacs/Quack and DrScheme has to be
deferred.)
--
http://www.neilvandyke.org/
·············@yahoo.com (David Fisher) writes:
> Eli Barzilay <···@barzilay.org> wrote in message
> news:<··············@mojave.cs.cornell.edu>...
> > To add a little to what Mike said:
>
> Mike wrote that all I had said "is almost completely wrong". I'll add
> *'s to your reply for more drama:
The drama is unnecessary. (It seems that it was really important to
you to point out every time I said "yes", which only makes it look
like you really need to win some fight here.)
> > ·············@yahoo.com (David Fisher) writes:
> >
> > > Correct me if I'm wrong, but PLT Scheme uses Boehm's GC (hack),
> >
> > By default *yes*, but it comes with a precise collector and I think that
> > there was another collector that was used at some point.
>
> Note that what I wrote isn't "wrong".
I don't care for a "wrong" or "right" label, just to have the correct
details out. If it makes you happy: you were not wrong. You were so
not wrong, that you were right.
> Additionally, the fact that whomever makes decisions as to which GC
> to use chose Boehm's tells me that the available alternative
> probably wasn't considered to be better.
There are reasons: two important ones are the fact that it takes more
memory (unsurprisingly), and that it makes interfacing the C world
much harder. But it's there and it's working. (I have a homework
submission server, which evaluates students code so things often get
pretty wild, and it is very stable.)
> > > compiles to byte code,
> >
> > *Yes* , but also a Scheme->C compiler (and maybe a JIT compiler
> > will come at some point).
>
> That's nice, but not very useful to me. I run my programs almost
> entirely from REPL. Again, where was I "wrong"?
In implicating that byte-code is the only option. You can still work
at the repl when you develop parts of your code, then compile away
things that work. PLT has a very good module system that will allow
you to write your code in independent pieces.
But if "yes" is so important for you -- here: you were not wrong, ok?
> > > and in the GUI editor, you can't send one S-expr to the listener
> > > with a single key stroke/combination.
> >
> > This can only be written by someone who didn't use the
> > environment. It is meaningless to send a single expression to the
> > listener. The philosophy is quite different than Emacs.
>
> Interesting logic here. I would have come to the opposite conclusion
> in your place. Entertain us. If I never used "the environment", how
> did I know about the fact that you can not send one S-expr to the
> listener with a single key stroke/combination?
Well, it *looks* like a listener in the Emacs sense, but it's not, and
spending more than 30 seconds with DrScheme makes it very clear. The
mode of work in Emacs is that there is a single repl session, which
you load files and feed expressions to. In DrScheme the situation is
different: you get a fresh environment every time you click execute,
which essentially evaluates your code in a clean namespace. Because
of this, it doesn't make sense to "send an expression to the
listener". An an Emacs user, I wouldn't even consider the DrScheme
interaction window as a "listener" since in my Emacs-washed mind that
term is associated with a prompt that is never being reset.
So, here's a bit that will make you happy: it is obvious that if you
wrote the above, then you did "use" the environment, but this is a
very shallow usage of "use".
> Regarding your claim that this feature is useless,
Huh? Where did I say that sending an expression to a repl is useless?
Are you confusing "meaningless" with "useless"?
> I'll make a counterclaim: I generally (meaning whatever language,
> system or purpose) prefer to send expressions from a *persistent*
> buffer rather than typing them in directly (in almost all cases).
> PLT clears the listener buffer when I change the "main" source.
Look, what I said is that the nature of the environment makes it
*meaningless* to send an expression to a repl. Using a repl is good
in itself, and I use it every day (in Emacs), trying to force DrScheme
into the same more of operation will not get too far.
> > > BTW, is PLT GUI /configurable/ in scheme?
> >
> > And this is related to the above -- the GUI is *written* in
> > Scheme, and the way DrScheme works is by running user code in its
> > own name space etc. This means that there is no direct relation
> > between user Scheme code and the Scheme code that is the
> > implementation.
>
> Note that I emphasized "configurable", and you told me about and
> emphasized "written". It's really not very clear to me if you are
> saying it is configurable in Scheme (in the same sense that Emacs is
> configurable through ~/.emacs in Emacs Lisp - this is what I meant
> by "configurable").
If it is written in Scheme, then adding functionality is done in
Scheme, then any kind of customization (according to the standard
definition of changing the default) must be done in Scheme. If you're
talking about a separate customization file, then there is none, and
many people would like to have one, except that there are not enough
resources for that. (And again, Emacs already exists...)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> wrote in message news:<··············@mojave.cs.cornell.edu>...
> Huh? Where did I say that sending an expression to a repl is useless?
> Are you confusing "meaningless" with "useless"?
So, in PLT, it's "useful", but "meaningless". And even though it's
"useful", I shouldn't criticize PLT for not letting me do it. I see.
Thanks for your input.
EOD.
·············@yahoo.com (David Fisher) writes:
> Eli Barzilay <···@barzilay.org> wrote in message news:<··············@mojave.cs.cornell.edu>...
>
> > Huh? Where did I say that sending an expression to a repl is
> > useless? Are you confusing "meaningless" with "useless"?
>
> So, in PLT, it's "useful", but "meaningless".
*sigh*
In general, a standard listener, the one you know in Emacs, is useful
-- this is true for most Scheme implementations including PLT. In
*DrScheme* it is meaningless -- don't confuse DrScheme with the rest
of PLT -- it comes with a very particular mode of work, but the
underlying MzScheme implementation is behaving in very standard way.
> And even though it's "useful", I shouldn't criticize PLT for not
> letting me do it. I see. Thanks for your input. EOD.
Oh you can definitely criticize anything you want as much as you
want, but when you do so, try to be a little more effective.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
David Fisher wrote:
> Note that what I wrote isn't "wrong". Additionally, the fact that
> whomever makes decisions as to which GC to use chose Boehm's
> tells me that the available alternative probably wasn't considered
> to be better.
This and earlier comments imply a negative opinion of Boehm's collector.
Why is that? It solves certain problems very neatly, in particular,
integration with C and C++ code, which is often an issue for a language like
Scheme. It also performs very well in practice. Is your opinion based on
actual experience with the collector?
Anton
"Anton van Straaten" <·····@appsolutions.com> wrote in message news:<····················@newsread2.news.atl.earthlink.net>...
> David Fisher wrote:
> > Note that what I wrote isn't "wrong". Additionally, the fact that
> > whomever makes decisions as to which GC to use chose Boehm's
> > tells me that the available alternative probably wasn't considered
> > to be better.
>
> This and earlier comments imply a negative opinion of Boehm's collector.
It's a hack, so it's not necessarily bad. It's very good for some
things, but the fact that you had to use it is likely to say that your
(C, I presume) programming skills are lacking (or you just have to
write "lisp in c")
> Why is that? It solves certain problems very neatly, in particular,
> integration with C and C++ code, which is often an issue for a language like
> Scheme. It also performs very well in practice. Is your opinion based on
> actual experience with the collector?
Do you have a negative opinion of your abilities to survive in vacuum?
Why is that? Is you opinion based on actual outer space experience?
:-)
We, homo sapiens, possess what is known as "reasoning ability". Unlike
other animals, we don't always need to experience bad things to know
they will hurt us.
I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
process references n Gigs, a random non-pointer bit pattern will be
interpreted as a pointer with the probability of n * 25% . The memory
referenced by such "pointers" will be traversed in search of more
"pointers". From this, it's pretty clear why some people have good
experience with Boehm's, while others know better.
This is getting off-topic in both groups, so I'm not going to discuss
this further. (There are other groups, where you can talk about
Boehm's in detail, if have a burning desire to)
David Fisher wrote:
> "Anton van Straaten" <·····@appsolutions.com> wrote in message
news:<····················@newsread2.news.atl.earthlink.net>...
> > David Fisher wrote:
> > > Note that what I wrote isn't "wrong". Additionally, the fact that
> > > whomever makes decisions as to which GC to use chose Boehm's
> > > tells me that the available alternative probably wasn't considered
> > > to be better.
> >
> > This and earlier comments imply a negative opinion of Boehm's collector.
>
> It's a hack, so it's not necessarily bad. It's very good for some
> things, but the fact that you had to use it is likely to say that your
> (C, I presume) programming skills are lacking (or you just have to
> write "lisp in c")
Perhaps my comprehension skills are lacking, but I don't understand this
sentence. If "it's very good for some things", then how does it imply that
anyone's C programming skills are lacking if they use it, especially for
something it's particularly good at, like supporting integration of a
garbage-collected language with C code?
Of course, you said "you had to use it", but I'm not sure where that came
from or who you're referring to. Who "had to" use it, and why?
> > Why is that? It solves certain problems very neatly, in particular,
> > integration with C and C++ code, which is often an issue for a language
like
> > Scheme. It also performs very well in practice. Is your opinion based
on
> > actual experience with the collector?
>
> Do you have a negative opinion of your abilities to survive in vacuum?
> Why is that? Is you opinion based on actual outer space experience?
> :-)
>
> We, homo sapiens, possess what is known as "reasoning ability". Unlike
> other animals, we don't always need to experience bad things to know
> they will hurt us.
That process assumes both an intact reasoning ability, and correct
knowledge.
I take it your answer to the question is no, you have no experience with the
Boehm collector.
> I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
> process references n Gigs, a random non-pointer bit pattern will be
> interpreted as a pointer with the probability of n * 25% . The memory
> referenced by such "pointers" will be traversed in search of more
> "pointers".
And your point is? The fact that it doesn't achieve perfect efficiency is
hardly unusual. I suppose you're not big on virtual machines either.
> From this, it's pretty clear why some people have good
> experience with Boehm's, while others know better.
Yeah, I get the idea. If you had anything substantive to say, this is the
point where you would have said it.
Anton
From: Grzegorz =?UTF-8?B?Q2hydXBhxYJh?=
Subject: Re: "The Little Lisper"
Date:
Message-ID: <c4uc83$15l$1@news.ya.com>
David Fisher wrote:
>
> We, homo sapiens, possess what is known as "reasoning ability". Unlike
> other animals, we don't always need to experience bad things to know
> they will hurt us.
<OT>
Non-human animals don't always need experience to know what to avoid (if you
stop to think for a moment examples will just spring to mind). Humans
probably rely on experience _more_ rather than _less_ than other animals,
i.e. our ability to extract information from environment based on
experience is more developed.
Not that it has any obvious bearing on the ongoing argument :-)
</OT>
--
Grzegorz Chrupała | http://pithekos.net | ·········@jabber.org
A scholar is just a library's way of making another library.
-- Daniel Dennett, Consciousness Explained
·············@yahoo.com (David Fisher) writes:
> I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
> process references n Gigs, a random non-pointer bit pattern will be
> interpreted as a pointer with the probability of n * 25%.
If you are familiar with the ALGORITHM, then you should know that that
the second statement is not true.
--
~jrm
> ·············@yahoo.com (David Fisher) writes:
>> I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
>> process references n Gigs, a random non-pointer bit pattern will be
>> interpreted as a pointer with the probability of n * 25%.
Joe Marshall wrote:
> If you are familiar with the ALGORITHM, then you should know that that
> the second statement is not true.
Here are some more hints, in case Joe's isn't obvious enough:
1. With word-aligned cells, the probability drops by factor of 4.
2. If you use the version of the algorithm that tracks objects rather
than words, the probability drops again, by a factor of 2 or more.
3. "Random non-pointer bit pattern" is a poor standard for measuring the
algorithm's efficiency, since program data is not random. Small
integers are common, and small integers almost never coincide with
object addresses. This drops the probability a lot more.
4. Gigabytes of data? On most 32-bit systems, you can't allocate GBs,
because there's less than 2 GB available to user processes.
5. Pointer aliasing is only a problem when the object "pointed" to is no
longer live.
So what's the actual probability of a pointer alias that retains data
that it shouldn't? Very, very low, maybe 1/2% per GB. In a typical
process with only megabytes of data, that's a very low chance of harmful
pointer aliasing. Yes, there are pathological cases which cause very bad
behavior. Fortunately, PLT Scheme has an alternate collection scheme for
those cases.
--
Bradd W. Szonye
http://www.szonye.com/bradd
"Bradd W. Szonye" <··········@szonye.com> writes:
> > ·············@yahoo.com (David Fisher) writes:
> >> I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
> >> process references n Gigs, a random non-pointer bit pattern will be
> >> interpreted as a pointer with the probability of n * 25%.
>
> Joe Marshall wrote:
> > If you are familiar with the ALGORITHM, then you should know that that
> > the second statement is not true.
>
> Here are some more hints, in case Joe's isn't obvious enough:
>
> 1. With word-aligned cells, the probability drops by factor of 4.
Up first, let me say that I don't want to defend Fisher's unjust
criticism fn the Boehm-Weiser algorithm. Also, I am not quite sure
what your reasoning is here, so you could be right. But for me to
believe that will require some exlaining.
In particular, I don't see how cell-alignment (in the context of
conservative collection) would lower the probability. Even if the
allocator doles out only 4-byte aligned pointers, your C program can
still do:
char *p = malloc (1024);
p = p + 1;
Now the pointer p is certainly not 4-byte aligned, but it must keep
the allocated memory alive.
> 2. If you use the version of the algorithm that tracks objects rather
> than words, the probability drops again, by a factor of 2 or more.
Can you explain?
> 3. "Random non-pointer bit pattern" is a poor standard for measuring the
> algorithm's efficiency, since program data is not random. Small
> integers are common, and small integers almost never coincide with
> object addresses. This drops the probability a lot more.
I consider this the strongest and most valid defense of the BW algorithm.
> 4. Gigabytes of data? On most 32-bit systems, you can't allocate GBs,
> because there's less than 2 GB available to user processes.
That does not help and probably hurts only more unless, e.g., the
address range available for allocation happens to be the one where the
high bit is set. After all, those integers that "point" there are the
ones that are rare, as you pointed out yourself.
>> > ·············@yahoo.com (David Fisher) writes:
>>>> I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
>>>> process references n Gigs, a random non-pointer bit pattern will
>>>> be interpreted as a pointer with the probability of n * 25%.
Joe Marshall wrote:
>>> If you are familiar with the ALGORITHM, then you should know that that
>>> the second statement is not true.
"Bradd W. Szonye" writes:
>> Here are some more hints, in case Joe's isn't obvious enough:
>>
>> 1. With word-aligned cells, the probability drops by factor of 4.
>> 2. If you use the version of the algorithm that tracks objects rather
>> than words, the probability drops again, by a factor of 2 or more.
Matthias Blume wrote:
> Up first, let me say that I don't want to defend Fisher's unjust
> criticism fn the Boehm-Weiser algorithm. Also, I am not quite sure
> what your reasoning is here, so you could be right. But for me to
> believe that will require some exlaining.
Object-tracking algorithms generally come in two varieties: Tracking all
interior pointers, and tracking only pointers to the start of an object.
This is true even for collectors designed for use with C and C++. GC
systems for those languages always impose some requirements regarding
"pointer swizzling" (e.g., using "unimportant" bits of a pointer to
store type bits, like many Scheme VMs do). It wouldn't be outrageous for
a conservative GC system to insist that programs always hold at least
one pointer to the head of an object. For example:
> In particular, I don't see how cell-alignment (in the context of
> conservative collection) would lower the probability. Even if the
> allocator doles out only 4-byte aligned pointers, your C program can
> still do:
>
> char *p = malloc (1024);
> p = p + 1;
>
> Now the pointer p is certainly not 4-byte aligned, but it must keep
> the allocated memory alive.
A conservative GC system that tracks head pointers only would deem this
pointer swizzle invalid. You'd need to write this instead:
char * obj = malloc(1024);
char * p = obj + 1;
You might even need to declare "obj" volatile to make sure that the
compiler can't optimize it away.
It's basically an ease-of-use vs efficiency trade-off. In an all-C
system, I doubt that you'd want to impose that strong a restriction, but
it might make sense for a mostly-Scheme system.
I don't know exactly how Boehm's algorithm handles this, nor do I know
how PLT's collector (which is a variant on Boehm's, IIRC) implements it.
I do know that it's a reasonable option for a conservative GC, though.
Anyway, this is somewhat speculative, which is why I called them "hints"
rather than "corrections." (I will admit to being condescending about
it, perhaps unreasonably so.)
>> 3. "Random non-pointer bit pattern" is a poor standard for measuring the
>> algorithm's efficiency, since program data is not random. Small
>> integers are common, and small integers almost never coincide with
>> object addresses. This drops the probability a lot more.
> I consider this the strongest and most valid defense of the BW algorithm.
Yes, it's the main reason why conservative GC is feasible (and the
reason why it fails for some classes of input).
>> 4. Gigabytes of data? On most 32-bit systems, you can't allocate GBs,
>> because there's less than 2 GB available to user processes.
> That does not help and probably hurts only more unless, e.g., the
> address range available for allocation happens to be the one where the
> high bit is set. After all, those integers that "point" there are the
> ones that are rare, as you pointed out yourself.
Very high addresses are a problem too, because they're congruent to
small negative numbers in twos-complement arithmetic.
Anyway, the address range for allocation "happens to be" congruent to
large positive numbers in most contemporary operating systems, AFAIK.
For example, IA-32 Linux reserves a huge chunk of low addresses for a
downward-growing stack, and it reserves the top half of memory for the
operating system, so collisions with small integers are practically
impossible. It's been a while since I studied the details, but IIRC
Windows and HP-UX both use a similar memory architecture.
--
Bradd W. Szonye
http://www.szonye.com/bradd
Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
> ·············@yahoo.com (David Fisher) writes:
>
> > I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
> > process references n Gigs, a random non-pointer bit pattern will be
> > interpreted as a pointer with the probability of n * 25%.
>
> If you are familiar with the ALGORITHM, then you should know that that
> the second statement is not true.
Since Szonye retracted his "explanation" in your support, perhaps
you'd like to tell us what you meant?
To Blume: I didn't criticize BW per se, only PLT's use of it as a
default for Scheme programs. If I were forced to develop a GC to use
with arbitrary leaking C programs, I would have hoped to come up with
something like BW.
I'm pretty busy at work these days, but if there are still
deliberations in about a week, and if there are still those who seem
intelligent but do not believe PLT is a toy, I'll write a simple
snippet that should run in constant space (and hopefully will run in
constant space in CMUCL), but that "explodes" under PLT (&BW).
Seriously, using the probability theory, Markov chains, etc. to
_estimate_ the probability (non-deterministic!) with which your
program will "explode" does not strike me as something to prefer to
manual memory management, let alone precise GC.
P.S. By PLT I usually mean DrScheme or MzScheme depending on the
context (There is always some anal-retentive that considers it his
duty to point out the obvious differences).
P.P.S. Knowing Joe Marshall's history on c.l.l, I think he was just
talking out of his you know what, but let's give him a chance.
David Fisher wrote:
> I'm pretty busy at work these days, but if there are still
> deliberations in about a week, and if there are still those who seem
> intelligent but do not believe PLT is a toy, I'll write a simple
> snippet that should run in constant space (and hopefully will run in
> constant space in CMUCL), but that "explodes" under PLT (&BW).
I don't have a dog in this fight, as I don't use PLT.
Why don't you just write a better GC for PLT? You seem to know what
you're talking about. I'm sure the reception would be much better than
to your pathological case which will purport to prove that an
implementation which has been used for serious work is a mere toy.
I'm not saying than a demonstration of the drawbacks of BW might not be
interesting reading for the type of person who can't just read the
research and quickly figure them out for himself, but if writing a
better GC doesn't take much longer than writing a demo of PLT/BW's
weaknesses, your rewards in posterity will be greater with the former.
--
Cameron MacKinnon
Toronto, Canada
·············@yahoo.com (David Fisher) writes:
> Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
>> ·············@yahoo.com (David Fisher) writes:
>>
>> > I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
>> > process references n Gigs, a random non-pointer bit pattern will be
>> > interpreted as a pointer with the probability of n * 25%.
>>
>> If you are familiar with the ALGORITHM, then you should know that that
>> the second statement is not true.
>
> Since Szonye retracted his "explanation" in your support, perhaps
> you'd like to tell us what you meant?
I was about to...
>
> P.P.S. Knowing Joe Marshall's history on c.l.l, I think he was just
> talking out of his you know what, but let's give him a chance.
But given this comment, fuck it.
--
~jrm
Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
> ·············@yahoo.com (David Fisher) writes:
>
> > Joe Marshall <·············@comcast.net> wrote in message news:<············@comcast.net>...
> >> ·············@yahoo.com (David Fisher) writes:
> >>
> >> > I know the ALGORITHM Boehm's GC uses. On a 32 bit machine, if your
> >> > process references n Gigs, a random non-pointer bit pattern will be
> >> > interpreted as a pointer with the probability of n * 25%.
> >>
> >> If you are familiar with the ALGORITHM, then you should know that that
> >> the second statement is not true.
> >
> > Since Szonye retracted his "explanation" in your support, perhaps
> > you'd like to tell us what you meant?
>
> I was about to...
Even though you knew your argument wouldn't hold water?
> >
> > P.P.S. Knowing Joe Marshall's history on c.l.l, I think he was just
> > talking out of his you know what, but let's give him a chance.
>
> But given this comment, fuck it.
Joe Marshall, true to the form.
David Fisher <·············@yahoo.com> wrote:
> Since Szonye retracted his "explanation" in your support, perhaps
> you'd like to tell us what you meant?
What the hell are you talking about? I retracted nothing. Kindly refrain
from putting words in my mouth.
> To Blume: I didn't criticize BW per se, only PLT's use of it as a
> default for Scheme programs.
What's wrong with it? I'm no fan of conservative GC, but your criticism
of it so far seems founded entirely on half-truths, bad math, and poor
understanding.
> P.P.S. Knowing Joe Marshall's history on c.l.l, I think he was just
> talking out of his you know what, but let's give him a chance.
Joe's a bit provocative, but at least he doesn't falsely claim that the
other guy retracted his claims.
--
Bradd W. Szonye
http://www.szonye.com/bradd
"Bradd W. Szonye" <··········@szonye.com> wrote in message news:<·························@szonye.com>...
>
> What the hell are you talking about? I retracted nothing.
"""
I don't know exactly how Boehm's algorithm handles this, nor do I know
how PLT's collector (which is a variant on Boehm's, IIRC) implements
it.
I do know that it's a reasonable option for a conservative GC, though.
Anyway, this is somewhat speculative, which is why I called them
"hints"
rather than "corrections." (I will admit to being condescending about
it, perhaps unreasonably so.)
"""
I'd say you phrased it mildly, considering that you had to eat your
own words given the counterexample to your "pointer alignment"
nonsense.
In the future, please kindly refrain from pretending to be an
authority on issues you do not have any clue about.
Bradd wrote:
>> What the hell are you talking about? I retracted nothing.
David Fisher quoted me:
> """
> I don't know exactly how Boehm's algorithm handles this, nor do I know
> how PLT's collector (which is a variant on Boehm's, IIRC) implements
> it. I do know that it's a reasonable option for a conservative GC,
> though. Anyway, this is somewhat speculative, which is why I called
> them "hints" rather than "corrections." (I will admit to being
> condescending about it, perhaps unreasonably so.)
> """
.. and then added:
> I'd say you phrased it mildly, considering that you had to eat your
> own words given the counterexample to your "pointer alignment"
> nonsense.
I did not actually retract my claims, however. Furthermore, another
poster confirmed that the Boehm GC does in fact use the "reasonable
option" I had described, thereby justifying my educated guess.
Frankly, I don't any other way to describe your tactics here except
"blatantly dishonest." I admitted to condescension and a bit of
speculation, but that's not at all the same as your claim that I
*retracted* my guess.
> In the future, please kindly refrain from pretending to be an
> authority on issues you do not have any clue about.
In the future, please kindly refrain from being a raging hypocrite.
--
Bradd W. Szonye
http://www.szonye.com/bradd
David Fisher wrote:
> I'm pretty busy at work these days, but if there are still
> deliberations in about a week, and if there are still those who seem
> intelligent but do not believe PLT is a toy, I'll write a simple
> snippet that should run in constant space (and hopefully will run in
> constant space in CMUCL), but that "explodes" under PLT (&BW).
I look forward to seeing that. But once again, I have to ask what your
point is, and also what your definition of "toy" is. Are C and C++ toys?
It would seem reasonable to include amongst toy languages ones in which
easy-to-commit errors (like pointer errors) result in catastrophic behavior
(like segfaults).
Which languages are not toys? Perhaps Common Lisp, a language with a
heavily relied-on construct which supports arbitrary rearrangement of source
code? From some perspectives, a language with such a feature could be
considered a toy, and a dangerous one at that. Of course, practical
experience argues otherwise, but that's my point.
If you've ever actually used programming languages in the real world, you
should know that the appropriateness of a particular tool for a job is
heavily context-dependent. That applies to a choice to use the Boehm
garbage collector, and it would apply to a choice to use PLT Scheme. As it
happens, PLT Scheme is not intended as a commercial language implementation,
so it would be silly to argue that it is perfectly suited for that task
(although I happen to have used it for that purpose on a few occasions).
But it's equally silly to criticize DrScheme for not being a good emacs
clone, since it's not intended to be one. Similarly, it's unreasonable to
dismiss something as useful as the Boehm collector has been on many
real-world projects, when you have no experience with it whatsoever, and
based solely on an assumed understanding of its algorithm, uninformed by any
experience of its real world performance.
> Seriously, using the probability theory, Markov chains, etc. to
> _estimate_ the probability (non-deterministic!) with which your
> program will "explode" does not strike me as something to prefer to
> manual memory management, let alone precise GC.
In theory, precise GC seems like an easy win, sure. In practice, things
aren't always so clear cut. Manual memory management? That depends.
> I think he was just talking out of his you know what,
> but let's give him a chance.
This seems to be an example of what psychologists call "projection".
Anton
·············@yahoo.com (David Fisher) writes:
...
> To Blume: I didn't criticize BW per se, only PLT's use of it as a
> default for Scheme programs. If I were forced to develop a GC to use
> with arbitrary leaking C programs, I would have hoped to come up with
> something like BW.
I'm not a Blume, but this is usenet.
Bigloo Scheme also uses the Boehm GC as the default for Scheme
programs. My team and I have been working with Bigloo and the Boehm
GC for roughly a year and a half now. Our project is roughly 30k LOC
of Scheme and C. We have never had a single problem related to the
Boehm GC. We've had trouble with GCC, a few little bugs in Bigloo
itself, but the Boehm GC is one thing that has simply done its job
without a hitch.
The Boehm GC is not a kludge, as you seem to imply. It is not merely
useful for "arbitrary leaking C programs". My experience with it says
that the Boehm GC is an excellent alternative to manual memory
management in production quality C code.
> I'm pretty busy at work these days, but if there are still
> deliberations in about a week, and if there are still those who seem
> intelligent but do not believe PLT is a toy, I'll write a simple
> snippet that should run in constant space (and hopefully will run in
> constant space in CMUCL), but that "explodes" under PLT (&BW).
It sounds like you'd like to drive a car into a tree to prove that the
car isn't safe.
Are you aware that CMUCL's default GC on x86 (and I think SPARC too,
in recent versions) is also conservative?
...
> P.P.S. Knowing Joe Marshall's history on c.l.l, I think he was just
> talking out of his you know what, but let's give him a chance.
Crawl back under your rock, fool.
--
-Tim
···@tenkan.org (Tim Daly Jr.) writes:
> Are you aware that CMUCL's default GC on x86 (and I think SPARC too,
> in recent versions) is also conservative?
Iirc, it's only conservative on the stack and in registers on x86.
It's precise on the heap.
On SPARC, the gc is based on gencgc but is precise.
--
Alan Shutko <···@acm.org> - I am the rocks.
Regarding the Boehm GC:
I have had trouble with it, but that was largely due to a
pathological data structure. I was storing lots of hash
codes interleaved with pointers and fillng memory, and it
crapped out because hash values were being mistaken for
pointers and preserving stuff that there wasn't a pointer
to - which in turn contained more pointer-looking hash
values, etc. The data structure was redesigned so that we
used bigger nodes (meaning not as many valid values for
pointers) and allocated pointers and hash values in separate
nodes. Then we just told the collector that the hash-value
nodes never contained pointers, and that was that.
As far as I can tell there is no problem with it if you're
not doing something pathological - I wouldn't hesitate to use
it for code that was being written in-house where the pathological
stuff would be detected as soon as we started writing it.
What I wouldn't use it for is systems made out of code that
was written in many different places by many different people;
I don't know which of them plays pointer-arithmetic games that
the GC will choke on, or which of them 'disguise' pointers with
tagbits, or which of them does what we did and interleaves live
pointers and arbitrary integers together in big dense data
structures creating situations the GC won't cope with.
To me it seems like the Boehm collector is fine, as long as
you remember that you're using it when you're writing the
code. Most of the things it wants (maintaining a pointer to
the head of an object at all times, not tagbitting pointers,
etc) are pretty much good style guidelines in C anyway. But
before applying it to code that wasn't written with it in
mind, you do need to audit that code and see exactly what kind
of games they play with their pointers.
Linux, btw, always allocates on 8-byte aligned addresses, so
the last 3 bits of a valid pointer returned from malloc are
always zero. This fact alone allows conservative collectors
to ignore 7/8 of randomly chosen integers as "not looking like
pointers" even if the entire address space is in use.
Bear
Ray Dillinger <····@sonic.net> writes:
> Regarding the Boehm GC:
>
> I have had trouble with it, but that was largely due to a
> pathological data structure.
PLT Scheme sometimes tickles a pathological case in the Boehm GC.
PLT Scheme can be built with the `3m' precise collector.
The Boehm GC has a number of options to help avoid pathological cases.
--
~jrm
Joe Marshall <·············@comcast.net> wrote:
> PLT Scheme sometimes tickles a pathological case in the Boehm GC.
>
> PLT Scheme can be built with the `3m' precise collector.
>
> The Boehm GC has a number of options to help avoid pathological cases.
Our experience with the Boehm GC in Larceny has generally been
pretty good, but we have observed a few benchmarks in which it
leaks enough storage to be noticeable in comparison to Larceny's
four precise collectors. I doubt whether we'd have noticed the
problems had we not been doing controlled experiments to compare
various configurations of the five collectors.
If the troll can "write a simple snippet that should run in
constant space...but that 'explodes' under PLT (&BW)", then he
will be making a positive contribution to the gc community. We
should all encourage him in this endeavor, and remind him of it
if he forgets to do it.
Will
··········@verizon.net (William D Clinger) wrote in message news:<····························@posting.google.com>...
> Joe Marshall <·············@comcast.net> wrote:
> > PLT Scheme sometimes tickles a pathological case in the Boehm GC.
> >
> > PLT Scheme can be built with the `3m' precise collector.
> >
> > The Boehm GC has a number of options to help avoid pathological cases.
>
> Our experience with the Boehm GC in Larceny has generally been
> pretty good, but we have observed a few benchmarks in which it
> leaks enough storage to be noticeable in comparison to Larceny's
> four precise collectors. I doubt whether we'd have noticed the
> problems had we not been doing controlled experiments to compare
> various configurations of the five collectors.
>
> If the troll
Excuse me?
> can "write a simple snippet that should run in
> constant space...but that 'explodes' under PLT (&BW)", then he
> will be making a positive contribution to the gc community.
Here, you pretend to speak for the "gc community", and at the same
time you are implying that there is no "simple snippet that should run
in constant space...but that 'explodes' under PLT (&BW)", thus
contradicting yourself
and betraying your complete ignorance of the subject.
The "GC community" is very familiar with such examples.
In fact, when you know how conservative GC works, such examples
immediately spring to mind:
1. Implement a list-based queue. keep it at around 1000-element length
(for example), run random floats "through" it. Observe your PLT
eventually sending your computer to the swapping hell (unless heap
limits are set, in which case it will just fail to allocate)
2. If you don't like "random", replace it with some "meaningful"
numerics.
3. If you don't like "queue", replace it with lists, stacks or
doubly-linked lists that are temporarily grown inside some loop, and
then completely discarded (only to stay in memory _forever_, with some
probability)
> We
> should all encourage him in this endeavor, and remind him of it
> if he forgets to do it.
I laugh at pompous fools like you!
·············@yahoo.com (David Fisher) wrote:
> In fact, when you know how conservative GC works, such examples
> immediately spring to mind:
>
> 1. Implement a list-based queue. keep it at around 1000-element length
> (for example), run random floats "through" it. Observe your PLT
> eventually sending your computer to the swapping hell (unless heap
> limits are set, in which case it will just fail to allocate)
You should read about GC_malloc_atomic(nbytes) in the README file
for the BDW collector. You might also read the paragraph labelled
"Atomic and nonatomic objects" in Larceny Note #11, online at
http://www.ccs.neu.edu/home/will/Larceny/notes/note11-bdw.html
You should also learn something about the algorithm used in the
BDW collector, which is considerably more sophisticated than the
naive algorithm you have been describing in this newsgroup.
The gc community really does want to see small programs that the
BDW collector handles badly, because small programs are much easier
to analyze than large programs. DrScheme, alas, is a large program
before you add a single line of your own code. Even so, I would
have been interested in your example had it been real.
Will
David Fisher wrote:
> 1. Implement a list-based queue. keep it at around 1000-element length
> (for example), run random floats "through" it. Observe your PLT
> eventually sending your computer to the swapping hell (unless heap
> limits are set, in which case it will just fail to allocate)
Mr Fisher, I translated the above into the following concrete code:
(define queue
(build-list 1000 (lambda (i) (exact->inexact (random (+ i 1))))))
(define (enq x)
(append! queue (list x)))
(define (deq)
(unless (null? queue) (begin0 (car queue) (set! queue (cdr queue)))))
;; run program run
(let L ([i 100000000])
(unless (= i 0)
(enq (exact->inexact i))
(deq)
(L (- i 1))))
Then I ran this program in all three versions of PLT Scheme v206.1 using the
Conservative version [Built from cvs two days ago]:
1. drscheme/pretty-big-plt language, i.e., mred with the whole programming
environment in there. I see a memory increase after a while in both RSIZE and
VSIZE. After 11 minutes the RSIZE stabilizes. Will thinks that even the VSIZE
should stabilize after a while. This is on a 1Gig machine, TiBook, OS X 10.3.3.
2. mred (require (lib "etc.ss")), i.e., the raw kernel of the environment with
all the "os"y things and the graphics engine. I see *no* memory increase there
at all.
3. mzscheme (require (lib "etc.ss")), i.e., the raw Scheme interpreter with
nothing but one library loaded. Again, I see *no* memory increase there at all
when I am running this program for 15 minutes or more.
Is this was you observe?
-- Matthias
Matthias Felleisen wrote:
> David Fisher wrote:
>
>> 1. Implement a list-based queue. keep it at around 1000-element length
>> (for example), run random floats "through" it. Observe your PLT
>> eventually sending your computer to the swapping hell (unless heap
>> limits are set, in which case it will just fail to allocate)
>
>
>
>
Mr Fisher,
apologies for responding to myself but I have rewritten the benchmark in R5RS
and modified it based on a suggestion from Matthew. We now see *no* memory
growth even in the DrScheme part of PLT Scheme. The mzscheme and mred versions
still don't show memory growth.
If I have misunderstood your suggestion, please correct me. Thanks
-- Matthias
(define queue
(let L ([i 1000]) (if (= i 0) '() (cons (exact->inexact i) (L (- i 1))))))
(define (enq x)
(let L ([q queue])
(if (null? (cdr q)) (set-cdr! q (list x)) (L (cdr q)))))
(define (deq)
(if (null? queue)
(void)
(let ([old queue])
(set! queue (cdr queue))
(set-cdr! old #f)
(car old))))
;; run program rn
(let L ([i 100000000])
(if (= i 0)
(void)
(begin
(enq (exact->inexact i))
(deq)
(L (- i 1)))))
William Clinger wrote:
>> Our experience with the Boehm GC in Larceny has generally been
>> pretty good, but we have observed a few benchmarks in which it
>> leaks enough storage to be noticeable in comparison to Larceny's
>> four precise collectors. I doubt whether we'd have noticed the
>> problems had we not been doing controlled experiments to compare
>> various configurations of the five collectors.
>>
>> If the troll can "write a simple snippet that should run in constant
>> space...but that 'explodes' under PLT (&BW)", then he will be making
>> a positive contribution to the gc community.
David Fisher wrote:
> Here, you pretend to speak for the "gc community" ....
Pretend to? Based on his implementation experience, he's well-qualified
to speak for that community.
> and at the same time you are implying that there is no "simple snippet
> that should run in constant space...but that 'explodes' under PLT
> (&BW)" ....
How did you get that from what he wrote? Especially since the first
paragraph makes it clear that he *has* seen experiments that blow up. I
think you've mistakenly interpreted Clinger's quotation marks as scare
quotes.
> thus contradicting yourself and betraying your complete ignorance of
> the subject.
>
> The "GC community" is very familiar with such examples.
Duh. He even mentioned an example of such in the first paragraph!
> ... I laugh at pompous fools like you!
You apparently don't even read the article you're replying to before you
launch into your kookrants, and yet you're calling other people pompous
fools? Heal thyself, physician.
--
Bradd W. Szonye
http://www.szonye.com/bradd
·············@yahoo.com (David Fisher) wrote in message news:<····························@posting.google.com>...
>
> In fact, when you know how conservative GC works, such examples
> immediately spring to mind:
>
> 1. Implement a list-based queue. keep it at around 1000-element length
> (for example), run random floats "through" it. Observe your PLT
> eventually sending your computer to the swapping hell (unless heap
> limits are set, in which case it will just fail to allocate)
>
> 2. If you don't like "random", replace it with some "meaningful"
> numerics.
>
> 3. If you don't like "queue", replace it with lists, stacks or
> doubly-linked lists that are temporarily grown inside some loop, and
> then completely discarded (only to stay in memory _forever_, with some
> probability)
>
This is all discussed quite thoroughly in my paper:
``Bounding Space Usage of Conservative Garbage Collectors'',
Proceedings of the 2002 ACM SIGPLAN-SIGACT Symposium on Principles of
Programming Languages, Jan. 2002, pp. 93-100.
There are two distinct reasons for conservative collection to leak
unbounded amounts of space:
1) The number of pointer misidentifications itself is unbounded. This
generally can't happen unless the heap itself is traced
conservatively. Some clients of our collector do that, some don't.
It's useful to be able to do this, but for Scheme or Java objects,
it's typically also fairly easily avoidable. (E.g. gcj avoids it.)
2) You create data structures which contain unbounded pointer chains.
Linked queues and lazily evaluated lists seem to be the canonical, and
basically only, examples of this. You do need to manually avoid these
in conservatively collected applications. (They also don't get along
well with some other GC techniques, e.g. anything that involves a very
rarely or never collected generation.) This is a property that's
quite amenable to analysis. And the paper contains an algorithm for
testing it with modest overhead.
I think the above examples actually won't work well. Version 1 will
work (i.e. blow up) if you instead fill a large live array with random
numbers which are replaced periodically. (If they're constant, the
black-listing algorithm in the collector is likely to handle the
problem.) Version 3 won't work, unless you have a very large heap in
relation to your address space, and the heap is traced conservatively.
Queues are far worse than anything else. (See the paper for proofs.)
Hans
Ray Dillinger <····@sonic.net> wrote in message news:<·················@sonic.net>...
> Regarding the Boehm GC:
...
> Linux, btw, always allocates on 8-byte aligned addresses, so
> the last 3 bits of a valid pointer returned from malloc are
> always zero. This fact alone allows conservative collectors
> to ignore 7/8 of randomly chosen integers as "not looking like
> pointers" even if the entire address space is in use.
>
> Bear
It doesn't matter. As Blume correctly pointed out much earlier in this
thread, even if your pointer p is m-byte aligned, p+1 may not be,
while being a valid pointer.
Tim Daly Jr.) wrote:
> Are you aware that CMUCL's default GC on x86 (and I think SPARC too,
> in recent versions) is also conservative?
>
... and then continued ...
>
> Crawl back under your rock, fool.
Thus creating a self-referential article :-)
>>>>> "Tim" == Tim Daly <···@tenkan.org> writes:
Tim> Are you aware that CMUCL's default GC on x86 (and I think SPARC too,
Tim> in recent versions) is also conservative?
The sparc version is not conservative, despite the feature being
called :gencgc. There was already a :gengc feature used in the
sources so I didn't want to use that. (I think it was for a different
generational gc that was never finished.)
Ray
Anton van Straaten wrote:
>
> This and earlier comments imply a negative opinion of Boehm's collector.
> Why is that? It solves certain problems very neatly, in particular,
> integration with C and C++ code, which is often an issue for a language like
> Scheme. It also performs very well in practice. Is your opinion based on
> actual experience with the collector?
>
I see mainly these problems with conservative GC:
1) It can not *guarantee* that the only consumed storage contains live data.
In most cases it will work, but you simply can't be sure and have to rely
on rule-of-thumb heuristics and experience. All empiric studies are moot, since
one can not reproduce all possible usage patterns.
2) It's likely (per definitionem) to retain more garbage than a precise collector
3) Since data may not move, locality may suffer and fragmentation can be a problem
(this also applies to precise, non-moving collectors)
4) It is a "hack" (a rather clever and in the case of the BDW collector, very well
engineered one) in the way that it's easy to slap onto an existing language
implementation. This is nice in the beginning: you don't have to worry about
fussing with GC roots or moving data in external C code. But later when
you want to change the GC implementation, a lot of work is needed.
cheers,
felix
>>>>> "David" == David Fisher <·············@yahoo.com> writes:
David> Correct me if I'm wrong, but PLT Scheme uses Boehm's GC (hack),
David> compiles to byte code, and in the GUI editor, you can't send one
David> S-expr to the listener with a single key stroke/combination.
David> I don't know if PLT is primarily meant to be a teaching aid, but if
David> this is true, maybe it should come with a flashy warning label that
David> says so?
David> BTW, is PLT GUI /configurable/ in scheme?
All of what you say, especially with the thrust you apply, is
almost completely wrong:
- PLT can use a GC other than Boehm's.
- The "GUI editor" works differently from ordinary REPLs
When you use it from (X)Emacs, for instance, "sending an S-expr to
the listeneer with a single key stroke/combination" is no problem.
- PLT *is* primarily a teaching aid; I don't know why there should be
a warning label saying "Warning! This software is usable as a
teaching aid." If you mean that this means that PLT Scheme is toy,
you're wrong. (I personally have done two sizable commercial
(GUI-bound) applications using PLT Scheme.)
- Of course the PLT GUI is configurable in Scheme; it's written in
Scheme.
--
Cheers =8-} Mike
Friede, V�lkerverst�ndigung und �berhaupt blabla
Michael Sperber wrote:
(I personally have done two sizable commercial
> (GUI-bound) applications using PLT Scheme.)
Could you share any details about your experiences? I have been thinking
about using PLT for commercial apps for a while now and so would be very
interested in knowing about any difficulties you may have found.
Thanks in advance,
-pp
>>>>> "Pedro" == Pedro Pinto <······@cs.cmu.edu> writes:
Pedro> Could you share any details about your experiences? I have been
Pedro> thinking about using PLT for commercial apps for a while now
Pedro> and so would be very interested in knowing about any
Pedro> difficulties you may have found.
The paper "Developing a Stage Lighting System from Scratch" at
http://www-pu.informatik.uni-tuebingen.de/users/sperber/papers/
has some information.
I guess the main difficulty I keep encountering is that I'd like PLT's
threads to be more lightweight.
--
Cheers =8-} Mike
Friede, V�lkerverst�ndigung und �berhaupt blabla
"TLOlczyk" <··········@yahoo.com> wrote:
> On Sat, 03 Apr 2004 10:11:53 -0500, Brian Mastenbrook
> <····················@cs.indiana.edu> wrote:
...
> >There's also PLT, which has a flashy GUI interface, but is otherwise
> >mostly unimpressive. I'd rather work in Emacs anyway.
>
> That's the annoying thing about Scheme. PLT would be good to sort
> of play around doing early prototypes, then go to a more serious
> scheme later, but the libraries are incompatible.
I thought something like that too, using PLT to prototype a stock market
analysis application a few years ago. PLT turned out to be plenty fast and
powerful enough to do the job, and I've used it for plenty of serious things
since then.
Re a "more serious scheme", don't let PLT's educationally-oriented GUI
confuse you - when you're talking about the language features and
capabilities of Schemes, there are none more serious than PLT.
Anton
In article <·······································@cs.indiana.edu>,
Brian Mastenbrook <····················@cs.indiana.edu> wrote:
Just a quick thanks to you and all the others in this thread.
I now am armed with lots of good advice about CL and Scheme
implementations, free and otherwise.
Quite a variety of good choices, I must say :)
Thanks again, everyone,
Mark-