In these two languages we have two very different ideas of what MOP's
should be. In Lisp we have a very heavy definition of MOP which lots
of structure, in Smalltalk we have the class Class and associated
classes, which form a very lightweight system with little structure.
The result is that a Lisp MOP gives you a lot of power at the cost
of a steep learning curve. AMOP is one of the toughest reads in CS.
Smalltalk gives you less power but is much easier to learn.
In fact I can't even believe that there is some book necessary to
learn the protocol.
So is the extra cost of the Lisp AMOP worth it?
Thaddeus L Olczyk wrote:
> In these two languages we have two very different ideas of what MOP's
> should be. In Lisp we have a very heavy definition of MOP which lots
> of structure, in Smalltalk we have the class Class and associated
> classes, which form a very lightweight system with little structure.
Yes, and there's very little you can do to change these operations without
substantial performance penalties because so much of the infrastructure is
hardwired into the VM that moving back into the interpreter, usually via a
mNU exception, even with JIT'ing, is prohibitively expensive. With CLOS's
MOP you at least have the opportunity to re-compile the MOP-using ops for
the generic functions involved and have less of a performance hit.
> The result is that a Lisp MOP gives you a lot of power at the cost
> of a steep learning curve. AMOP is one of the toughest reads in CS.
I don't think it's much worse than learning which things you can actually
change in Smalltalk's limited MOP and being disappointed that you can't
do more. It's an issue that most Smalltalk or Lisp users don't usually run
up against, anyway. As far as AMOP being a "tough read", at least the
documentation and code is there. Try to pry very deeply into the Smalltalk
MOP and you find that very soon you'll be shunted off into <primitive: 217>
land and you don't have code for the VM (except in Squeak).
> Smalltalk gives you less power but is much easier to learn.
> In fact I can't even believe that there is some book necessary to
> learn the protocol.
Wow. I can't believe you could be much more flame inciting than this,
Thaddeus. Whay don't you go back and troll on comp.lang.c++ like you used
to...
> So is the extra cost of the Lisp AMOP worth it?
In one word: Yes.
Thaddeus L Olczyk wrote:
>
> The result is that a Lisp MOP gives you a lot of power at the cost
> of a steep learning curve. AMOP is one of the toughest reads in CS.
>
> Smalltalk gives you less power but is much easier to learn.
But isn't that the classic trade-off with almost everything? And anyone
thinking about doing a metaclass is likely someone prepared to hunker
down with the doc to make it happen. The one thing they do /not/ want is
to be stymied in their effort because the MOP designer did not expose
some mechanism.
kenny
clinisys
······@interaccess.com (Thaddeus L Olczyk) writes:
> In these two languages we have two very different ideas of what MOP's
> should be. In Lisp we have a very heavy definition of MOP which lots
> of structure, in Smalltalk we have the class Class and associated
> classes, which form a very lightweight system with little structure.
>
> The result is that a Lisp MOP gives you a lot of power at the cost
> of a steep learning curve. AMOP is one of the toughest reads in CS.
Really? I found it a wonderful read. It's extremely well written,
and it eases you into a smaller MOP in a way that everything feels
natural when you get to it. From the Closette MOP, the full MOP is
easy enough to grasp.
> Smalltalk gives you less power but is much easier to learn.
> In fact I can't even believe that there is some book necessary to
> learn the protocol.
>
> So is the extra cost of the Lisp AMOP worth it?
Yes.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
······@interaccess.com (Thaddeus L Olczyk) wrote (abridged):
> The result is that a Lisp MOP gives you a lot of power at the cost
> of a steep learning curve. AMOP is one of the toughest reads in CS.
The difference in MOPs is also a reflection of the difference in
languages. For example, CLOS has multi-methods and multiple inheritance.
These are more powerful and more difficult whether or not a MOP is
available to fiddle with them.
> So is the extra cost of the Lisp AMOP worth it?
Could you give Lisp a MOP as simple as Smalltalk's without also cutting
down the language? Is the extra cost of multi-methods etc worth it?
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
········@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
"Dave Harris" <········@cix.co.uk> wrote in message
·······························@brangdon.madasafish.com...
> ······@interaccess.com (Thaddeus L Olczyk) wrote (abridged):
> > The result is that a Lisp MOP gives you a lot of power at the cost
> > of a steep learning curve. AMOP is one of the toughest reads in CS.
>
> The difference in MOPs is also a reflection of the difference in
> languages. For example, CLOS has multi-methods and multiple inheritance.
> These are more powerful and more difficult whether or not a MOP is
> available to fiddle with them.
>
>
> > So is the extra cost of the Lisp AMOP worth it?
>
> Could you give Lisp a MOP as simple as Smalltalk's without also cutting
> down the language? Is the extra cost of multi-methods etc worth it?
Yes, multi-methods are definitely worthwhile and make transparent and
efficient FFI possible. The MOP cost is fairly nominal, and the exposed MOP
API does not require existing message-API replacements, only extensions.
SmallScript (as an extended dialect of Smalltalk) handles this through the
introduction of a <MessageSignature> class and corresponding literal form.
Most Smalltalk code does not have type-signatures declared so there is no
impact on those (classic Smalltalk) methods. For methods with
type-signatures and other annotations, you can directly reference using the
extended facilities or the <MessageSignature> litera; which is something
that would be nice if classic Smalltalk had (whether or not multimethods
were present).
""assumes => Class name: Blah.
Method behavior: Blah [
foo: <Integer> x
]
Eval [
"" ##:: is a message signature literal
|mth| := Blah[##::foo:(<Integer>)].
stdout cr << mth asNamespacePath.
].
-- Dave S. [www.smallscript.org]
>
> Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
> ········@cix.co.uk | And close your eyes with holy dread,
> | For he on honey dew hath fed
> http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."
·············@smallscript.com (David Simmons) wrote (abridged):
> > Is the extra cost of multi-methods etc worth it?
>
> Yes [...]
It was a rhetorical question as far as you're concerned :-)
Dave Harris, Nottingham, UK | "Weave a circle round him thrice,
········@cix.co.uk | And close your eyes with holy dread,
| For he on honey dew hath fed
http://www.bhresearch.co.uk/ | And drunk the milk of Paradise."