[Prev][Next][Index][Thread]
RE: MI: why?
> -----Original Message-----
> From: Lawrence G. Mayka [mailto:mayka@lucent.com]
> Sent: Friday, January 14, 2000 9:00 AM
> To: info-dylan@ai.mit.edu
> Subject: Re: MI: why?
>
>
> Eric Clayberg wrote:
>
> Second, my understanding of typical Smalltalk MI implementations is that
> they refrain from modifying the virtual machine and language design.
> This is, in essence, what you are saying too. The resulting MI would, I
> expect, have neither the functionality nor the performance required for
> a commercially viable MI product. MI in Dylan was built in from the
> start. MI in CLOS was originally a library which had almost full
> functionality (due to Lisp's high evolvability) but lacked performance,
> for which absorption into commercial kernels was necessary.
It is quite possible in Smalltalk to create sub-languages that live
reasonably well with the rest of the Smalltalk libraries and VM -- in effect
meta-object programming. This has been used to integrate some odd and
interesting sub-languages (such as logic programming languages) without
messing up the rest of Smalltalk. Smalltalk shares this advantage with
Lisp.
If I remember correctly (and it has been some time) one way of implementing
MI in Smalltalk is to create appropriate links to byte code in a class, in
effect doing the equivalent of the code duplication without the programmer's
intervention (and without actually duplicating the code itself.) With this
method there should be little performance hit or need to change the virtual
machine.
I will say that I do not count MI as being one of Dylan's greatest
contributions. I do consider multi-methods as being a far greater asset.
Multi-method dispatch does simplify the implementation of several very
important design patterns.
References: