[Scheme-reports] Ratification vote for R7RS Small

[Mikael <mikael.crspdc@x>]

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

Rationale:

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

Now:

1)

Problem:

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.

Rationale:

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:

Suggestion:

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

2)

Problem:

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

 * Maintain two files per library

Rationale:

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.

Suggestion:

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!

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports