R5RS? 
Author Message
 R5RS?

Could somebody tell me what's the current status of R5RS
(the Revised^5 Report on the Algorithmic Language Scheme)?

I recently read a preface to the upcoming second edition of
<a href=" http://www.*-*-*.com/ ;>
"The Scheme Programming Language" by R. Kent Dybvig</a>,
in which he says:

<cite>
The current report [...] is the "Revised^4 Report on the Algorithmic
Language Scheme," although as this book goes to press, there is already
agreement on features to be included in the Revised^5 Report.
</cite>

Does somebody know what these features are?
 - exception handling?
 - multiple values?
 - records/structures? Maybe even an object system?
 - eval?
 - definitive low level (non-hygienic) macro facilities?
 - some kind of random access input/output?
 - String ports (I/O)?
 - multithreading?
 - fluid variables?
 - dynamic-wind?
 - ...?

I've read most of the archives of the "rrrs-authors" mailing list
(they're in the scheme repository), but the most recent ones I can
find are dated July 1994. Are there more recent archives somewhere?
Is the mailing list still alive? If so, can I subscribe to it?

Maybe some of these questions have been discussed during the
20th Anniversay Scheme Workshop that took place in January?
Are there (or will there be) proceedings of this workshop?

I'd be very grateful for answers to some of these questions.
Despite some rather pessimistic messages I've read in
comp.lang.scheme during the last two years, I still haven't
lost faith in the language. If only some of the more conspicuous
holes (like exception handling and records) could be filled...

-----



Sat, 08 Aug 1998 03:00:00 GMT  
 R5RS?
I can't speak for the authors, but as I understand it, one
of the factors that has interfered with the development of
Scheme is the Uniform Consent Rule, in which all of the
authors have to agree to a proposal in order for it to be
accepted. A number of people have made valuable proposals
in the areas of modules, records, exceptions, and so on,
and, combined with things that have already been accepted
(such as eval and dynamic-wind), R5RS could have been
produced in the very near future. However, many of the
proposals are not completely unanimously supported, and
therefore, by the UCR, cannot be incorporated into the Report.

At the recent Scheme workshop in St Petersburg Beach, there
was much discussion of the future of Scheme. None of the above
areas was identified as being THE roadblock to the success of
the language. The big issue was identified as interoperability,
and specifically interoperability with Java (this might be a
problem, because it may not clear how to make the Java VM and
continuations interact efficiently).

What I hope will happen is that the authors will get together,
and clear the deck of all outstanding issues. This would result
in the issuance of R4.5RS. After that, some serious language
design to support a GOOD foreign function interface, including
data mapping and callbacks, should be done. (It's not even as
though this is {*filter*} territory: there are lots of FFI's for
Scheme---some better than others---and lots for other related
languages too.)



Sat, 08 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:
(Arthur Lemmens) writes:
>Could somebody tell me what's the current status of R5RS
>(the Revised^5 Report on the Algorithmic Language Scheme)?

At last month's 20th anniversary workshop on Scheme, Olivier
Danvy told me he and others were working on the R5RS.  He did
not name a date.

The Scheme repository contains Jonathan Rees's Lisp Pointers
article on the June 1992 authors meeting.  This is the best
source for the expected content of the R5RS, and is my source
for the rest of this message.

Quote:
> - exception handling?

A committee appointed in 1992 has recently proposed a minimal
exception facility, but it is not yet clear whether it will be
included in the R5RS.

Quote:
> - multiple values?

Yes.

Quote:
> - records/structures? Maybe even an object system?

No.

Quote:
> - eval?

Yes.

Quote:
> - definitive low level (non-hygienic) macro facilities?

No.  The low-level macro facilities will be removed from the R5RS,
leaving only the hygienic high-level facilities.

Quote:
> - some kind of random access input/output?
> - String ports (I/O)?
> - multithreading?

No.

Quote:
> - fluid variables?

No, but most uses of fluid variables for single-threaded systems
are subsumed by dynamic wind.

Quote:
> - dynamic-wind?

Yes.

William D Clinger



Sun, 09 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:
> > - definitive low level (non-hygienic) macro facilities?

> No.  The low-level macro facilities will be removed from the R5RS,
> leaving only the hygienic high-level facilities.

I understand that hygiene and `levelhood' are essentially orthogonal
concepts (indeed, extend-syntax, pattern-only syntax-rules, defmacro
and syntactic closures seem to cover the discrete spectrum).  But
since Dybvig &c seem to have a workable solution to accomodating
escape from hygiene in the context of a `high-level' facility (I refer
to syntax-case), it isn't clear why one would want only a hygienic
facility, even a high-level one.

