On 10 May 2002, Rolf-Thomas Happe wrote:
> S48 structures are second class. FOO isn't a Scheme variable
> denoting a structure, and I don't think there are package (or
> environment) ids that you could pass to EVAL.
I didn't find any documentation that spells out the relationship
between eval and the module system. I think you are correct that S48
structures are second class. On the other hand, it seems like the
packages behind the structures are first class. At least to the extent
that they can be exposed with interaction-environment, and then you
can pass them to eval (see rts/env.scm and rts/eval.scm).
I don't know if these details were intended to be exposed to the user
or not, but they open the possibility of defining almost any custom
environment for eval. As far as I can tell, the only exceptions are
that you can't avoid two annoying initial bindings: an import of
interaction-environment, and an export of the package itself. Both
will be visible to any evaluation you do in your package. [They could
be hidden behind obscure names, blown away with set! after obtaining
the package, combined in a data structure, or other tricks, but I
think these ideas just provide more evidence that my method is a
hack.]
> You can have the Scheme system evaluate program text in a package
> FOO interactively... or spell out things in a structure definition
> ... but if you really want to construct and EVAL Scheme data, I
> don't know anything better than you came up with yourself. (Someone
> else may, of course.)
Thank you for the suggestions. In this case, I was playing with the
syntax-case source code, so I really needed eval.
<lament> It is too bad that nobody has found the time to create a
detailed roadmap of the scsh/scheme48 implementation. The scheme48,
prescheme, and module papers are tantilizing (especially prescheme),
but they lack detail. It seems like scrutinizing the source code is
the only way to really understand these systems (no easy
task).</lament>
-Tony Carrico
|