Was there a schism between R4RS and R5RS?
Grant Rettke
and against R6RS, and in the process of doing so, I've ended up
reading a lot about people's take on R4RS.
From what I can gather, R4RS is really quite good. In fact, I get the
impression that it is well loved as I see different Scheme code-bases
being written for R4RS.
R4RS only suggested macros, though, and didn't include them in the
standard. Why then, did they get added to the standard in R5RS?
Macros are powerful, but did Scheme need them? Who were the
proponents, and opponents, and why?
How might Scheme look had it not gone down the macro path? Would
records have been added?
Since the contributors to R4RS and R5RS are virtually identical,
probably there wasn't a schism, but, macros seem like a "big" addition.
samth
1. The full archives of the RRRS authors list is available here:
http://groups.csail.mit.edu/mac/projects/scheme/rrrs-archive.html
I recommend reading it to get a sense for the answers to many of the
questions you're asking.
2. R4RS has gained in popularity in some circles since the release of
the R6RS, since those people have in retrospect decided that R4RS was
the last revision of the Report that conformed to their ideas about
what Scheme is. This may not be the most accurate reading of the
history.
sam th
Jens Axel Soegaard
> Lately I've been trying to read more about people's arguments both for
> and against R6RS, and in the process of doing so, I've ended up
> reading a lot about people's take on R4RS.
>
> From what I can gather, R4RS is really quite good. In fact, I get the
> impression that it is well loved as I see different Scheme code-bases
> being written for R4RS.
>
> R4RS only suggested macros, though, and didn't include them in the
> standard. Why then, did they get added to the standard in R5RS?
The philophy of Scheme has always been to include general constructs
with a clear semantics. At the time R4RS was written there were quite
a few persons doing research in macros. Instead of choosing one
low-level macro mechanism and fearing the choice had to be remade
later, one simply omitted choosing a low-level macro mechanism.
If you are interested in the history, the RRRS archive is gold.
Also (why do I suddenly think of Palin?) compare the dates of
the papers on macros on readscheme.org to the date of R4RS.
--
Jens Axel Søgaard
Pascal J. Bourguignon
Macros were invented in 1963, and are an important consequence of
McCarthy's code=data equation.
Any language that hasn't lisp-equivalent macros is a shame, and not
worth is weight in bits.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
Jeff M.
wrote:
>
> Macros were invented in 1963, and are an important consequence of
> McCarthy's code=data equation.
>
> Any language that hasn't lisp-equivalent macros is a shame, and not
> worth is weight in bits.
One could say the same thing about many low-level operations that Lisp
cannot (in Common Lisp or Scheme) easily do. For example, could
someone (using Common Lisp only, and not an implementation-specific
method) show me how to do the following:
// handed 4 bytes in little-endian format, produce a big-endian float
float byte_swapped_float(unsigned char * pBuf)
{
float x;
// TODO: __declspec #pragma whatever to ensure float alignment
unsigned char * swapped = (unsigned char*)&x;
swapped[3] = pBuf[0];
swapped[2] = pBuf[1];
swapped[1] = pBuf[2];
swapped[0] = pBuf[3];
return x;
}
// Use IEEE to your advantage for a blazing fast 1/sqrt(x) function:
float inverse_sqrt(float x)
{
float xhalf = 0.5f * x;
int i = *(int*)&x;
i = 0x5f3759df - (i >> 1);
x = *(float*)&i;
x = x * (1.5f - xhalf * x * x);
return x;
}
Treating bytes as bytes and manipulating them is pretty fundamental
(and one might argue more fundamental than macros). While I know that
Lisp can do the above, it's not nearly as efficient to code or run.
I love Lisp (and Scheme for that matter), but the argument that a
language w/o macros isn't "worth its weight in bits" is pretty over-
the-top considering some of the basic functionality Lisp "lacks" on
the low-end.
Jeff M.
Pascal J. Bourguignon
> On Oct 6, 1:37 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>>
>> Macros were invented in 1963, and are an important consequence of
>> McCarthy's code=data equation.
>>
>> Any language that hasn't lisp-equivalent macros is a shame, and not
>> worth is weight in bits.
>
> One could say the same thing about many low-level operations that Lisp
> cannot (in Common Lisp or Scheme) easily do. For example, could
> someone (using Common Lisp only, and not an implementation-specific
> method) show me how to do the following:
>
> // handed 4 bytes in little-endian format, produce a big-endian float
> float byte_swapped_float(unsigned char * pBuf)
> {
> float x;
>
> // TODO: __declspec #pragma whatever to ensure float alignment
> unsigned char * swapped = (unsigned char*)&x;
>
> swapped[3] = pBuf[0];
> swapped[2] = pBuf[1];
> swapped[1] = pBuf[2];
> swapped[0] = pBuf[3];
>
> return x;
> }
This doesn't work. float are not necessarily IEEE754. In Common Lisp
we have the primitives to build floating point numbers whatever the
host representation. Have a look at
http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/c6cba9c562c61f71/949c20a07b315f7a?lnk=st&q=#949c20a07b315f7a
> // Use IEEE to your advantage for a blazing fast 1/sqrt(x) function:
> float inverse_sqrt(float x)
> {
> float xhalf = 0.5f * x;
> int i = *(int*)&x;
>
> i = 0x5f3759df - (i >> 1);
> x = *(float*)&i;
> x = x * (1.5f - xhalf * x * x);
>
> return x;
> }
Common Lisp has a 1/x primitive. Why would you assume it's not
optimized?
> Treating bytes as bytes and manipulating them is pretty fundamental
> (and one might argue more fundamental than macros). While I know that
> Lisp can do the above, it's not nearly as efficient to code or run.
Processing bytes is not fundamental at all. Turing machines don't
have bytes. Lambda calculus has no byte. Bankers, game players, your
grandma don't deal with bytes and don't know what a byte is.
Therefore bytes have nothing to do in CS, and should be plain
eliminated.
> I love Lisp (and Scheme for that matter), but the argument that a
> language w/o macros isn't "worth its weight in bits" is pretty over-
> the-top considering some of the basic functionality Lisp "lacks" on
> the low-end.
That said, and while the Common Lisp definition doesn't allow to
process the bit representation of most of lisp data, this doesn't
prevent lisp systems to provide the needed primitives and whole Lisp
Operating Systems for Lisp Machines, including device drivers, to be
written 100 % in Lisp.
But I repeat, it's ludicruous, useless and dangerous to try to break
the encapsulation of data.
--
__Pascal Bourguignon__ http://www.informatimago.com/
This universe shipped by weight, not volume. Some expansion may have
occurred during shipment.
Jeff M.
wrote:
>
> But I repeat, it's ludicruous, useless and dangerous to try to break
> the encapsulation of data.
And this is where we differ, friend.
I don't know the kind of work you do with computers, but I'll assume
it's good, grand, and very different from what I do. ;-)
But, I promise, the work I do requires that kind of code daily in
order to squeeze every last bit of memory and speed out of the
machine... let alone the wonderful 8-bit microprocessors I was working
on before that (using Forth). And I couldn't imagine trying to do the
same work without those fundamentals available to me.
Jeff M.
Pascal J. Bourguignon
Well, squeezing bits might be funny (I like to to do it occasionnaly
too), but it's not CS.
Remember that Turing Machines have *infinite* memory! ;-)
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Debugging? Klingons do not debug! Our software does not coddle the
weak."
Ray Blaak
> Well, squeezing bits might be funny (I like to to do it occasionnaly
> too), but it's not CS.
>
> Remember that Turing Machines have *infinite* memory! ;-)
You don't work with Turing machine either, for that very reason.
--
Cheers, The Rhythm is around me,
The Rhythm has control.
Ray Blaak The Rhythm is inside me,
rAYb...@STRIPCAPStelus.net The Rhythm has my soul.
Benjamin L. Russell
Bourguignon) wrote:
>"Jeff M." <mas...@gmail.com> writes:
>
>> On Oct 6, 3:53?pm, p...@informatimago.com (Pascal J. Bourguignon)
>> wrote:
>>>
>>> But I repeat, it's ludicruous, useless and dangerous to try to break
>>> the encapsulation of data.
>>
>> And this is where we differ, friend.
>>
>> I don't know the kind of work you do with computers, but I'll assume
>> it's good, grand, and very different from what I do. ;-)
>>
>> But, I promise, the work I do requires that kind of code daily in
>> order to squeeze every last bit of memory and speed out of the
>> machine... let alone the wonderful 8-bit microprocessors I was working
>> on before that (using Forth). And I couldn't imagine trying to do the
>> same work without those fundamentals available to me.
>
>Well, squeezing bits might be funny (I like to to do it occasionnaly
>too), but it's not CS.
>
>Remember that Turing Machines have *infinite* memory! ;-)
In looking through the RRRS-Authors Mailing-List Archive (see
http://groups.csail.mit.edu/mac/projects/scheme/rrrs-archive.html), I
came across the following apparently relevant quotation (from
ftp://ftp.swiss.ai.mit.edu/pub/scheme-mail/rrrs.mail20.gz).
(Pardon the expletive at the very end of this quotation--if you cannot
stand expletives, please stop reading this message here!):
>From c...@martigny.ai.mit.edu Wed Mar 19 14:12:52 1997
>[...]
>Date: Wed, 19 Mar 1997 14:12:47 -0500
>From: Chris Hanson <c...@martigny.ai.mit.edu>
>[...]
>Subject: a (revised) draft of R5RS
>
>This is the reason that Scheme standardization is dead.
>
>On the one hand, there are a group of people who are trying to make
>Scheme a useful programming language. These people make expedient
>choices that use the best currently available technology to produce a
>language with the expressive power to write complex programs. These
>people are programmers who are trying to use Scheme as a tool.
>
>On the other hand, there are a group of people who are trying to make
>Scheme the cleanest and best programming language. These people want
>to wait until the technology has reached the point that it is elegant,
>well understood and well integrated with the rest of the language
>before it is standardized on. These people are language designers who
>are trying to make Scheme the best possible language, a work of art.
>
>There really isn't any middle ground between these two points of view,
>at least as far as standardization goes. Each person is going to make
>a different trade-off based on their immediate need for expressive
>power versus their desire for a beautiful language.
>
>The underlying problem is that these are two very different goals, and
>that the Scheme community hasn't chosen one or the other as its basis
>for standardization. The original reason for standardization, which
>resulted in RRRS, was to produce a document that defined the common
>elements of the then-existing implementations, and possibly to
>compromise on some of their differences in an effort to create a
>portable language. Today, there's no such reason. Portability is
>important, but we already have portability for the agreed-upon subset.
>Now the problem is to extend that subset, and there's no agreement
>about what purpose the extension would serve.
>
>I think a good deal of this is the fault of those of us who
>participated in the early standardization efforts. We thought that we
>could live in both camps, having an elegant language that was also
>expressive. We established the tradition of unanimous agreement, and
>we tried to standardize only on those things that were well
>understood. This was fine as long as the goal of standardization was
>to create a language that was suitable for teaching, in which toy
>programs were portable. Today that's no longer an interesting
>motivator, and consequently the traditions of the past are no longer a
>good mechanism for moving forward.
>
>The only way I can see to resolve this is to have two languages.
>
>The first is a kind of cleaned-up Common Lisp, in which it is
>understood that the goal is to make the language as powerful as
>possible using the best, cleanest language technology of the day, and
>incorporating other elements when necessary to solve real programming
>problems. This would be a "snapshot" of the current Scheme
>technology, augmented by some reasonable but less-than-excellent
>mechanism to cover up Scheme's pimples. Standardizing on this
>language would be a matter of getting the participants to agree on a
>clean base language (e.g. R4RS or R5RS) and an acceptable but
>imperfect set of patches to cover the pimples.
>
>The second is a work-in-progress, which lacks certain kinds of
>expression when it is not yet understood how to cleanly integrate that
>expression into the language. It would be understood that some kinds
>of programs would be hard to write in this language, but people would
>work to improve the technology until that expression was achieved.
>Probably this second language would periodically spin off "snapshots"
>that would be used for serious programming. Standardizing on this
>language would be a matter of getting the participants to agree what
>parts of the language are well understood and elegant.
>
>Then the only real issue is: which language gets the name "Scheme"?
>Frankly, I don't give a damn.
This message was written in 1997, yet most of the arguments seem very
relevant to the R5RS vs. R6RS debate. We seem to have come Back to
the Future. De'ja` vu.
-- Benjamin L. Russell
tom.g...@me.com
the "cleaned-up Common Lisp" alternative has won. There doesn't seem
to be any current interest in creating a programming language
*standard* for the "cleanest and best programming language". And I've
never understood the point of using industry standards for academic
purposes.
-Tom Gordon
Nils M Holm
And the people have lost. History repeats itself repeats itself.
--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/
Brian Harvey
>And I've
>never understood the point of using industry standards for academic
>purposes.
Alas, eventually the non-industry-standard (i.e., R5RS) implementation we
use will fall prey to software rot, and then we teachers will have to get
into the language implementation business in order to have any implementation
at all!
samth
> tom.gor...@me.com wrote:
> > An interesting bit of Scheme history. But now the debate is over and
> > the "cleaned-up Common Lisp" alternative has won. [...]
>
> And the people have lost. History repeats itself repeats itself.
Oh come on. Who are these 'people' and what have they lost?
Have they lost implementations? No, there are in fact several
excellent new implementations developed recently.
Have they lost R5RS? No, it's still there.
Have they lost the pedagogic usefulness of Scheme? No, that had
nothing to do with standards?
Have they lost their programs? Of course not.
sam th
Abdulaziz Ghuloum
> Alas, eventually the non-industry-standard (i.e., R5RS)
> implementation we use will fall prey to software rot,
Of course it won't. Or at least, not for that reason.
You probably have not tried any implementation that advertises
itself as R6RS-(compliant, conforming, whatever) but as far as
I can tell from *ALL* implementations supporting R6RS to date
is that business is as usual: they all start in a repl, you can
enter your factorial definition from the repl, you can type
(fact 5) and get the usual 120. Pretty much everything in R5RS
exists in R6RS implementations (except for transcript-on and
transcript-off which no one cares about anyways).
So, if one implementation rots (for whatever reason), time to
move on. There is never a shortage of Scheme implementations.
> and then we teachers will have to get into the language
> implementation business in order to have any implementation
> at all!
Really? Last I checked, teachers were already in the business
of writing Scheme implementations and were pretty good at it
too. Plus, does anybody really uses R5RS only for teaching?
You certainly don't (judging from your lecture videos), and
neither do the PLTers (who created all of these pedagogical
niceties into their system), and neither do we at IU (except
for Dan that is). You always need extensions to R5RS to make
it suitable for anything, teaching included. And you always
ignore some parts of it that you don't care about. So, what
changed here? The concerns that you express seem to fall
into the "fear of the unknown" category than anything serious.
Aziz,,,
jurgen....@gmail.com
Got a question here. I have easily found much material on evaluating
Lisp and writing evaluators (SICP, HTDP, the lambda papers, Graham),
but I haven't found anything that is immediately available about
implementing Lisp macros. Now seeing that they already exist since
1963, this surprises me a bit. Do you have any clues ? (Btw. I ordered
"Principes d'implantation de Scheme et Lisp", so studying how they are
implemented should soon be possible).
Kjetil S. Matheussen
It's not that complicated, to put it mildly. Here is a super-simple
low-level macro system I made for SISC. (I made my own system,
since the R6RS macroexpander in SISC is extremely slow):
(define-macro (c-define-macro def . body)
(if (pair? def)
`(hashtable/put! all-macros ',(car def) (lambda ,(cdr def)
,@body))
`(hashtable/put! all-macros ',def ,@body)))
(define (c-macroexpand-1 expr)
(if (or (not (pair? expr))
(null? expr)
(not (symbol? (car expr))))
expr
(let ((qua (hashq-ref all-macros (car expr))))
(if (not qua)
expr
(apply qua (cdr expr))))))
Kjetil S. Matheussen
Not that it matters very much, but c-define-macro is
better implemented like this:
(define-macro (c-define-macro def . body)
(if (pair? def)
`(c-define-macro ,(car def) (lambda ,(cdr def)
,@body))
`(hashtable/put! all-macros ',def ,@body)))
Since it's shorter and supports macros like (c-define-macro ((a)) a).
Pascal Costanza
Implementing simple low-level macro systems is relatively
straightforward. Peter Norvig's "Paradigms of Artificial Intelligence
Programming" shows a (kind of metacircular) implementation of Scheme
with support for Lisp-style macros, and Paul Graham's "On Lisp" also
shows a model of low-level macros that's very straightforward to understand.
For hygienic and other macro systems, see the paper collection at
http://library.readscheme.org/page3.html
Pascal
--
Lisp50: http://www.lisp50.org
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Marek Kubica
> On Oct 7, 5:52 am, Nils M Holm <news2...@t3x.org> wrote:
>> tom.gor...@me.com wrote:
>> > An interesting bit of Scheme history. But now the debate is over and
>> > the "cleaned-up Common Lisp" alternative has won. [...]
>>
>> And the people have lost. History repeats itself repeats itself.
>
> Oh come on. Who are these 'people' and what have they lost?
It surely isn't me, because I'm quite happy with what current R6RS
implementations provide. I prefer to use a language than to look at it in
awe and at the same time scratch my head what use it may have.
I haven't yet read all of R6RS (I just printed it, and sure, it is
considerably bigger than R5RS), but I'm quite happy with the current
state of Scheme implementations.
regards,
Marek
leppie
> I haven't yet read all of R6RS (I just printed it, and sure, it is
> considerably bigger than R5RS), but I'm quite happy with the current
> state of Scheme implementations.
The (rnrs base) library is actually smaller than R5RS :)
But then you get the odd 500 extra symbols/definitions/whatever from
the libraries.
Cheers
leppie
Jens Axel Soegaard
> (Btw. I ordered
> "Principes d'implantation de Scheme et Lisp", so studying how they are
> implemented should soon be possible).
An excellent book (I've got the english translation of the first
edition). It will answer all your questions - and then some.
--
Jens Axel Søgaard
Ray Dillinger
Is that the book known in English as Lisp In Small Pieces?
If so, I definitely concur. Excellent book.
Bear
Jens Axel Soegaard
> Jens Axel Soegaard wrote:
>
>> jurgen....@gmail.com wrote:
>>> (Btw. I ordered
>>> "Principes d'implantation de Scheme et Lisp", so studying how they are
>>> implemented should soon be possible).
>> An excellent book (I've got the english translation of the first
>> edition). It will answer all your questions - and then some.
>
> Is that the book known in English as Lisp In Small Pieces?
Yes. From the book's homepage:
The exact title of this book stands for "Lisp in Small Pieces". This
book covers Lisp, Scheme and other related dialects, their
interpretation, semantics and compilation. To sum it up in a few
figures: 500 pages, 11 chapters, 11 interpreters and 2 compilers.
This book was first written in French. It was published by
InterÉditions, under title "Les Langages Lisp". See exact bibliographic
reference or cover page . Unfortunately this edition is now out of press.
A new (slightly revised) edition will be issued by February 2007. It
will bear a new title "Principes d'implantation de Scheme et Lisp". See
Paracamplus for more details.
The book also exists in English, published by Cambridge University
Press, under title "Lisp in Small Pieces" (£40.00/$49.95).
> If so, I definitely concur. Excellent book.
--
Jens Axel Søgaard
Peter Keller
That is a phenomenal book and it might take 5 or 6 readings to get the
full impact of it. I wish there was somthing intellectually in between
The Structure and Interpretation of Computer Programs and List in Small
Pieces though...
-pete
Vend
> On Oct 6, 1:37 pm, p...@informatimago.com (Pascal J. Bourguignon)
> wrote:
>
>
>
> > Macros were invented in 1963, and are an important consequence of
> > McCarthy's code=data equation.
>
> > Any language that hasn't lisp-equivalent macros is a shame, and not
> > worth is weight in bits.
>
> One could say the same thing about many low-level operations that Lisp
> cannot (in Common Lisp or Scheme) easily do. For example, could
> someone (using Common Lisp only, and not an implementation-specific
> method) show me how to do the following:
This is a bit unfair since the following is implementation-specific C.
Vend
> Grant Rettke <gret...@gmail.com> writes:
> > Lately I've been trying to read more about people's arguments both for
> > and against R6RS, and in the process of doing so, I've ended up
> > reading a lot about people's take on R4RS.
>
> > From what I can gather, R4RS is really quite good. In fact, I get the
> > impression that it is well loved as I see different Scheme code-bases
> > being written for R4RS.
>
> > R4RS only suggested macros, though, and didn't include them in the
> > standard. Why then, did they get added to the standard in R5RS?
>
> > Macros are powerful, but did Scheme need them? Who were the
> > proponents, and opponents, and why?
>
> > How might Scheme look had it not gone down the macro path? Would
> > records have been added?
>
> > Since the contributors to R4RS and R5RS are virtually identical,
> > probably there wasn't a schism, but, macros seem like a "big" addition.
>
> Macros were invented in 1963, and are an important consequence of
> McCarthy's code=data equation.
>
> Any language that hasn't lisp-equivalent macros is a shame, and not
> worth is weight in bits.
Does this apply to languages with non-strict semantics too?
Pascal Costanza
Grant Rettke
<findrealaddresswithgoo...@soegaard.net> wrote:
> If you are interested in the history, the RRRS archive is gold.
> Also (why do I suddenly think of Palin?) compare the dates of
> the papers on macros on readscheme.org to the date of R4RS.
1991: R4RS macros are suggested, but not required
1991: Christian Queinnec and Julian Padget. "Modules, macros and Lisp"
1991: Christian Queinnec and Julian Padget. "A proposal for a modular
Lisp with macros and dynamic evaluation".
1991: Chris Hanson. "A Syntactic Closures Macro Facility"
1991: William D. Clinger. "Macros in Scheme"
1991: William D. Clinger. "Hygienic macros through explicit renaming"
1991: William D. Clinger and Jonathan A. Rees. "Macros that work"
1992: Ana Bove and Laura Arbilla. "A confluent calculus of Macro
expansion and evaluation"
1992: R. Kent Dybvig. "Writing Hygenic Macros in Scheme with Syntax-
Case"
1992: Robert Hieb, R. Kent Dybvig and Carl Bruggeman. "Syntactic
Abstraction in Scheme"
1993: Jonathan A. Rees. "Implementing lexically scoped macros"
1993: R. Kent Dybvig, Robert Hieb and Carl Bruggeman. "Syntactic
abstraction in Scheme"
1995: Matthias Blume. "Refining Hygienic Macros for Modules and
Separate Compilation"
1996: Stephen Paul Carl. "Syntactic Exposures - A Lexically-Scoped
Macro Facility for Extensible Compilers"
1998: R5RS macros are required
Grant Rettke
> This message was written in 1997, yet most of the arguments seem very
> relevant to the R5RS vs. R6RS debate. We seem to have come Back to
> the Future. De'ja` vu.
Interesting.
Grant Rettke
The same bunch of editors was around from RRRS (R2RS) up to and
including R5RS. That is 13 years. None of those guys are on the board
for R6RS (The exception here is Kent Dybvig which was been on since
R3RS.).
Why? Did their interests change? Did they retire? I read that the
Abelson switched over to Python for example.
Grant Rettke
> Alas, eventually the non-industry-standard (i.e., R5RS) implementation we
> use will fall prey to software rot, and then we teachers will have to get
> into the language implementation business in order to have any implementation
> at all!
I suspect that the R5RS community will continue to exist and thrive
just as well as it always has.
Why do you think it wouldn't?
samth
> On Oct 7, 4:20 am, tom.gor...@me.com wrote:
>
> > An interesting bit of Scheme history. But now the debate is over and
> > the "cleaned-up Common Lisp" alternative has won. There doesn't seem
> > to be any current interest in creating a programming language
> > *standard* for the "cleanest and best programming language". And I've
> > never understood the point of using industry standards for academic
> > purposes.
>
> The same bunch of editors was around from RRRS (R2RS) up to and
> including R5RS. That is 13 years. None of those guys are on the board
> for R6RS (The exception here is Kent Dybvig which was been on since
> R3RS.).
Will Clinger was also part of the Editors Committee for almost all of
the R6RS process, and he had significant influence on the current
R6RS, although he resigned prior to the end of the process and is
therefore not listed as an editor on the final document.
Richard Kelsey was on the original Editors Committee for R6RS, but
resigned early in the process.
Jonathan Rees was not one of the Editors for R6RS, but did vote on
(against) the final version.
The Steering Committee (Wand, Steele and Bawden) were all old-time
members of the Scheme community.
So I think there was substantial continuity between the past and the
present.
sam th
chthon
> >>> (Btw. I ordered
> >>> "Principes d'implantation de Scheme et Lisp", so studying how they are
> >>> implemented should soon be possible).
>
> >> An excellent book (I've got the english translation of the first
> >> edition). It will answer all your questions - and then some.
>
> > Is that the book known in English as Lisp In Small Pieces?
>
> > If so, I definitely concur. Excellent book.
>
> That is a phenomenal book and it might take 5 or 6 readings to get the
> full impact of it. I wish there was somthing intellectually in between
> The Structure and Interpretation of Computer Programs and List in Small
> Pieces though...
>
> -pete
It is the successor, from beginning of 2007. The previous English
version is starting to get expensive and somewhat difficult to find,
so I decided to bite the bullet and order the French version (34EUR,
and I got a colleague here who's mother in law lives in Paris, so no
transport cost either).
Jurgen
Majorinc Kazimir
>
> Macros were invented in 1963, and are an important consequence of
> McCarthy's code=data equation.
>
> Any language that hasn't lisp-equivalent macros is a shame, and not
> worth is weight in bits.
Lisp-equivalent macros are bit (better, few
bytes) of syntactic sugar in every language
with eval which can access to local variables.
In such language instead of
(my-macro expr1 ... exprn)
one has to write:
(eval (my-function 'expr1 ... 'exprn))
The second version is even semantically superior,
since my-function is probably the first-class value,
while my-macro is not. CL and Scheme evals
cannot do that.
Pascal J. Bourguignon
You realize that this implies two very strong requirements on that
language.
- you need to be able to access the lexical environment (to be able to
implement safely some macros).
- you need to be able to quote expressions, or said otherwise, you
need s-expressions.
Actually, the later requirement could be avoided if you can pass
strings and evaluate strings, but this is on the verge of the turing
tarpit. It's possible, but you really don't want to manipulate
program sources as strings.
On the other hand, in a programming language that implements these two
requirements, or as you put it, where you can evaluate quoted
expressions, you can easily add the bits of syntactic suggar
implementing the metalinguistic abstraction of "macro" over these
low-level primitives. This is something that has been done in 1963.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
leppie
> The second version is even semantically superior,
> since my-function is probably the first-class value,
> while my-macro is not. CL and Scheme evals
> cannot do that.
Superior at runtime, but does not feature at compile time, which is
the point of macros.
Majorinc Kazimir
I think the point is in additional expressive power,
not provided by "ordinary" functions. And that need
for optimization of macro calls is just like
for any other feature, including function calls -
optimize if you can, and if you cannot
- then better to provide slow version than nothing.
However, if you want to use macros only if they can be
expanded during compile time, in such cases
(eval (my-function 'expr1 ... 'exprn))
provides exactly the same opportunity for optimization
during compile time as
(my-macro expr1 ... exprn)
The reason is - in that particular case my-function, 'expr1 ...
'exprn - everything is constant. It is just like (sin 4).
It can be optimized during compile time.
samth
These are not merely syntactic sugar for each other. Macros preserve
a fundamental separation between expansion time and run time, which
eval does not. Further, the ability of `eval' to bind new variables
is a feature that most languages will live to regret.
sam th
Ray Dillinger
You say that as though you think macros have only one point.
Bear
Majorinc Kazimir
>
> These are not merely syntactic sugar for each other. Macros preserve
> a fundamental separation between expansion time and run time, which
> eval does not.
They do - but why it is important? Such separation
doesn't make (my-macro ...) more expressive or better
optimizable than equivalent (eval (my-function ... ))
expression.
> Further, the ability of `eval' to bind new variables
> is a feature that most languages will live to regret.
Why?
Vend
Doesn't that work:
(eval `(,my-function expr1 ... exprn))
leppie
> leppie wrote:
> > Superior at runtime, but does not feature at compile time, which is
> > the point of macros.
>
> You say that as though you think macros have only one point.
I am not sure I follow you.
Maybe I should have worded it as ... the point of macros in terms of
when they execute?
Majorinc Kazimir
>
> Doesn't that work:
> (eval `(,my-function expr1 ... exprn))
No, because eval doesn't see local
variables in expr1 ... exprn.
(eval '(let ((x 1)(y 2))
(+ x y)))
=>3 because x and y are defined inside eval
But:
(let ((x 1)(y 2))
(eval '(+ x y)))
=>"reference to unidentifed identifier x!"
If you want eval & my-function to replace
macros, eval should access everything normal
code can. Just like it is not there. And it
is not the case in CL & Scheme.
Pascal Costanza
This looks ugly. One of the many important points of macros is that you
can extend the base language with new constructs that look and behave
like any other language construct.
For example, in Scheme 'if is a base language construct while 'cond is
derived from 'if (or some other low-level construct). Do you seriously
want to suggest that we should say the following from now on?
(eval (cond '((> x 0) (display "x is more than zero"))
'((= x 0) (display "x is zero"))
'((< x 0) (display "x is less than zero"))))
...instead of...
(cond ((> x 0) (display "x is more than zero"))
((= x 0) (display "x is zero"))
((< x 0) (display "x is less than zero")))
You could extend Scheme or Lisp with first-class macros (nlambda,
fexprs, etc.) to avoid such ugliness, but then you get other problems...
Pascal
Ray Dillinger
> On Oct 11, 4:17 am, Ray Dillinger <b...@sonic.net> wrote:
>> leppie wrote:
>> > Superior at runtime, but does not feature at compile time, which is
>> > the point of macros.
>>
>> You say that as though you think macros have only one point.
>
> I am not sure I follow you.
For most of us, I think a pretty important point of macros
is syntax - the idea that we can define a macro in such a way
that one simple expression which matches the way we think about
an action can substitute for possibly several quite complex
expressions, which don't match the way we think about an action
but do implement that action given the structure of the rest of
the code.
Another point is that macro definitions can be changed in one
place when the structure of the rest of the code changes, and
the macro-using code can continue to do what it did in terms
of application-level actions even though the underlying data
structures may be very different.
I for one don't really give a flying leap about runtime versus
compile time, link time, or whatever. Furthermore, if I ever
find that I *have* to care, in terms of semantics, I will
strongly suspect that it is because I have made a serious design
error.
Bear
Majorinc Kazimir
>
> This looks ugly. One of the many important points of macros is that you
> can extend the base language with new constructs that look and behave
> like any other language construct.
Yes!
> For example, in Scheme 'if is a base language construct while 'cond is
> derived from 'if (or some other low-level construct). Do you seriously
> want to suggest that we should say the following from now on?
>
> (eval (cond '((> x 0) (display "x is more than zero"))
> '((= x 0) (display "x is zero"))
> '((< x 0) (display "x is less than zero"))))
I do not intend to go that far. I only said
that macros provide few bytes of syntactic sugar
over that. I do not say that syntactic sugar
is useless.
But syntactic sugar should be taken for
what it is. If Python or Ruby programmer
ask "why is Lisp great?" and Lisp programmer
says "macros", he should be aware that they
already have this functionality - in the form
of uglier, but simple idiom, and that it is
"first class" citizen unlike CL or Scheme
macros. I do not really think this comparison
is favorable to Lisp.
Yes, fexprs (like they existed in ancient Lisps and
still exist in Newlisp) have potential to unify macros
and functions, but true, it is complicated issue.
Scott
>
> You could extend Scheme or Lisp with first-class macros (nlambda,
> fexprs, etc.) to avoid such ugliness, but then you get other problems...
>
Ignoring possible performance/optimization considerations, what's
wrong with fexprs?
Ray Dillinger
In the original implementations thereof, they were prone to
evaluating expressions in the wrong environments. Simple
applications of them were fine and clever and evaluated
expressions in the environment at the call site. But when
you started having one fexpr passing its arguments to another,
the mechanism no longer worked; one argument expression
needed evaluating at the call site of the first fexpr, and
another needed evaluating at the call site of the second
fexpr, and the calling disciplines simply didn't encapsulate
enough information for the runtimes to do it correctly.
Fexprs were largely abandoned because of this problem.
In order to fix this problem, you have to make your runtime
pass environments along with *EACH* argument expression, to
assure that each argument is evaluated in the (lexical+dynamic)
environment where it actually appeared. You also need to pass
the environment of the call site (which may turn out to be
different from the environment of any argument expression) so
that the fexpr can do its work at the call site. I implemented
a toylisp with this calling discipline (for *ALL* functions, which
is a quite serious cost considering you usually don't need this
power) as an experiment, but as far as I know, this has never
been implemented in any released lisp.
Bear
William D Clinger
> Will Clinger....
>
> Richard Kelsey....
>
> Jonathan Rees....
>
> The Steering Committee (Wand, Steele and Bawden)....
>
> So I think there was substantial continuity between the past and the
> present.
Of the six individuals mentioned by samth, none voted to
ratify the documents that became R6RS. Clinger and Rees
voted against ratification. The other four abstained.
Will
Vend
> On Mon, 06 Oct 2008 23:11:09 +0200, p...@informatimago.com (Pascal J.
>
>
>
> Bourguignon) wrote:
> >"Jeff M." <mass...@gmail.com> writes:
>
> >> On Oct 6, 3:53?pm, p...@informatimago.com (Pascal J. Bourguignon)
> >> wrote:
>
> >>> But I repeat, it's ludicruous, useless and dangerous to try to break
> >>> the encapsulation of data.
>
> >> And this is where we differ, friend.
>
> >> I don't know the kind of work you do with computers, but I'll assume
> >> it's good, grand, and very different from what I do. ;-)
>
> >> But, I promise, the work I do requires that kind of code daily in
> >> order to squeeze every last bit of memory and speed out of the
> >> machine... let alone the wonderful 8-bit microprocessors I was working
> >> on before that (using Forth). And I couldn't imagine trying to do the
> >> same work without those fundamentals available to me.
>
> >Well, squeezing bits might be funny (I like to to do it occasionnaly
> >too), but it's not CS.
>
> >Remember that Turing Machines have *infinite* memory! ;-)
>
> In looking through the RRRS-Authors Mailing-List Archive (seehttp://groups.csail.mit.edu/mac/projects/scheme/rrrs-archive.html), I
> came across the following apparently relevant quotation (fromftp://ftp.swiss.ai.mit.edu/pub/scheme-mail/rrrs.mail20.gz).
>
> (Pardon the expletive at the very end of this quotation--if you cannot
> stand expletives, please stop reading this message here!):
>
>
>
> >From c...@martigny.ai.mit.edu Wed Mar 19 14:12:52 1997
> >[...]
> >Date: Wed, 19 Mar 1997 14:12:47 -0500
> >From: Chris Hanson <c...@martigny.ai.mit.edu>
> >[...]
> >Subject: a (revised) draft of R5RS
>
> >This is the reason that Scheme standardization is dead.
>
> >On the one hand, there are a group of people who are trying to make
> >Scheme a useful programming language. These people make expedient
> >choices that use the best currently available technology to produce a
> >language with the expressive power to write complex programs. These
> >people are programmers who are trying to use Scheme as a tool.
>
> >On the other hand, there are a group of people who are trying to make
> >Scheme the cleanest and best programming language. These people want
> >to wait until the technology has reached the point that it is elegant,
> >well understood and well integrated with the rest of the language
> >before it is standardized on. These people are language designers who
> >are trying to make Scheme the best possible language, a work of art.
<rant>
If they want to design a crippled language just to fulfill some
abstract and entirely subjective aesthetic ideal, they can always make
something like Unlambda or Iota.
Scheme is supposed to be an useable and useful language, maybe not for
mass-producing websites, but at least for research and teaching, IMHO.
</rant>
Aaron W. Hsu
><rant>
>If they want to design a crippled language just to fulfill some
>abstract and entirely subjective aesthetic ideal, they can always make
>something like Unlambda or Iota.
>Scheme is supposed to be an useable and useful language, maybe not for
>mass-producing websites, but at least for research and teaching, IMHO.
></rant>
<rant>
Why do people continue to think that R5RS based Schemes were useless
or not very useful for real-world work outside of reasearch and
teaching? I used them commercially all the time, and they worked better
than many other infrastructures that people tried to sell me.
It is possible to make a very useful language that is also aesthetically
and philosophically pleasing.
</rant>
Aaron Hsu
--
+++++++++++++++ ((lambda (x) (x x)) (lambda (x) (x x))) +++++++++++++++
Email: <arc...@sacrideo.us> | WWW: <http://www.sacrideo.us>
Scheme Programming is subtle; subtlety can be hard.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Abdulaziz Ghuloum
> <rant>
> Why do people continue to think that R5RS based Schemes were useless
> or not very useful for real-world work outside of reasearch and
> teaching? [...]
> </rant>
Correct me if I'm wrong, but I don't think "people" talked about
"R5RS based Schemes" since everybody knows the usefulness of Chez,
Chicken, Gambit, MzScheme, etc., outside of research and teaching.
There might have been some talk about "R5RS the standard", which is,
for the most part, not that useful even for research and teaching
(IMNSHO).
Aziz,,,
Vend
Aaron W. Hsu
>Aaron W. Hsu wrote:
People inferred that Scheme was "not useful" for real programming
because the R5RS standard wasn't complete enough for real programming,
implying that a Scheme in practice -- meaning an implementation --
was useless for "real" programming.
Grant Rettke
wrote:
> There might have been some talk about "R5RS the standard", which is,
> for the most part, not that useful even for research and teaching
> (IMNSHO).
Is R6RS useful for research and teaching? And "real work"?
leppie
> Is R6RS useful for research and teaching? And "real work"?
With a few implementation extensions (actually just a hook) in
IronScheme, I dished up a complete 'MVC' web framework.
IMO, it is close enough for real world usage. From a professional
point of view, I would have to question maintainability though.
Cheers
leppie
Grant Rettke
How so?
leppie
> On Oct 15, 3:33 am, leppie <xacc....@gmail.com> wrote:
>
> > On Oct 14, 9:16 pm, Grant Rettke <gret...@gmail.com> wrote:
>
> > > Is R6RS useful for research and teaching? And "real work"?
>
> > With a few implementation extensions (actually just a hook) in
> > IronScheme, I dished up a complete 'MVC' web framework.
>
> > IMO, it is close enough for real world usage. From a professional
> > point of view, I would have to question maintainability though.
>
> How so?
Due to the small user community of Scheme, finding some one to
maintain the code will be harder when the author has moved on. In an
open source environment that would work, but would be risky for a
company.
That's just my opinion.