Thank you Alan,
I was starting to be a little concerned that no one was interested. :) Thanks for the huge pointer on where to go next.
It definitly needs a speed up and better performance tests/monitors. We'll get better algorithms. What I am really interested in is the full unification in CLOS. It almost seems as if it is related to AOP. A single object may want to register for several events with different patterns. Since every object in the system can be considered a 1 arity tuple, we could get Object to understand match: and implement a doubleDispatch to locate special cases. You may want to register with an ad hoc match algorithm, however. VM and JIT support could go a long way on restricted class spaces. Since we have a oop fence with the vm event channel, we could possibly apply the idea of an 'Protocol class' which could help us find a restricted class implementation of the space structure and algorithms. Is this the path of least resistence?
Could you tell us a little more about full unification in CLOS?
cheers, Rob 8-)
Alan Kay wrote:
Rob --
Much work was done in the area of fast correlation of tuples with event patterns for OPS5 at CMU and later, ART (automated reasoning tool) at Inference Corp (spinoff from CMU, they used to be located in LA). Most of this would work very well for Linda (whose pattern matching is kind of a minimal subset of what ART could do). You should find some great algorithms for this in the literature. ART, in particular, was pretty fantastic at being able to have many thousands of patterned watchers all looking at a big constantly changing tuple space 1000s of times per second. Several really serious mainframe and terminal systems (e.g. for American Express, a large airline, etc.) were done in ART in the 1980s. Much earlier (late 60s) Dave Fisher (CMU) and I independently showed NLogN event expression catchers (like boolean expressions but seeming to continuously and efficiently evaluate), some of whose technology was later incorporated into the highly engineered OPS5 (and then ART) stuff. You could also look at how LINDA has been incorporated into CLOS with full unification instead of just simple matching ... I.e. a lot has been done in this area over the years.
Cheers,
Alan
At 10:32 AM -0700 7/30/00, Rob Withers wrote:
Or any abstract tree implementation. There's no sense in reinventing the wheel. Even better would be a Slang implementation. 8-) (drool)
thanks, Rob
--
Smalltalking by choice. Isn't it nice to have one!
Could you tell us a little more about full unification in CLOS?
After Bolot ported Mike Teng's Prolog/V to Squeak, but before starting on these book projects, I started exploring using the Prolog unification for LindaTalk, but I didn't get very far. Perhaps that's a start using existing code?
Mark
-------------------------- Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Mark --
Yes, I would say that is a very good place to look at and start.
One of the things that would help the merging of Smalltalk and Linda is to see what aspects of Smalltalk can be abstracted by the Linda tuple. There are two obvious ones.
* A tuple can be used as an abstraction for sending and receiving of a message, though in Linda it is a little more general and comes out as publish and subscribe.
* The second abstraction is to use the Linda tuple to model externalized properties of an object (you don't want to expose the instance directly since that ruins encapsulation, but it is quite reasonable to think of exposing the kind of values that getters expose to pattern recognition and retrieval).
* A third and more subtle one is that one could conceive of a tuple space that only has the exposed end of a stream as its single "tuple". Linda matching in such a space could be used to construct compilers and other kinds of translators, etc.
* A fourth usage would be to model a reasoning tool (like ART) that permits both forward and backwards processing. ART's forward reasoning was fast enough to allow e.g. views to be made of a model without touching the model in any way, just by being able to react (event driven style) to the new values (that were tuples in ART) being produced by the model process.
Cheers,
Alan
At 1:48 PM -0400 7/31/00, Mark Guzdial wrote:
Could you tell us a little more about full unification in CLOS?
After Bolot ported Mike Teng's Prolog/V to Squeak, but before starting on these book projects, I started exploring using the Prolog unification for LindaTalk, but I didn't get very far. Perhaps that's a start using existing code?
Mark
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
Alan,
I had no idea that it was this powerful. TSpaces and JavaSpaces are touted as repositories or communications buffers. I had heard of ART, but not the same one you mentioned. I think it was the Adaptive Resonance Tool, also from CMU. I think it was a combination of a Neural net, GAs, and a Selectron style bucket brigade for unsupervised learning. It was quite successful, in the lab. It also used a Blackboard model to exchange information.
I have a few comments/questions, below...
Alan Kay wrote:
Mark --
Yes, I would say that is a very good place to look at and start.
One of the things that would help the merging of Smalltalk and Linda is to see what aspects of Smalltalk can be abstracted by the Linda tuple. There are two obvious ones.
- A tuple can be used as an abstraction for sending and receiving of
a message, though in Linda it is a little more general and comes out as publish and subscribe.
A forwarder that we can use as a perfect proxy would help us hide this, and treat it as a message send. I was trying to subclass off of ProtoObject and the tools didn't like it.
- The second abstraction is to use the Linda tuple to model
externalized properties of an object (you don't want to expose the instance directly since that ruins encapsulation, but it is quite reasonable to think of exposing the kind of values that getters expose to pattern recognition and retrieval).
A big conceptual problem that I am having is how to convert or publish the right (restricted) information of a particular object. There may be several different views of an object. I don't think we have to convert to a Tuple instance, but rather give Object the protocol for Tuple. Another issue is that we have to initialize the match template with type information. Of course, that is bi-directional, as well. As I learn more about what Linda can do, it struck me that a JIT needs to do this very thing, when looking up the (receiver | arguments ) tuple for the right native method. Could we write the JIT in Slang?
- A third and more subtle one is that one could conceive of a tuple
space that only has the exposed end of a stream as its single "tuple". Linda matching in such a space could be used to construct compilers and other kinds of translators, etc.
Wow! Really?! How does this work? I can almost see that it could walk a tree, which would be nice. I'm guessing that you could register the productions and actions for various tokens that one would find in a language. If that stream emits the tokens and does a lookahead, then the reading and writing of the tokens would trigger various productions, which would take what it needs from the stream. This would be fun to build! There must be a way to register interest by internal actions for events. There must also be a way to add new operations. Mmmm.
- A fourth usage would be to model a reasoning tool (like ART) that
permits both forward and backwards processing. ART's forward reasoning was fast enough to allow e.g. views to be made of a model without touching the model in any way, just by being able to react (event driven style) to the new values (that were tuples in ART) being produced by the model process.
I have much reading to do on this. :)
Currently, Linda is a powerful tool that seems to be looking for a home. She is being fed and she's starting to grow in *very* interesting directions.
thanks, Rob
Cheers,
Alan
At 1:48 PM -0400 7/31/00, Mark Guzdial wrote:
Could you tell us a little more about full unification in CLOS?
After Bolot ported Mike Teng's Prolog/V to Squeak, but before starting on these book projects, I started exploring using the Prolog unification for LindaTalk, but I didn't get very far. Perhaps that's a start using existing code?
Mark
Mark Guzdial : Georgia Tech : College of Computing : Atlanta, GA 30332-0280 Associate Professor - Learning Sciences & Technologies. Collaborative Software Lab - http://coweb.cc.gatech.edu/csl/ (404) 894-5618 : Fax (404) 894-0673 : guzdial@cc.gatech.edu http://www.cc.gatech.edu/gvu/people/Faculty/Mark.Guzdial.html
squeak-dev@lists.squeakfoundation.org
-
Alan Kay -
Mark Guzdial -
Rob Withers