This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: invoke-static
Daniel Bonniot wrote:
I thought it could actually be healthy to makr more clearly a barrier
between Kawa-the-multilanguage platform, and the different languages
that are built on it. Would it be a reasonable goal that everything
under the 'gnu' toplevel package would be language independant, while
things under 'kawa' would be language dependant?
Arguably everything should be under the "gnu" "top-level" package.
GNMU Java code should in general use a "gnu" package.
At the moment, there are both gnu.kawa and kawa packages. Is there a
transition between the two? There are also gnu.jemacs, gnu.brl packages,
..., that definitely don't belong to the "core".
There is another dimension: "run-time" vs "compile-time" packages. For
a language that supports eval you can of course compile things at
run-time, but I would like to make it possible to "deploy" a package
in a Kawa langauge without including gnu.expr for example. That is
the distinction between gnu.kawa.functions are run-time utilities,
while gnu.kawa.lispexpr are compile-time utilities.
Thus compile-time classes can depend on run-time classes, but not vice
versa.
Language-independent run-time classes include those in: gnu.math,
gnu.lists, gnu.xml, gnu.text. (Some of gnu.text is geared to
lexing/parsing, but that is also useful at run-time.)
Language-independent compile-time classes include: gnu.bytecode,
and gnu.expr.
Somewhat language-dependent compile-time classes include those in
gnu.kawa.lispexpr and kawa.lang; most of the latter should be
moved, perhaps to the former.
There is some bleeding with Type and its descendents, since we
may have run-time type-checking. Also, Interpreter should probably
be split up into compile-time and run-time features.
Another solution would be to have a clear stratification of packages
dependancies, with a list of 'core' packages that don't depend on the
outside. In that case, it could make sense to move the core to a
different CVS repository. That would help advertise the core as a code
generation package, easily reusable to implement different languages.
Is that too big of a step at this point? How far are we from making this
separation possible?
I don't know. I'm realy heavily booked at this point.
It's a hard problem. I'm trying at least to make the
package inter-dependencies fewer rather than more.
--
--Per Bothner
per@bothner.com http://per.bothner.com/