Lynn Winebarger
2009-04-06 17:01:25 UTC
Hello,
Is there any ready mechanism for dynamically generating the export
list of a library form from the expansion of the library form itself?
I am thinking along the lines of an internal (export <export-spec>
...) form. AFAIK, no such mechanism is supported now. It doesn't
seem like it would be that difficult to support. Would such an added
feature be acceptable to the larceny developers? Any pitfalls?
This is not an idle question. I'm writing some data-structuring
support macros that allow the user (me) to reference fields of a
record in a variable in a "C" like fashion [*]. The basic mechanisms
from the user's point of view are the data-structure definition form
(an elaborated record type definition) and a "declare" form that
causes the implicit bindings to be defined in a particular form.
My design is to generate some intermediate syntax which the user
shouldn't need to know. For example (define-data-structure ds <blah>
...) defines ds-spec (used for inheritance and declaring the structure
of fields) and declare/ds (macro-tail-called by the declare form).
The person using the defined data structure only needs to know about
"declare", not "declare/ds".
The advantage of doing this and not some internal hash table of
definitions is that the Scheme implementation will properly
disambiguate the names in the appropriate lexical context.
The disadvantage is that the user writing the definition of the data
structure has to explicitly export this support machinery. The data
structure definition should be able to (optionally) do this under the
table.
I've considered the possibility of macro-generating the library form
by walking through the code and gathering some internal "export"
forms, but the library has to actually be expanded based on imported
libraries in order for the internally exported definitions to exist.
This makes a solution that is not integrated into the library
mechanism unpleasant at best. For example, reading the library then
generating a temporary file containing the real library form
(unexpanded) with the correct export list. Yuck.
Thanks,
Lynn
[*] Am I the only Schemer who wants this facility? I'm not a fan of
destructuring/binding by pattern matching - it's too redundant for my
taste.
Is there any ready mechanism for dynamically generating the export
list of a library form from the expansion of the library form itself?
I am thinking along the lines of an internal (export <export-spec>
...) form. AFAIK, no such mechanism is supported now. It doesn't
seem like it would be that difficult to support. Would such an added
feature be acceptable to the larceny developers? Any pitfalls?
This is not an idle question. I'm writing some data-structuring
support macros that allow the user (me) to reference fields of a
record in a variable in a "C" like fashion [*]. The basic mechanisms
from the user's point of view are the data-structure definition form
(an elaborated record type definition) and a "declare" form that
causes the implicit bindings to be defined in a particular form.
My design is to generate some intermediate syntax which the user
shouldn't need to know. For example (define-data-structure ds <blah>
...) defines ds-spec (used for inheritance and declaring the structure
of fields) and declare/ds (macro-tail-called by the declare form).
The person using the defined data structure only needs to know about
"declare", not "declare/ds".
The advantage of doing this and not some internal hash table of
definitions is that the Scheme implementation will properly
disambiguate the names in the appropriate lexical context.
The disadvantage is that the user writing the definition of the data
structure has to explicitly export this support machinery. The data
structure definition should be able to (optionally) do this under the
table.
I've considered the possibility of macro-generating the library form
by walking through the code and gathering some internal "export"
forms, but the library has to actually be expanded based on imported
libraries in order for the internally exported definitions to exist.
This makes a solution that is not integrated into the library
mechanism unpleasant at best. For example, reading the library then
generating a temporary file containing the real library form
(unexpanded) with the correct export list. Yuck.
Thanks,
Lynn
[*] Am I the only Schemer who wants this facility? I'm not a fan of
destructuring/binding by pattern matching - it's too redundant for my
taste.