Scheme Language Steering Committee Report to the Community
Mitchell Wand
Since the last report of the Steering Committee, a number of important
changes have taken place.
First, Marc Feeley and Manuel Serrano have resigned from the Editors
Committee. We have accepted their resignations with regret, and with
gratitude for the efforts they have expended to produce a revised
Scheme standard.
In light of these changes, the Steering Committee has amended the
Charter to:
(a) change the number of Editors from seven to five.
(b) replace the office of Editor-in-Chief by a Chair and a Project
Editor. The Chair is responsible for organizing meetings and other
activities and ensuring that the process makes progress in an orderly
fashion. The Project Editor is responsible for producing
standardization documents.
The five editors have chosen their Chair and Project Editor. They
are:
Chair: Kent Dybvig
Project Editor: Mike Sperber
The Editors Committee has now produced a progress report, which is
available at schemers.org. In it they state their intention to
deliver to the Steering Committee a complete draft R6RS by September
1, 2006.
The Steering Committee looks forward to receiving their draft.
Alternate links to the Editors' Progress Report:
http://www.cs.indiana.edu/~dyb/r6rs/status.pdf
http://www.cs.indiana.edu/~dyb/r6rs/status.html
---The Scheme Language Steering Committee:
Alan Bawden
Guy Steele
Mitch Wand
Psy-Kosh
>
> Alternate links to the Editors' Progress Report:
>
> http://www.cs.indiana.edu/~dyb/r6rs/status.pdf
> http://www.cs.indiana.edu/~dyb/r6rs/status.html
>
This may be a really stupid question, but why're hash tables considered
definately library?
Let be clarify that: From what I understand, implementing symbols properly
more or less requires internal use of a hash table (right?)
ie, since it has to be there implicitly in the core anyways.......
Psy-Kosh
Alex Shinn
>
> This may be a really stupid question, but why're hash tables considered
> definately library?
>
> Let be clarify that: From what I understand, implementing symbols properly
> more or less requires internal use of a hash table (right?)
>
> ie, since it has to be there implicitly in the core anyways.......
A limited form of symbol-only value-less hash table with no exposed
API is implied.
A real hash-table API would include much more, and there was quite a
lot of disagreement on the SRFI-69 list, so it is definitely good
that this is relegated to a library.
You might make a case for asking the core to include something like
SYMBOL-HASH in order to make it easier to write a portable and
efficient hash-table library.
--
Alex
Psy-Kosh
>
> A limited form of symbol-only value-less hash table with no exposed
> API is implied.
>
> A real hash-table API would include much more, and there was quite a
> lot of disagreement on the SRFI-69 list, so it is definitely good
> that this is relegated to a library.
>
> You might make a case for asking the core to include something like
> SYMBOL-HASH in order to make it easier to write a portable and
> efficient hash-table library.
>
Okie, thanks. Not trying to make a case either way, more just a case of
not knowing too much about lang implementation, and trying to understand.
Psy-Kosh
Aubrey Jaffer
I am disappointed to see that although "homogeneous numeric vectors"
appears in section "4.8. Other possible changes", there is no mention of
arrays.
SRFI-63:
Computations have been organized into multidimensional arrays for over
200 years. Applications for multi-dimensional arrays continue to
arise. Computer graphics and imaging, whether vector or raster based,
use arrays. A general-purpose computer language without
multidimensional arrays is an oxymoron.