This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: Compilation options
- From: Per Bothner <per at bothner dot com>
- To: dominique dot boucher at nuecho dot com
- Cc: "'Kawa List'" <kawa at sources dot redhat dot com>
- Date: Mon, 16 Feb 2004 14:42:21 -0800
- Subject: Re: Compilation options
- References: <001501c3f4d4$ae9573a0$8881a8c0@Forman>
Dominique Boucher wrote:
For almost all source files, we don't need the --full-tailcalls option.
I would like to work on optimizing the --full-tailcalls API (and support
call/cc and better method overloading), though it will be hard to get it
as fast as --no-full-tailcalls api.
But for a few, we do. Ideally, we would like to specify the option using
the module-compile-options clause. Is it possible? Would it require a
lot of work?
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.
We can of course kludge/special-case --full-tailcalls, but I'd like
to do it cleanly and in a way that makes sense for other flags (such
as the not-yet-supported --cps flag).
If it's not hard to do, I volunteer to do it. I definitely need that
feature.
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.
--
--Per Bothner
per@bothner.com http://per.bothner.com/