Re: where to "put" a unification algorithm...

On 2/16/07, Roel Wuyts <Roel.Wuyts@xxxxxxxxx> wrote:
> You can put it there, yes.
>
> But there is an important design question lurking there. If you put
> the unification method on these classes, what you are really saying
> is: this Smalltalk object can be unified with that Smalltalk object.
> So you are then extending the Smalltalk language with unification.

That's exactly right

> The alternative is to only have unification methods un your own
> 'unifiable objects' hierarchy. In that hierarchy you will probably
> have a class called: CWNumber, which represents numbers in your
> language and which will hold a Smalltalk number.
>
> Which alternative to choose depends on whether, and how deep, you
> want to integrate Smalltalk and your own language. Unless you really
> want to mingle Smalltalk objects within your language, or want
> unification directly accessible at the Smalltalk level without having
> to pass through your language, I would advise the second option.

I understand. If I did choose the second option (make my own classes -
CWNumber, CWString, CSList etc), would I then have to use a tool like
SmaCC to construct instances. The advantage of extending the existing
classes ("extending the language") seems to me that no parsing /
compiling is required to make

5 unifiesWith: 5 in: emptyEnv

work.

I would be very interested in your work on this subject.

Thanks again for the help.

--
A/Prof Chris Wright FJFICM FRACP MBBS
Medical Director, ICU
Monash Medical Centre
Clayton, VIC