dyb at cs.indiana.edu
Sun Dec 11 14:59:58 EST 2005
> (library <lpath> <lang> (<impexp-form>*) <body>)
Perhaps this is what you meant to imply, but I think we need to go
further and make the syntax of <impexp-form> fixed, i.e., independent
of <lang>, so that people can use sed (or a similar text-based tool)
reliably to extract the imports and exports of a library. One cannot do
so if the syntax of the import and export forms can change based on the
specified language. The decision to restrict where import and export
forms can appear was primarily motivated by the desire of some among us
to be able to use sed, along with the related notion that human readers
should be able to spot import and export forms easily, without someone's
import and export abstractions getting in the way.
To be clear, I still prefer Scheme to sed (even when called from make
files), don't mind if my tools have to macro-expand the code to determine
imports and exports, and believe that abstraction leads to more rather
than less readable code. I also believe that "removing the weaknesses
and restrictions that make additional features appear necessary"
is a good idea. So I would strongly prefer that we treat import and
export forms as definitions, allow them to be interspersed amongst the
definitions at the top of a library, and allow them to be redefined if
someone so desires. I'd also strongly prefer for import forms to be
allowed wherever other definitions are allowed. I've mentioned before
the many benefits of lifting these restrictions and will not beat that
dead horse further at this point.
If we're not going to lift the restriction on placement of import
and export forms, however, we at least ought to tie the import/export
syntax down completely so that the people who prefer to use sed and
disallow abstraction get what they want. Otherwise, there's no point
in restricting where the forms can appear, and the library system won't
suit anyone's desires.
More information about the R6RS