On Mar 28, 4:22 am, Michael Wood <esiot...@gmail.com> wrote:
> On Thu, Mar 26, 2009 at 12:49 PM, Marko Kocić <marko.ko...@gmail.com> wrote:
>
> > On 25 мар, 21:41, mikel <mev...@mac.com> wrote:
> >> Tinyclos is decent, and lots of people have made good use of it. For
> >> example, it's a "standard" extension to Chicken Scheme (insofar as
> >> anything to do with Chicken Scheme can be called "standard") and has
> >> lots of enhancements provided by Felix.
>
> > I'll take a look at it. Haven't heard of if before.
>
> [...]
>
> I just saw this on Planet Lisp:
>
> http://www.foldr.org/~michaelw/log/programming/lisp/closhttp://www.foldr.org/~michaelw/projects/jclos/
>
> It's a port of Tiny-CLOS to Java by Michael Weber.
Note that just porting Tinyclos might not give you what you're looking
for. You probably want to do some work on figuring out how to
integrate Clojure's various types. Scheme's system of types is simple
enough that it's not hard to fit CLOS to it. In the case of Common
Lisp it's a lot more work, but the work's already been done for you,
if you use any standard implementation of Common Lisp with a standard
CLOS in it.
The work to integrate Clojure is probably more akin to the work to
integrate Common Lisp, and it hasn't been done yet. In order to
compute slots and applicable methods, you need class precedence lists
for all possible values. That means you need a function that returns a
class for any input value. The clojure function named "class" doesn't
do the right thing, because the information it gives you for some
values is not correct; for example, if the input is an object with a
type tag in its metadata, the output of class is irrelevant. The
function named "type" doesn't work either, because it's possible to
construct perfectly good Clojure values for which that function is
undefined.
So, at minimum, to make a solid port, you need to add a function that
can return a sensible type value for any input, and you need to devise
a means of constructing some way of traversing any arbitrary set of
types to deterministically obtain a class-precedence list for it, so
that you can resolve dispatch. This can be done: doing it for Common
Lisp was no less troublesome than doing it for Clojure would be; but
it was significant work to do it, and you should expect that it would
be significant work to do it for Clojure, too.
And you should expect, as the designers of CLOS did, that not everyone
will be happy with your algorithm for constructing class-precedence
lists. Fortunately, the entire point of building CLOS on a MOP, as in
Tinyclos, is that anyone who doesn't like your solution has the tools
to make his own.
As an aside, Dylan was an example of a brand new Lisp that was
designed from the start to be built on CLOS. Dylan's fundamental model
of types was CLOS; every value (including classes and methods) was an
instance of a CLOS class. Of course, once the language was built, it
wasn't called "CLOS" anymore, because it wasn't Common Lisp. Nowadays
it doesn't look as much like a Lisp anymore, since s-expression syntax
was abandoned. It did contribute at least one thing of potential
relevance, though, for anyone considering implementing a CLOS-like
object system: the C3 class-linearization algorithm. Given any set of
classes, C3 gives you either a single, reliable ordering, or a clear
error that is capable of telling you what you need to fix.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To post to this group, send email to clojure@googlegroups.com
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
