[R6RS] proposed library/syntax-case changes

[dyb at cs.indiana.edu]

> I don't understand the
> consequences of this change---what libraries will then be available
> for use with `eval'.

The set of available libraries is necessarily implemention-dependent and
presumably depends on which libraries are actually installed on the target
system.  That isn't a change from the current situation.  The only
difference is whether one has to declare the set of libraries one might
use for eval statically in the library header or whether a program can
load an arbitrary (available) library.

The practical impact for most implementations will be nil or rather, they
will be simpler since they'll have to make fewer checks.

> >   For the many applications that don't use eval, removing the "for eval"
> >   declaration and corresponding restriction does not impact an
> >   implementation's ability to generate self-contained applications. 
>
> But it seems fairly obvious that a self-contained application *will*
> impose restrictions.  Or am I missing something important?

Either way, implementations that allow the creation of self-contained
applications will be able to completely "tree shake" an application that
doesn't use eval and environment down to just the entry points that are
explicitly mentioned, they won't have to include an evaluator, and they
won't have to include support for locating, visiting, and invoking
libraries.

If eval and environment are used tree shaking is difficult and unlikely to
be very successful either way.  If the set of libraries is declared
statically, however, the implementation may be able to "preload" the code
for each declared "eval library" and avoid including support for locating,
visiting, and invoking libraries, but that's about the only likely
savings, and it comes at the cost of bloating the application binary.

The only significant impact, as I see it, is that a user wishing to use a
library will not be able to tell from the library header which libraries
the library's code might load dynamically, but that can be handled by
comment conventions, e.g., by the library developer proclaiming the set of
libraries that might be loaded dynamically, if any.  It could also be
handled in some implementation-dependent way.

Kent