On Tue, Jan 01, 2013 at 01:53:03PM -0500, John Cowan wrote:
> Peter Bex scripsit:
>
> > I suppose the confusion here is due to the fact that there are two
> > separate types of BEGIN.  One is part of the library language, which
> > consists of only import, export, begin and include (modulo a few
> > others), and one as part of the Scheme language.
>
> Three, in fact; there are already two types of `begin` that are
> part of the Scheme language, which we may call "expression `begin`"
> and "declaration `begin`".

Thanks for the correction.  This is interesting.  I had forgotten
about the different contexts begin can occur in.  However, this is still
a single identifier, which somehow reduces to two underlying core forms,
or simply gets treated as two different things.  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.

> I have added cross-references between sections 4.2.3 and 5.6.1 to draft 9.

Thanks, that'll be helpful.

> > It's important to remember that they're really two separate languages
> > that happen to be covered by the same specification because one is
> > designed as a "container" for the other.  That they both use BEGIN may
> > be confusing.  More confusing is that you can rename one to something
> > completely different.  The other can't be renamed at all, AFAIK.
>
> That is correct.  The library language has no capacity to define new
> library declarations, though new ones may be added to the large language.
> I have in mind the following (these are just my ideas, not anything that
> WG2 has blessed): speed, space, safety, compilation-speed, debuggability,
> reexport, inline, notinline, unused, undefined, verbose, terse, silent.

I'm unsure such things are very generally useful.  You don't want to make
too many assumptions about the capabilities of compilers/interpreters.
These particular types of optimizations are very tightly linked to the
way an implementation works internally.  There might be optimizations
that make no sense for a given implementation and even optimizations
that aren't in your list (Chicken's "exact" type checking comes to mind).

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.  OTOH, maybe SRFI-0 feature specifications are
enough already to conditionalize extensions to the library forms for
controlling optimizations and other compiler hints?

> In addition, I have proposed a new type of import-set, `drop-prefix`,
> which specifies a prefix to be removed from all names which start with it:
> Chibi already supports this.

I think these are quite useful, and it's good to hear such things are
being added to Chibi already.

> I have also added two sub-proposals for trivial pattern-matching macros
> in the library language, like syntax-rules but with no hygiene issues,
> and for named interfaces (groups of names to export simultaneously).

I think pattern-matching shouldn't be added.  Remember, one of the main
reasons is that library forms should be statically compilable.  These
forms should stay as simple as possible in order to be easily rewritten
to an underlying implementation's "native" module system.  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.

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.

Cheers,
Peter
--
http://sjamaan.ath.cx

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