This is the mail archive of the kawa@sourceware.cygnus.com 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]

Re: IMHOs...


Marco Vezzoli <marco.vezzoli@st.com> writes:

> Problems.
> -Kawa is a rather big system and I can't figure how to deploy kawa
> applets without having to send all the classes; i.e. I don't understand
> fully the package dependencies and how to send the smallest possible jar
> to the client (a sort of kawa runtime environment).

That is a problem.  It is one reason I didn't see applets as a major
priority.

Of course is only big in the context of applets that somebody downloads
and runs in their browser each time they want to use it.  In terms of
disk space it is not big (except for some really tiny computers).  So
one approach is to have people download the kawa jar file, and save it
in their browser's class path.

> I think that --due to the dynamic nature of scheme-- is very difficoult
> to understand if a class will be used from the source code; the worst
> case is when I pass an arbitrary string to 'eval'.

Basically, if you use eval, I don't think there is much sense in
trying to split things up.  I think it makes sense to split
kawa-compiled.jar into a "kawa-rte" part and a "kawa-dk" part.

Run-time:
        gnu.math
        gnu.mapping
        gnu.text
        gnu.kawa.util
        kawa
        kawa.lib
        kawa.standard

Compiler:
        gnu.bytecode
        gnu.expr
        kawa.lang
        gnu.kawa.reflect

There are some bad dependencies.  Some of these I consider bugs.  However,
this should not matter, as long as an application does not call any
method that needs a "compiler" class.  E.g. gnu.math.IntNum references
classes in gnu..bytecode and gnu.expr - but these are only loaded if
the method emit or makeliteral are called - and they are only called
if you use the compiler in gnu.expr, so it should be OK.

Some find tuning and experimentation of this division will probably be
needed, but if you want to experiement, I'm here to answer your
questions.

> -I need some more support for modules in order to manage the namespace;
> I found some interesting approach using macros e.g in guile, but I think
> that a closer java-package approach --like the choice for OO in kawa--
> can be more useful.

Working on it right now.  It *may* (if I get it working well enough)
appear in the next snapshot.

The idea is that each Scheme "module" (source file, usually) is compiled
to a Java class.  The non-private top-level definitions are compiled
to public fields.  (A top-level procedure has both one or more methods
plus a ModuleMethod field.)  This part is basically working.
There can be multiple instances of a module, by making the fields
be non-static.

To "import" a module you add the definitions exported by a class
to the definitions currently visible.  By default, these imported
definitions are not re-exported - in fact they are only visible
at compile-time.  This is the part I'm currently working on.
The tricky part is that I also want this to be efficient - for a
procedure, importing module should generate code that directly
calls the method in the exporing module, when possible.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/

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