Could you elaborate?

Thanks,
'shriram



Sun, 09 Aug 1998 03:00:00 GMT  
 R5RS?

   Records I can understand -- it would be nice to have a uniform record
   facility that is really a record type, and not just a vector, or a function.
   But what will opaque types buy Scheme?

Abstraction.  (And in case you wonder: no, I don't consider procedures
(lambda) to be the ultimate abstraction tool for data.)

--
-Matthias



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?


   >This is too bad for the future of Scheme.

   <Sigh.>  Everyone thinks Scheme will die unless it adds feature X, and
   everyone picks a different value of X.  There must be a m{*filter*}here...

Yes.  The m{*filter*}is: Scheme is _already_ dead.  `But there are worse
things than being dead.' (Olin, are you reading this? :)

--
-Matthias



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:

>(Arthur Lemmens) writes:
>>Could somebody tell me what's the current status of R5RS
>>(the Revised^5 Report on the Algorithmic Language Scheme)?
>At last month's 20th anniversary workshop on Scheme, Olivier
>Danvy told me he and others were working on the R5RS.  He did
>not name a date.
>The Scheme repository contains Jonathan Rees's Lisp Pointers
>article on the June 1992 authors meeting.  This is the best
>source for the expected content of the R5RS, and is my source
>for the rest of this message.
>> - records/structures?
>No.

This is too bad for the future of Scheme.  It was clear from the workshop
that the main future of Scheme is in its educational niche.
Also made clear was the key point of teaching students to do different
kinds of recursions by teaching them to pay close attention
to the (grammatical) form of their input.
Records (as in the define-record syntax of EOPL) and opaque types
would be a definite aid in such teaching.  Without them students
always tend to think they are working with lists.  One has far fewer
such problems when teaching in a language such as ML or Haskell.

But if this is too fundamental a change for the Scheme authors,
then I say: leave Scheme as it is and produce a clone of Scheme
that has better properties.  Scheme has had
too much success to keep improving as a language apparently.
But a clone of Scheme could be improved because it wouldn't have
to be Scheme, even though it could look a lot like Scheme.
Felleisen and Wright are, it seems, already well on the way to making
a successful such clone, with a record facility and opaque types.
I wish them well in their efforts.

(Of course, maybe the Scheme authors will wake up and change
their political structure to allow such important changes.
But from the workshop, it seems there is little cause for optimism.)

P.S.  An object system isn't nearly so important as this
kind of record system.

        Gary Leavens
--
        229 Atanasoff Hall, Department of Computer Science

        phone: (515)294-1580 fax: (515)294-0258 ftp site: ftp.cs.iastate.edu
        URL: http://www.cs.iastate.edu/~leavens/homepage.html



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?


Quote:


>>(Arthur Lemmens) writes:
        [ stuff deleted ]

>But if this is too fundamental a change for the Scheme authors,
>then I say: leave Scheme as it is and produce a clone of Scheme
>that has better properties.  Scheme has had
>too much success to keep improving as a language apparently.
>But a clone of Scheme could be improved because it wouldn't have
>to be Scheme, even though it could look a lot like Scheme.
>Felleisen and Wright are, it seems, already well on the way to making
>a successful such clone, with a record facility and opaque types.
>I wish them well in their efforts.

Records I can understand -- it would be nice to have a uniform record
facility that is really a record type, and not just a vector, or a function.
But what will opaque types buy Scheme?

Quote:

>    Gary Leavens
>--
>    229 Atanasoff Hall, Department of Computer Science


Steven Jenkins
272 Durham
Iowa State University


Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:
>This is too bad for the future of Scheme.

<Sigh.>  Everyone thinks Scheme will die unless it adds feature X, and
everyone picks a different value of X.  There must be a m{*filter*}here...

Personally, I still think Scheme's big problem is that R4RS doesn't
specify whether or not (read) eats the damn carriage return.  Could
the R5RS authors please fix this?

(I'm joking about "big problem" but I'm serious about fixing it!)



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?

   > - multiple values?

   Yes.

   > - records/structures? Maybe even an object system?

   No.

   > - eval?

   Yes.

   > - dynamic-wind?

   Yes.

Here you are.  Scheme's problems in a nutshell.  As far as I am
concerned, what we really need is the bitwise negation of these
decisions:

        multiple values: no!
        records: yes!
        eval: no!
        dynamic-whatever: no

I have already moved on to a language that makes the better decision
in all of these areas and then some: SML.  And from what I saw at the
Scheme workshop it doesn't look like I will ever regret that move.

Cheers,
--
-Matthias



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:
> But if this is too fundamental a change for the Scheme authors,
> then I say: leave Scheme as it is and produce a clone of Scheme
> that has better properties.

You may wish to look at the documentation we provide via

  http://www.*-*-*.com/ ~scheme/

This is the documentation site for Rice Scheme, which is Rice's
extension to (Chez/Mz) Scheme.  (The actual documentation there is a
bit dated in its specifics; our structures are now both disjoint and
generative by default.)

In particular, we have had generative (and, optionally, opaque)
structures for about eigh{*filter*} months now, and we use them extensively
even for serious, large-scale development work, not just for pedagogic
purposes.  (They have proven especially handy in the former context.)

DrScheme is our unified Scheme programming environment, featuring
various linguistic niceties, useful programming libraries, graphics
and an extensive debugging and analysis environment:

  http://www.*-*-*.com/ ~mflatt/drscheme.html

We have preliminary versions which are being used and tested in-house.

--

            Save the environment.  Create a closure today.
                                                     --Cormac Flanagan



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:


>>This is too bad for the future of Scheme.
><Sigh.>  Everyone thinks Scheme will die unless it adds feature X, and
>everyone picks a different value of X.  There must be a m{*filter*}here...

I guess I didn't make myself very clear.  I didn't mean that Scheme was
going to die unless records and opaque types were added.
(And I haven't been asking for features either...)
What I meant was that it would make Scheme a better teaching language.

In fact, as I started to type this, I was interrupted by a student
in my class, with exactly the problem I think would be clarified by
using records.  The problem is, students tend to think everything is a list,
and write (if (null? ls) ...) at the top of every procedure.
This is despite teaching that emphasizes otherwise.
Once you use records, this problem goes away, because the student will
get a type error instead of coming around wondering why their code
doesn't work.

On the other hand, it's clearly not *needed* in Scheme.
We can, and do, use a macro to do records.  But without opaque types
this record is somewhat ineffective...

        Gary Leavens

--
        229 Atanasoff Hall, Department of Computer Science

        phone: (515)294-1580 fax: (515)294-0258 ftp site: ftp.cs.iastate.edu
        URL: http://www.*-*-*.com/ ~leavens/homepage.html



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?
Quote:

> Personally, I still think Scheme's big problem is that R4RS doesn't
> specify whether or not (read) eats the damn carriage return.  Could
> the R5RS authors please fix this?While I'm one of the people Brian laments---yes, I do think that Scheme

needs records, exceptions, etc, he's also right about the `damn carriage
return'. There are in fact many intentional imprecisions: what happens
if you attempt to open a file that doesn't exist, for example?

