This is the mail archive of the kawa@sources.redhat.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: A few questions


Stig Erik Sandoe <stig@ii.uib.no> writes:

> I have not looked closely at the internals yet, but I think I need
> Java-compatible classes, but I am unsure how much work this will be,
> do you have an educated estimate? :-)

Of what?  First we need a design of the Scheme interface and how
that should map to Java.

One variant is that we only add a "run" method when neither module-extends,
module-implements, and module-static are specified.  A possible
refinement is to add an implicit "run" if the module implements Runnable,
and no run method is specified.  (The idea is that modules by default
implement Runnable.  Currently that is only if they don't extend
MdouleBody, because the run method has the wrong return type, but
that should be fixed.)

> I am not too familiar with GOOPS, but I know Tiny-CLOS and CLOS.  Do
> you know when you plan to add GOOPS

When I get time or I get suitable patches.

> and what extra support
> is needed in Kawa to support it?  It seems to have some constructs
> like procedure->memoizing-macro, procedure->macro which I don't know
> whether is in Kawa.

Urg, no.  The initial step is to implement CLOS-style multiple inheritance
*classes*, without methods, along the lines of
        http://www.bothner.com/~per/papers/jaoo99.html

Kawa does have some support for generic functions and multi-argument
dispatch, but it has limited usefulness as is.  The framework does
need some work.

It is also desirable to implement Java-style single dispatch, for
efficiency.  This requires a restriction that a method that takes
a first argument <T> must be defined in the same compilation unit
as <T>.  In that case Kawa can just compile that as a regular
virtual method.  This optimization needs be indicated using some
suitable syntax, such as define-virtual-generic, as opposed to
the "generic" define-generic.

> True, but expressing interfaces as lists which are easily generated
> by lispy languages is for me preferable to writing it in java.  But
> I can probably piece something together.

It would be nice if that was am implementation of define-class,
extended to handle methods as well as fields.

> I guess it is an old habit and when writing macros and use them it
> might be nice to see that the correct code is generated.  I am not
> sure how this is usually done in Scheme.

I've discussed this issue in private.  Matthias Radestock suggested:
        (define t (make <kawa.lang.Translator>))
        (invoke t 'rewrite '(some-expr))
You can probably do a better CommonLisp-style macroexpand-1
using the expand method in Macro.
-- 
	--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]