Was there a schism between R4RS and R5RS?

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.

Two things here:

1. The full archives of the RRRS authors list is available here:
http://groups.csail.mit.edu/mac/proj...s-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

On Oct 6, 9:58*am, Grant Rettke <gret...@gmail.com> wrote:
> 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.

Grant Rettke skrev:
> 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

Grant Rettke <grettke@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.

--
__Pascal Bourguignon__ http://www.informatimago.com/

"Debugging? Klingons do not debug! Our software does not coddle the
weak."

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;
}

// 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.

"Jeff M." <massung@gmail.com> writes:

> 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....9c20a07b315f7a



> // 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.

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.

Jeff M.

"Jeff M." <massung@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! ;-)


--
__Pascal Bourguignon__ http://www.informatimago.com/

"Debugging? Klingons do not debug! Our software does not coddle the
weak."

pjb@informatimago.com (Pascal J. Bourguignon) writes:
> 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,
rAYblaaK@STRIPCAPStelus.net The Rhythm has my soul.

On Mon, 06 Oct 2008 23:11:09 +0200, pjb@informatimago.com (Pascal J.
Bourguignon) wrote:

>"Jeff M." <massung@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/proj...s-archive.html), I
came across the following apparently relevant quotation (from
ftp://ftp.swiss.ai.mit.edu/pub/schem...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 cph@martigny.ai.mit.edu Wed Mar 19 14:12:52 1997
>[...]
>Date: Wed, 19 Mar 1997 14:12:47 -0500
>From: Chris Hanson <cph@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

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.

-Tom Gordon

tom.gordon@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.

--
Nils M Holm <n m h @ t 3 x . o r g> -- http://t3x.org/nmh/

tom.gordon@me.com writes:
>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!

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?

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

Brian Harvey wrote:

> 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,,,