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
It is OK to extend existing classes, but you should read up on PackageInfo so your methods remain in their own package.
http://www.wiresong.ca/Monticello/UserManual/PackageInfo/
-Todd Blanchard
On Feb 15, 2007, at 9:34 PM, Chris Wright wrote:
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On 2/16/07, Todd Blanchard tblanchard@mac.com wrote:
It is OK to extend existing classes, but you should read up on PackageInfo so your methods remain in their own package.
That is a really useful reference and piece of advice...
thanks
Chris
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.
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.
( If you are interested I have a number of papers I can point you to, since I did research on integrating a Prolog in Smalltalk )
On 16 Feb 2007, at 16 February/06:34, Chris Wright wrote:
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
On 2/16/07, Roel Wuyts Roel.Wuyts@ulb.ac.be 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.
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.
Indeed, because you now have Smalltalk extended with unification. With the other option you would need to do something like:
5 asTerm unifiesWth: 5 asTerm in: emptyEnv
which is more cumbersome.
You can have a look at http://prog.vub.ac.be/SOUL/index.html for more info on what we did. To really know more about the integration you can have a look at this paper: http://www.iam.unibe.ch/~scg/Archive/Papers/ Gybe06aSymbioticReflectionESUGJournal.pdf or in my phd. Happy reading :-)
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 Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
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 Roel.Wuyts@ulb.ac.be 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.
Sorry, I just noticed your mail.
The SOUL package on squeakource is normally stable, but very old. But the unification algorithm there should not give you problems. If you need any help, you can post messages on the SOUL mailinglist (see http://prog.vub.ac.be/SOUL/index.html ); clearly mention that you have a question about the Squeak version, since all recent work has been done for VisualWorks.
On 23 Mar 2007, at 23 March/12:58, Guillaume Grondin wrote:
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 Roel.Wuyts@ulb.ac.be 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: grondin@ensm-douai.fr http://csl.ensm-douai.fr/grondin
Beginners mailing list Beginners@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/beginners
beginners@lists.squeakfoundation.org
-
Chris Wright -
Guillaume Grondin -
Roel Wuyts -
Todd Blanchard