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