chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-users] syntax-case modules questions


From: Graham Fawcett
Subject: Re: [Chicken-users] syntax-case modules questions
Date: Fri, 25 May 2007 11:28:38 -0400

On 5/25/07, felix winkelmann <address@hidden> wrote:
Modules to be "import"ed by client code should always be
available in source code form: the source code is processed
by the syntax-case macro expander and binding information
(of normal variables and macros) is recorded. So to create
an extension, install both the compiled .so and the source files.

Conceivably, a different module-system could be designed that did this
processing at compilation time? Perhaps library source would need to
be available at application-compilation time, or perhaps the library
source could be distilled into an export-directive that contains the
details required by the importer (including syntax definitions)?

BTW, on a related note, I would love to have an optional,
"categorical" namespace through which I could access an extension's
definitions, without any concerns of shadowing. E.g.

#;1> (use definition-catalogue)  ; a theoretical extension
#;2> (use url)
#;3> url-decode
#<procedure (url-decode str124)>
#;4> (set! url-decode #f)
#;5> url-decode
#f
#;6> (as-defined-in 'url 'url-decode)
#<procedure (url-decode str124)>

...where definition-catalogue's hooks would note the import of (url)
and identify any toplevel definitions. The (as-defined-in) procedure
performs the lookup of the final definition of 'url-decode that
occurred during the extension-load phase.

Possibly something like the (oblist) egg could be used to note changes
in the toplevel environment caused by the require-extension call, or
possibly a formal export-list might be required. (Or a do-not-export
list, in the case of volatile definitions that should never be
catalogued.)

I'm concerned, for example, that more than one egg defines a 'format'
procedure, as does the standard library. My app might depend on the
standard (format) as well as on your egg; but if you modify your egg
to depend on 'format-modular', for example, then my app might break.
I'd like to be able to say (as-defined-in 'extras 'format) and know
for sure what I'm getting, regardless of import-order and other
side-effects. (I'm sure I'd choose a nicer syntax, but the point
stands.)

Having something like this might eliminate the need for library source
to be available in order to make a module system work correctly.
(Still not sure how to handle syntax, though.)

Thoughts?

G




reply via email to

[Prev in Thread] Current Thread [Next in Thread]