[r6rs-discuss] comment and vote (if allowed)

From: Elf <elf>
Date: Fri, 24 Aug 2007 06:05:03 -0700 (PDT)

On Tue, 21 Aug 2007, Thomas Lord wrote:

<snip>
> Those of us who aren't entirely excited about 5.97 have solid
> criticisms all around, in my view, but we now "owe the
> community" (so to speak) some work to back up our criticisms
> with a pragmatic alternative.
>

fair enough. pragmatic alternative to r5.97, based on the 'guiding principles'
section of the 1 mar 2006 r6rs status report:


* allow programmers to create and distribute substantial programs and libraries
   eg SRFI implementations, that run without modification in a variety of
   Scheme implementations;

clearly, we need some form of module/library system and some means of publishing
what modules are available. we already have SRFIs 0, 7, and 55; additionally,
most implementations have some form of module system. what would be the
functionality intersection of the SRFIs and assorted module systems?
furthermore, in the interests of interoperability, would it be possible for
each implementation to publish its differences from the standard as a module
(or library) that could be included with a module system (ie, if i am running
chicken, an ideal module system would allow me to add a 'guile' module for
whatever functionality guile has outside of r6rs, etc)? this may require
some meta-FFI semantics for expressing scheme to outside languages. there are
also some clear pitfalls here between interpreters and compilers that need to
be explored.

* support procedural, syntactic, and data abstraction more fully by allowing
   programs to define hygiene-bending and hygeine-breaking syntactic abstractions
   and new unique datatypes along with procedures and hygenic macros in any
   scope;

define-macro would be a plus. syntax-case would be a plus (potentially).
new datatypes... record semantics would mean a cleanup of SRFI 9 and 57, not
an entire rewrite, in my opinion.

* allow programmers to rely on a level of automatic run-time type and bounds
   checking sufficient to ensure type safety while also providing a standard
   way to declare whether such checks are desired;

first, this seems like fluff and unnecessary to include. second, i do not
recall anything in the r6rs draft that addressed this. this amounts to
simple correctness checking if i understand properly.

* allow implementations to generate efficient code, without requiring
   programmers to use implementation-specific operators or declarations.

again, i believe that this requirement is in error. what constitutes
'efficient' code is dependent on the system's intended use. a number-crunching
app doesn't necessarily care about string handling. additionally, a
one-size-fits-all 'efficiency' definition destroys the usefulness of individual
implementations.


* In general, R^6RS should include building blocks that allow a wide variety
   of libraries to be written,

R5RS already allows this. *ANY* real language allows this.

* include commonly used user-level features features to enhance portability
   and readability of library and application code, and exclude features that
   are less commonly used and easily implemented in separate libraries.

who or what has determined what are 'commonly used user-level features'?
almost all of the changes in r6rs are not things i commonly use nor intend to.
and how did unicode support become both commonly used and not easily implemented
as a separate library? ditto the arithmetic? ditto most of the changes?

* R^6RS Scheme should also be backward compatible with programs written in
   R^5RS Scheme to the extent possible without compromising the above principles
   and future viability of the language.

'backward compatability' and 'future viability' were both obviously discarded.

* With respect to future viability, we operate under the assumption that many
   more Scheme programs will be written in the future than exist in the present,
   so the future programs are those with which we must be most concerned.

given the vocal and reasoned opposition to r5.97, is this a valid assumption?
i for one can state that i will not be writing r5.97 scheme programs. period.
many/most implementators have stated that they will not support r6rs. how
exactly is this new proposed standard increasing the viability of the language?


please, people, if the point of r6rs was to allow the language to be viable
commercially, to allow code to be more-or-less implementation independent,
and to remain true to scheme... scrap the proposed draft. find some module
or library system similar to all existing ones, and give it sufficient power
to allow implementations to export their differences as modules includable by
others.

"Programming languages should not be designed by piling feature on top of
  feature, but by removing the weaknesses and restrictions that make additional
  features appear necessary. *Scheme demonstrates that a very small number of
  rules for forming expressions, with no restrictions on how they are composed,
  suffice to form a practical and efficient programming language that is flexible
  enough to support most of the major programming paradigms in use today.*"

Don't forget this.


-elf
Received on Fri Aug 24 2007 - 09:05:03 UTC