[Scheme-reports] R7RS-large library declarations

[John Cowan <cowan@x>]

Peter Bex scripsit:

> This single identifier can be renamed which causes both these types
> of begins to be renamed.  In that sense it's really just one begin.

True.

> I'm unsure such things are very generally useful.  [...]  Perhaps
> it's more useful to add a sort of "pragma" declaration in which such
> annotations can be safely kept, being ignored by implementations that
> don't understand it.

They are already in effect pragmas, because they are all defined using
RFC 2119 "should", which means they can be ignored if they make no sense,
and that is spelled out in the proposal.  I also spell out that it is
not an error (though it is in Chibi) to provide a library declaration
that the implementation does not understand.

The only declarations for which support is by my proposal are "reexport"
and "notinline", and even the latter can be ignored if your implementation
does not inline code by its own decision.  If interfaces are included,
the "interface" declaration will also be required.

My list was compiled by looking at the declarations (and command-line
switches) of Common Lisp, Chicken, Gambit, and Bigloo (which has about
a hundred such declarations).  I looked briefly at other Schemes but
found nothing I wanted to add.

> OTOH, maybe SRFI-0 feature specifications are enough already to
> conditionalize extensions to the library forms for controlling
> optimizations and other compiler hints?

I don't see how that would work, because it is not suggested that you
can specify your own SRFI-0 features.  Also they are very unselective.

> I think pattern-matching shouldn't be added.   [...]  I'm already a
> little uneager to implement R7RS modules in Chicken.  Adding a pattern-
> matching thing to it will push the complexity well over the edge of
> being acceptable to implement IMHO.

To hear is to obey.  I have put everything in that part of the proposal
in the subjunctive, and made it clear that I am not proposing it though
someone else may do so.  That's just in order to keep the idea around
for completeness.

> Interfaces might be useful but probably need some more experimentation
> by implementers to figure out how useful they really are in practice.
> Without something that "needs" an interface in the abstract, it doesn't
> seem to add much benefit to be able to group identifiers in this way.

They are provided by Chicken and by Scheme48.  They are used at least
in the latter system when there is more than one good set of algorithms
for providing particular functions, to save typing out long lists of
identifiers which must be kept consistent.

For example, there are now two implementations of SRFI 1: the Shivers
implementation, optimized for speed, and the Shinn implementation,
optimized for code space.  An implementation could check the optimizing
declarations to figure out which is wanted, or leave it up to the user.
In any case, the SRFI 1 procedures could be listed in an interface,
and both libraries could specify `(interface (srfi 1))`.  Adding new
identifiers to the interface that aren't supported in either library
would cause it to break.

-- 
First known example of political correctness:   John Cowan
After Nurhachi had united all the other         http://www.ccil.org/~cowan
Jurchen tribes under the leadership of the      cowan@x
Manchus, his successor Abahai (1592-1643)
issued an order that the name Jurchen should       --S. Robert Ramsey,
be banned, and from then on, they were all           The Languages of China
to be called Manchus.

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