For that matter, I still can't figure out whether -1+ is a legal
identifier. It all depends upon whether the phrase `in all
implementations' at the beginning of Section 2.1 is intended
prescriptively or descriptively.



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?

Quote:
>[...]
>At the recent Scheme workshop in St Petersburg Beach, there
>was much discussion of the future of Scheme. None of the above
>areas was identified as being THE roadblock to the success of
>the language. The big issue was identified as interoperability,
>and specifically interoperability with Java

nnnnnnNNNNNNNNNNYYYYYYYYAAAAAAAAAARRRRGH!

Java this, java that, java, java, java, java, java java JAVA.

Ptui!

{*filter*} it.  I'm with Matthias Blume.  If fercryinoutloud *java*
compatibility is the biggest issue in the evolution of Scheme,
then I'm tearing up my Scheme Fan Club membership card and finding
a new favorite functional programming language.

  ``Programming languages should be designed not by piling
    feature on top of feature, but by removing the weaknesses
    and restrictions that make additional features appear
    necessary.''

Doesn't that sound at all familiar to anyone?

What I'm wondering is: what could possibly make Java-compatibility
appear necessary to begin with other than Sun's and Netscape's
marketing hype?  What for that matter makes 'eval' appear necessary
other than the twice-weekly newbie query "Does Scheme have 'eval'?"
in this newsgroup?  And who the hell is asking for 'call-with-values',
anyway?

Last but not least what features are going to be *removed* so that
a *module system* no longer appears necessary?


  Haskell... yeah, that's it, Haskell...



Mon, 10 Aug 1998 03:00:00 GMT  
 R5RS?
Quote:

> {*filter*} it.  I'm with Matthias Blume.  If fercryinoutloud *java*
> compatibility is the biggest issue in the evolution of Scheme,
> then I'm tearing up my Scheme Fan Club membership card and finding
> a new favorite functional programming language.As a teacher, I'm primarily interested in doing things to my students

that cause them to see the world in new and better ways. Scheme is
very much a part of that, and would be so even if nobody in the Real
World ever used it for Serious Programming.

My students tend to be quite forgiving in allowing me to teach this
stuff to them, even though they force me to agree with them that
there is not a great deal of Scheme in the Real World. Regardless of
what I might say, they know that Scheme is this little toy that one
must ditch when one wants to write Real Programs that use ODBC, DSOM,
SQL, DCE, and all the other TLAs knowledge of which puts money in
their pockets.

What *I* would like is a programming language that is designed on
a good solid theoretical foundation, which is orthogonal in the good
sense (consistent, small basis set), and which scales up to solving
real problems. I would be able to teach that language to students,
knowing that as their skill progressed they would be able to master
more and more advanced problems, and that eventually their skills
(including those of programming in Scheme) would allow them to take
on serious programming projects and build a career.

For the past seven or eight years I have hoped that Scheme would be
that language. I still don't see a reason why a language cannot have
a good, simple, core, and still provide (as libraries, if nothing else)
tools that allow one to build large programs. After all, most good
Scheme implementations come with records, and several macro tools.
Many already have foreign function interfaces.

Quote:
> What I'm wondering is: what could possibly make Java-compatibility
> appear necessary to begin with other than Sun's and Netscape's
> marketing hype?  I'm still not entirely sure that Java is real (I was reporting on

the mood at the workshop). However, you CANNOT write real programs
unless you can easily get at the host platform's capabilities, as
well as all of the various class libraries around. I won't try to
comment on the other workshop participants' views, but speaking for
myself, Java is not a particularly interesting programming language;
what it does represent is a genuinely ubiquitous virtual machine,
support for which could make Scheme a lot more popular than it
currently is.

Quote:
> Last but not least what features are going to be *removed* so that
> a *module system* no longer appears necessary?I have no idea, but Albert Einstein said that a physical theory should

be as simple as possible, but NO SIMPLER.


Mon, 10 Aug 1998 03:00:00 GMT  
 
 [ 105 post ]  Go to page: [1] [2] [3] [4] [5] [6] [7] [8]

 Relevant Pages 

1. R5RS

2. Multiple values in R5RS Scheme

3. R5RS and the June92 Meeting....

4. R5RS

5. Whither R5RS?

6. R5Rs?

7. R5RS

8. R5RS anywhere ?

9. Is there to be an R5RS?

10. Status of R5RS records?

11. implementing r5rs macros

12. R5RS request: promise?

 

 
Powered by phpBB® Forum Software