RE: Compilation options

["Dominique Boucher" <dominique dot boucher at nuecho dot com>]

Per,
 
> It would be a reasonable thing to do to integrate --full-tailcalls
> (as well as --no-inline) into the module-compile-options framework.
> It's a little tricky, because --full-tailcalls actually sets the "enum
> variable" defaultCallConvention, and the module-compile-options
> framework so far only really supports booleans.

Of course.

> The ideal would be to extend Options.java so it understand
> (1) enum flags (in some manner, ideal compatible with the
>      JDK 1.5 enum conventions).
> (2) options that are aliases for enum options.
> 
> So you could do:
>    --call-convention "full-tailcalls"
> or:
>    (module-compile-options call-convention: 'full-tailcalls)
> or:
>    (module-compile-options full-tailcalls: #t)
> 
> Alternatively, we can get rid of the defaultCallConvention
> "enum" variable, and define a set of boolean options.

The last option would certainly be the easiest one. But as I review the
code, the different calling conventions form a partial ordering, and
this ordering is used in the code. Enum-like constructs are certainly
worth considering. I'll see what I can do.

But all this also raises an important question. Can different calling
conventions be used for different expressions in the same module?
Suppose one writes:

(module-compile-options call-convention: 'full-tailcalls)

(define (f x)
  (with-compile-options call-convention: 'cps
     (g x)))

(define (g y)
   ...)

Dominique