This is the mail archive of the kawa@sourceware.org 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]
Other format: [Raw text]

Re: CL implementation questions


On 03/27/2012 04:33 PM, Charles Turner wrote:
It's mentioned in PrimOps.scm that it should be written in CL, but for
that's not possible yet due to a lack of CL support. Is the correct
approach to build some primitive transformers for CL (as in
prim_syntax.scm) and then rewrite the stuff in PrimOps.scm with them?

No, that's not what I meant.


prim_syntax.scm implements various primitive syntax forms, such as (if ..).
PrimOps.scm implements various built-in *functions*, and it could probably
be re-written in Common Lisp. What is missing is support for type specifiers.
Without type specifiers many things are either less efficient or just
don't work at all.


Common Lisp does have a type specifier syntax. For example:

(define (length (x :: gnu.lists.Sequence))
  (invoke x 'size))

could probably be re-written to:

(defun foo (x)
  ;; Note this is equivalent to: (declare (type gnu.lists.Sequence x))
  (declare (gnu.lists.Sequence x))
  (invoke x 'size))

The problem is that the declare form needs to be implemented first.

There may be other problems implementing Common Lisp primitives using
Common Lisp, but declare a good thing to tackle first.

I don't understand why the %define-syntax&  define-syntax methods are
required, I assume for bootstrapping purposes, but I've yet to see the
forest for the trees (sadly the Makefiles have failed to evince the
process for me).

Yes, it's boot-strapping. %define-syntax is implemented in Java, using kawa/standard/define_syntax.java. The define-syntax form defined in prim_syntax.scm handles some extra complications which are easier to express using Scheme.

Likewise define, define-constant, and define-private are all
implemented using %define, which is kawa/standard/define.scm,
as you can see in Scheme.java.

I plan on adding a new Kawa type for Java arrays to avoid the
getClass().isArray() dance when implementing sequences.

Not sure what you mean. There is a Kawa type for Java arrays: For example java.lang.String[] .

On 03/27/2012 09:30 PM, Jamison Hope wrote:

Uh oh, using Past Me against me! I don't think that that particular message
went to the Kawa list, so I'll repeat my complaint here. The context was
that I was telling Charles about how I was toying with an implementation
of CL's #'length, which is supposed to work on any "sequence". It seems to
me that the natural idea of a sequence for Kawa would be the union of
java.util.List, java.lang.CharSequence, and Java arrays.

Yes, hard to do it efficiently/elegantly, though using Java 7 invokedynamic might help.

Notice the breakdown in symmetry and elegance:

(define-procedure length
method: (lambda (proseq ::java.util.List) ::int (proseq:size))
method: (lambda (proseq ::java.lang.CharSequence) ::int (proseq:length))
method: (lambda (proseq) ::int
(if (*:array? (*:get-class proseq))
(java.lang.reflect.Array:get-length proseq)
(error length "Cannot get length:" proseq))))

It would be reasonable to add a Kawa type-specifier for a generic Java array. Perhaps java-array:

(define-procedure length
 method: (lambda (proseq ::java.util.List) ::int (proseq:size))
 method: (lambda (proseq ::java.lang.CharSequence) ::int (proseq:length))
 method: (lambda (proseq :: java-array) ::int
               (java.lang.reflect.Array:get-length proseq)))

Perhaps also make that a pseudo-generic, so that
java-array[T] is equivalent to the old T[] syntax.

I've started implementing patterns for Kawa.  Part of patterns
would be support for a guard expression.  For example maybe:

(lambda (proseq #!guard (*:array? (*:get-class proseq)) ::int ...)

The guard expression would be evaluated during the matching phase,
so if it fails another alternative could be tried.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/


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