This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Applet and Servlet Compile Options


So, here I come back with this feature :)

I changed how module header check is implemented. I added a base class
`ModuleHeader` that syntax objects that need to be treated as a module
header extend. Then, in the method `scanForm` of
`kawa.lang.Translator`, I finish module headers if the syntax object
is not an instance of `ModuleHeader`.

The drawback with this approach is that we will call
`finishModuleHeader` multiple times while compiling. The method
`finishModuleHeader` is idempotent so the call when headers are
already finished will only incur the cost of checking if flag
`ModuleExp.HEADER_FINISHED` is set of the module expression. I don't
know if it's an acceptable solution.

The patch doing this is attached in this email, tell me what you think
about it. You can also see it on github
(https://github.com/maoueh/kawa-fork/pull/1/files), where I maintain a
git mirror of kawa svn. The patch is not ready to merge, I need to do
more testing for `servlet:` and `applet:` module compile options.

A more optimal solution in my opinion would be something like this:

 * Module headers are scanned by a custom method derived from
`scanForm` (maybe named `scanModuleHeaderForm`) until first non-module
header syntax is reached.
 * Module headers are finished by calling `finishModuleHeader`.
 * Rest of module is scanned as usual.

So, in this solution, `scanForm` is kind of split in two. One part for
module headers, another one for rest of module. From my current
understanding of the code, it would be possible to do so. However, I
may have missed some stuff that would make this solution impossible.

If you agree that it could work and is a better alternative to
attached patch, I could work on it.

Regards,
Matt

On Wed, Mar 6, 2013 at 8:53 AM, Matthieu Vachon
<matthieu.o.vachon@gmail.com> wrote:
>>
>> One quick buglet - the comment HEADER_FINISHED was copied
>> from USE_DEFINED_CLASS.
>>
>
> Fixed, thanks :)
>
>>
>> For now, call it a the start of finishModule, and the start of
>> require.scanForDefinitions (before checking PROLOG_PARSING).
>>
>
> I changed the implementation to what you specified but it does work
> only if a require clause is used in the scheme source file. If there
> is no `(require ...)`, the error is not reported because
> `finishedModuleHeader` has not been called. I'm unsure what to do from
> here. I don't think adding a call to `finishModuleHeader` in every
> syntax that can be top-level in a module is good since it would incur
> multiple false calls to the method. Do you have suggestions?
>
>> It might be needed to cal it before regular definitions, but
>> probably not.
>
>  Probably indeed. If we can't find a better way to handle
> `finishModuleHeader`, I fear I will need to do it like this.
>
>>
>> Also, make finishModuleHeader idempotent:  I.e. if HEADER_FINISHED
>> is already set, just return.
>>
>
> Done.
>
>> Also, drop the isModuleHeaderSyntax.  Instead, define a method
>> checkInModuleHeader().  This would check HEADER_FINISHED, and if
>> set report an error.  Call this from the various Syntax's scan methods.
>> I think this is more robust/extensible, rather than listing up
>> various syntaxes in isModuleHeaderSyntax/
>>
>
> Done.
>
>>
>> What happens if you compile the servlet with:
>>   --warn-undefined-variable --warn-unknown-member --warn-as-error
>> while the functions define in those two modules?
>>
>
> So this load class call is used for static analysis then, to be sure
> we have the definition in the language for the methods. Is that
> correct?
>
>>
>>> So, I'm not sure what is the purpose of this flag exactly and
>>> how I should integrate it into my patch. Should I check if servlet is
>>> defined in the new `finishHeaderModule` and then load the class in the
>>> Scheme language instance?
>>
>>
>> That may be appropriate.
>>
>
> Will do.
>
>>
>> If you have module_name#scanForm call checkInModuleHeader then
>> you can probably use that to supress the second error - perhaps
>> by having checkInModuleHeader return a boolean.
>>
>
> Done, exactly what I was after :)

Attachment: feature-applet-servlet-options.diff
Description: Binary data


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]