where to "put" a unification algorithm...

> I would like to play around with some classes which require
> unification (I know about Prolog/V etc...). I am not sure where to
> "put" the unification algorithm.
>
> It might look like:
>
> anObject unifiesWith: anotherObject in: anEnvironment
>
> ? does that seem like the right sort of selector?
>
> So, to I put that in Number, Strings, Array, (and a class I've made  
> - LogicVar)?
>
> Is it "OK" to extend the functionality of the built-in classes this
> way, or should I derive my own Number, String, Array --- I want to use
> the parser/compiler that Squeak already has, so I want to be able to
> enter:
>
> 5 unifiesWith: 5 in: emptyEnv
>
> On the subject of return values, what's the best way to return more
> than one value? Should I create my own class (UnificationReturnValue)
> (then I could tell it how to respond to ifTrue/ifFalse etc), or should
> I return a collection with indexes for the success-value and the
> environment-value?
>
> Thanks!
>
> Cheers
>
> Chris
>
> --
> A/Prof Chris Wright FJFICJ FRACP MBBS
> Medical Director, ICU
> Monash Medical Centre
> Clayton, VIC
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> I would like to play around with some classes which require
> unification (I know about Prolog/V etc...). I am not sure where to
> "put" the unification algorithm.
>
> It might look like:
>
> anObject unifiesWith: anotherObject in: anEnvironment
>
> ? does that seem like the right sort of selector?
>
> So, to I put that in Number, Strings, Array, (and a class I've made  
> - LogicVar)?
>
> Is it "OK" to extend the functionality of the built-in classes this
> way, or should I derive my own Number, String, Array --- I want to use
> the parser/compiler that Squeak already has, so I want to be able to
> enter:
>
> 5 unifiesWith: 5 in: emptyEnv
>
> On the subject of return values, what's the best way to return more
> than one value? Should I create my own class (UnificationReturnValue)
> (then I could tell it how to respond to ifTrue/ifFalse etc), or should
> I return a collection with indexes for the success-value and the
> environment-value?
>
> Thanks!
>
> Cheers
>
> Chris
>
> --
> A/Prof Chris Wright FJFICJ FRACP MBBS
> Medical Director, ICU
> Monash Medical Centre
> Clayton, VIC
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> 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 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
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners

> On 2/16/07, Roel Wuyts <[hidden email]> 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.
>

> Hello Chris.
>
> I need a unification algorithm in Squeak to solve simple constraint  
> problems.
> What is the current state of your project for implementing a  
> unification algorithm ?
>
> BTW, does anybody known whether or not the SOUL package on  
> squeaksource is stable.
>
> Thanks a lot.
>
> Guillaume Grondin
>
> Chris Wright wrote:
>> On 2/16/07, Roel Wuyts <[hidden email]> 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.
>>
>
> --
> Guillaume Grondin
> Ph.D candidate in Computer Science
> ===========================================
> Département IA, École des Mines de Douai
> 941, rue Charles Bourseul - BP 10838
> 59508 Douai Cedex
> Tel : (+33) (0) 3 27 71 24 53
> Fax : (+33) (0) 3 27 71 29 17
> Email: [hidden email]
> http://csl.ensm-douai.fr/grondin
>
>
> _______________________________________________
> Beginners mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/beginners