[Scheme-reports] Ratification vote for R7RS Small

Mikael mikael.crspdc at gmail.com
Mon May 13 00:54:43 EDT 2013

Full name: Mikael More

Statement of interest:
I value Scheme as a reference point among programming languages in its
being a simple and universal lambda
calculus-based language.
My take on the standardization process is that it's of value to contribute
to as it shapes Scheme's longer term
development and has a defining quality for its community.
I've used Gambit for long and have been involved in bringing about the
Black Hole module system for Gambit.
My use has focused on incremental development, and based on this experience
I've come to value suitability for
incremental development as a central quality for a Scheme or Scheme module
system in any nontrivial use.
I've gotten in touch with the complexity involved in providing a
library/module abstraction in the presence of
syntactic closures or define-macro and a syntactic tower.

Vote: no

I'm sincerely very impressed by the work with R7RS-small and believe it's
really close to completion.

I vote no solely with regard to two aspects of the Library syntax in 5.6. ,
and given that these two are addressed
this is to be considered a yes vote.

These two aspects both regard how well the library syntax delivers for
incremental development situations,
which should make up a majority of the total Scheme development being made.

Of course it may be that there has been something relevant regarding the
spec, for example some plan for 'hiding'
|define-library|, that I am not aware of, such that if I would have been
aware of it, I would have voted otherwise
already now - if so feel free to let me know.

It appears to me from the spec that the |import| form proposed is intended
to be used for any Scheme library
importing, and that by Scheme library is meant the Scheme code 'fragment'
or 'module' unit within the modularization
of any Scheme code project.

Any Scheme project of >~500-5000 rows of code is normally subdivided into
more than one library.
The general strategy is to keep the "main" code file minimal and keep as
much as possible of the code in library files.
This means that >99% of Scheme code in existence will be in the form of
library files.

For context on this topic, incremental development support should include
live re-imports at the level of indivudal
library while keeping Scheme environment state for libraries that have not
been reimported, this way
becoming a tool complementary to the interactive live code execution and
updates without need for application/
Scheme environment restarting that the REPL provides.

This is a really valuable quality of a Scheme system indeed for any larger


There is no description in the spec of what a library exports if it has no
(export) library declaration,
and this could very well be interpreted as something else than that in this
case, all of the library's
identifiers should be exported.

For [library] exports, an export-all by default approach is of value in
many incremental
development situations.

To give an example, a Tetris game, with rendering, keyboard input, and
other libraries.

The basic idea is that, as the programmer adds modules to the code project
and imports them
incrementally into the Scheme environment, it is implicit that every new
identifier the programmer
defines in a module should be exported to all of its dependencies;

The library abstraction is used as a means for
subdivision/modularization/separation of code only and the
code project is so small that there cannot possibly be any unexpectable
identifier/export collision to talk about.

A requirement to explicitly export symbols though, would require the
programmer to add this
as an extra consideration which is stricly speaking unnecessary, and would
provide a clear incentive
for the programmer to replace the spec-provided library functionality with
a custom one; this would
be an involvement of unnecessary complexity, and would also decrease the
generality of the spec-
provided library functionality so much that a less general name for its
|import| form, such as |import-library|,
would be really relevant to consider.

I would suggest that the R7RS Library syntax should be intended to deliver
for incremental development also,
as this appears like the most holistic approach - the Library syntax
describe a mechanism for
subdivision/modularization of code as it is already, so it would make sense
for it to be intended also for this
use. Therefore:

I'd suggest that a clarification is added to the spec that all identifiers
are exported by default, so that
that is the effect absence of an (export) library declaration has.

A library that wants not to export any identifiers specify an export
library declaration that lists
no libraries, i.e. (export) .

The Library syntax requires all library content to be put within the
|define-library| form (there in a begin or include* ).

This means that to define a library, the programmer is reasonably required
to either

 * Put all library code in a |define-library| and also indent accordingly,

 * Maintain two files per library

An incremental development situation makes use of any convenience as to
increase the speed of experimentation.
In such a situation, creating two files per library would seem completely
unjustified. Also, in general
Scheme development, Scheme can be made to work reliably without need for
separation of a library into
anything alike a separate header and code file. By this reason, I will not
consider the two files per
library usecase further here but focus on the other point:

I find a requirement that >99% of the Scheme code in existence needing to
be made within a particular form
and indented accordingly peculiar indeed;

The way Scheme code traditionally is divided into files works so well that
I believe a specific define-library form
in addition to this to contain the library, to be superfluous. And,

Scheme's traditional forms provide sufficient structure to perform
indentation based on.


Please find a way so that the library body in the library definition file
is at the top level.

One way would be to allow a variant of |define-library| of 5.6.1. to be
used as (define-library (library name))
and then provide the (library declaration):s subsequent to this one, with
the exception of the |begin| library
declaration whose contents are inlined by themselves.

I'd guess many times the Scheme file's filename would provide the
information otherwise provided by
(define-library (library name)) , so that that line could be made optional
generally also.

Thank you again for all your detailed work with R7RS-small - looking
forward to that it will be released soon!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scheme-reports.org/pipermail/scheme-reports/attachments/20130513/5b541b26/attachment-0001.htm 

More information about the Scheme-reports mailing list