This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: Applet and Servlet Compile Options
On 03/02/2013 07:21 AM, Matthieu Vachon wrote:
Hi Per,
I started to work on the `applet:` and `servlet:` module compile
options. It is a bit harder than what I was thinking.
The problem comes from the moment at which `module-compile-options`
are parsed. Indeed, just before parsing, `Compilation` will push the
module being compiled with `pushNewModule`. In this code, we check if
we are generating an applet or a servlet and then, we set the flag
`SUPERTYPE_SPECIFIED` on the module.
Hm. There are indeed a a couple of different solutions, none
strikingly appealing.
The most obvious is to replace the checks for SUPERTYPE_SPECIFIED
to also check for applet and servlet. Probably by using a method
like isSupertypeSpecified.
Cleaner would be to defer the check in pushNewModule to when we
actually need it. The simplest is just move it from pushNewModule
to Translator#finishModule. There is a good chance that would
work, but it needs some testing.
More generally:
Kawa Scheme has an implicit (i.e. under-documented) concept of the
module header. Certain forms, including module-extends and module-name,
should only be specified in the module header. How far the
module header extends is vague, but it certainly does not extend
beyond the first require or import. Consider module-name - this
needs to be set before require/import, in case of a group of
modules that recursively require each (which Kawa supports).
Perhaps we need to formalize this. Maybe Translator needs a
new method named commitModule or finishModuleHeader. This
would set SUPERTYPE_SPECIFIED if applet or servet is requested.
It would also set a flag that the module header is done, perhaps
ModuleExp#HEADER_FINISHED. Then for example module-name would
report an error if HEADER_FINISHED is set. Likewise some
of the module-compile-option would only be allowed in the header.
Right now, if you compile a module like:
(require whatever)
(module-name bar)
You get a rather uninformative error message:
/tmp/foo.scm:2:1: duplicate module-name: old name: foo
If we have a HEADER_FINISHED flag we could do better - e.g.:
/tmp/foo.scm:2:1: module-name must be set in module header
--
--Per Bothner
per@bothner.com http://per.bothner.com/