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 tried to make a module that worked as a regular Java class in the
> system, but I found the separation of the constructor and the run()
> method a bit odd. Is this separation needed? 

This is to handle modules that mutually reference each other.
Both modules should get constructed first, then run is run.

> Is it hard to change this or will something probably break?

Probably, but we can probably implement something.  Note a static module
has no run method - the "body" is handled by the class initializer.

There are design issues in how this "should" be done I'm not sure
about.

Part of the problem is that the module feature is used for two
different things:  defining Java-compatible classes with a
predictable and natural encoding, and defining Scheme modules.
This was perhaps not a great idea.

> I could unfortunately not find a good way to define my own
> constructor for such a class, is this planned for the upcoming
> DEFINE-CLASS mentioned in the docs?

Yes.  I want to implement something similar to the module system
used in Guile (I believe called GOOPS), which is based on CLOS.

> Is there a way to define java interfaces currently in Kawa?

No.  It has limited usefulness, since you can't associate any
actions with an interface.

The planned define-class will work by generating both an interface
and a (hidden implementation) class.  (There will be an option to
generate a class, but the default will be to generate an interface.)

> I've noticed DEFMACRO in the docs and have seen that it is a wrapper
> for DEFINE-SYNTAX.  Coming from Common Lisp I feel that I want a
> MACRO-EXPAND, is there a MACRO-EXPAND or similar for
> DEFMACRO/SYNTAX-RULES?

Why do you want it?  It is not clear that macro-expand makes sense for
syntax-rules, since the result would contain re-named identifiers
that only make sense in context.  For defmacro, as well as CommonLisp
(and Emacs Lisp) macro-expand is reasonable, and will probably be
added.
-- 
	--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]