From: "Aaron W. Hsu" <[email protected]> Subject: Re: [r6rs-discuss] Import choices: flexibility vs. discoverability Date: Wed, 14 Oct 2009 00:34:15 -0400
> I have thought about this problem a little more, because I believe this is > going to be a very important issue to Scheme. [...] > > > <http://my.opera.com/arcfide/blog/2009/10/14/a-philosophy-on-scheme-modules> Thanks for the writeup. This clearified my thought a lot. I agree that the confusion came from that we are conflating different concepts in module primitives. I've been asking if John's proposed module system can support static discoverability, but I myself is not an advocate of it. Gauche's module system is a lot closer than "syntactic" or "dynamic" construct as in Aaron's proposal. Yet Gauche has some support to ensure that my packaged application include everything it needs, so that it runs on the client machine without stopping to say "can't find module xxx" or "unbound variable". So I think it may be a datapoint to show that dynamism can coexist with "industrial" use case. * Gauche's module forms (import, export, define-module etc.) exist in the same layer of macros; macros can generate those forms. * Module forms merely control visibility of identifiers. It does not load any extra code. An import form raises an error if the named module does not already exist on memory. * A primitive to load necessary code is an orthogonal primitive, the good old 'require'. Gauche also has a higher-level construct 'use', which is a macro expands into require + import and I find it handy. But fundamentally, control of namespaces and loading necessary files are different concepts. * Dependency checking is done in a test procedure, which compiles a module, then traces all the code paths (not executing; just visiting) to check if all global identifiers can be resolved; since macro expansion is done by then, imports are taken into account. (If you want to do hairy eval tricks that confuse this check process, you can explicitly tell to the test procedure to exclude checking on certain identifiers). I don't insist this model is universal. I've been feeling it somewhat ad-hoc, and I'd like to hop on to any better model when it comes across. But my experience suggests a couple of ideas. * Namespace control and source code dependency don't need to be coupled; we can leave the latter outside of the core language (e.g. meta language, or an extra macro layer as suggested by Aaron), built on top of imports and includes. * Certain quasi-static check can be done even with allowing imports to be generated by macros. --shiro _______________________________________________ r6rs-discuss mailing list [email protected] http://lists.r6rs.org/cgi-bin/mailman/listinfo/r6rs-discuss
