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

[felix winkelmann]

On 5/25/07, Graham Fawcett <address@hidden> wrote:
> 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)?

I'm not quite sure what you mean here: the binding resolution while
importing is already done at compile time (unless you are interpreting
code, of course). Creating a condensed module definition from the source
file might be possible, though, and would probably speed up compile
times somewhat. On the other hand it might not really be worth the trouble.

Ideally, we need a well hackable, understandable module system that
supports syntax-rules and that is static enough to be used with batch
compilation. I haven't found such a thing yet.

> 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.)

Yes, sounds quite interesting: after a load/require you could walk the
symbol table and store all changes to a previously saved set of
globals, but that might include some garbage or gensym'd hidden
globals. Might be helpful for debugging, too...

Anyway, as said in the previous mail: toplevel variables are first class,
so one can do quite a lot of munging in the toplevel namespace.

> 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.)

Understandable. The traditional way to handle this is prefixing each
definition (say "extras:format" and "format-modular:format") which
works quite well (and should probably be used more often).

> 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.)

Syntax is exactly the one detail where everything gets complicated.
This is still a research area.


cheers,
felix