[Prev][Next][Index][Thread]

Re: Dylan & MOP



Ashley Yakeley wrote:

> > Do I need to defend the utility of a MOP in Dylan?
> 
> Yes. Dylan has the very useful property that it can always calculate type
> relations. I'm not sure you can guarantee this with any useful kind of
> MOP...

Good point and exactly the kind of argument I'm looking for ;-) MOP-like
capability is cool, but extending it too far breaks one or more of
Dylan's fundamental properties, better to leave Dylan alone.

> > I think you should be able to find classes and generic functions by
> > name.
> 
> Classes and generic functions are merely objects. What you are asking for
> is a special case of getting the value of a binding by name.

Yes.

> This sort of 'eval' type thing is a bad idea for Dylan, in my opinion. It
> would mean, for instance, that the compiler could not compile away the
> names of bindings.

I yield on this point. The appropriate way to get this functionality in
Dylan is to create a registry of the classes in question. The
appropriate way to make it easy and mostly automatic is to use macros.

While it would be nice to just have the functionality available, the
runtime cost is high enough to be "un-Dylan-like". After all, if I want
a SLOW dynamic language, I know plenty of places to find one ;-)

> > You can create a generic function, add and remove methods, and apply the
> > function. Such a function is by nature anonymous, there is no way to
> > bind it to a module-level name and call it by that name, nor is there
> > apparently any way to "fake up" that kind of behavior.
> 
> What's wrong with
> 
>   define constant myfunction = make(<generic>, required: 3);

It's not runtime. You have to anticipate in advance how many you will
need and what the names will be. As discussed elsewhere, I've been
convinced the correct Dylan design is code generation instead of runtime
adaptation.

My sneaking back-of-the-mind suspicion was right, the design I was
playing with was not appropriate for Dylan. This discussion has been
very valuable for me, helping me sort out in my mind Dylan's unique
compromise of static and dynamic techniques. Although my initial design
was no good for Dylan, I'm not really disappointed. The alternatives are
not bad.

Certainly if anyone wants to continue this discussion feel free. But I
think all my questions have been answered clearly now, so please don't
spend time on my behalf.



References: