compiler update, questions

"Yury Sulsky" <[email protected]> Sat, 29 Apr 2006 15:23:08 -0400
Newsgroups gmane.lisp.lush.devel
Message-ID <[email protected]>
Hi again,

I'd like to add classes to the compiler, but I'm not sure which way to
go. I could do what Lush does now (in which case, maybe I can just use
C++ classes?), but wouldn't it be nicer to have a prototype based
object system? That is, instead of using a vtable based method lookup,
the methods would simply be fields in the class that point to
closures.

The nice things about this are: 1) it's really easy to implement, and
2) you can redefine methods after object creation. Of course, the down
side is that it adds some memory overhead to every object.

We could also do both, but I'm not sure what the point of that would be.

Kind of orthogonal to this, I've split up the object type into
object/struct types. The struct type is a no-frills mapping of a C
struct, while the object type is a subclass of "object", which would
contain a hash map of slot name -> field address. This also allows
random fields to be added to any object at runtime.

Oh also while we're on the topic of incompatible changes to Lush, how
about changing the reader to take a:b => (scope a b) instead of :a:b?
This allows taking :a:b to mean slot b of global a, and also it's much
easier to type. We'd need to make the reader either take white space
into account or else just change the global scope operator to
something else, like "::".

Also (especially if you agree with using a prototype-based object
system), how about changing method calls from (==> obj foo) to
(obj:foo)? It'd make nested calls much easier to write:
  (((obj:foo):bar):baz) instead of (==> (==> (==> obj foo) bar) baz)


Yury
blah3.lsh (application/octet-stream, 59.2 KB) - not displayed