Squeak-dev March 1998

squeak-dev@lists.squeakfoundation.org

67 participants
130 discussions

aspects of MOP (was: class, prototype, meta)
by jecel＠lsi.usp.br 02 Mar '98

02 Mar '98

I wrote a paper on bootstrapping a reflective system that might be of interest to some people on this list: http://www.lsi.usp.br/~jecel/jabs7.html An updated version of that paper is a chapter in this book: "Advances in Object-Oriented Metalevel Architectures and Reflection" Edited by Chris Zimmermann CRC Press, 1996, ISBN 0-8493-2663-X This was intended to complement "The Art of MOP" so it might also interested somebody here (though it is a bit expensive). About Aspect Oriented Programming: a key feature of a good MOP is the "separation of concerns". That is, you shouldn't have to mix base-level code and meta-level code in a single source. It would be nice to be able to entirely write the base-level program (and even test) and then turn your attention to meta-stuff and write it separately (for better understandability and reusability). An example where this doesn't happen is when your meta-language is in the form of annotations (or "pragmas"). If you segregate the meta-level into special objects, you get much closer to this goal. Now it happens that this separation of the sistem into two "aspects" (the base-level and the meta-level) is simply too simplistic. We could go a step further and separate the data distribution aspect of the application from the communication protocols aspect. You might find it useful to also break up the base-level into separate parts (like VRML separates the 3D structure aspect from the interaction aspect by coding them in totally different languages). So the main idea is to write several simple programs in specialized languages. But this is not to be confused with some kind of modular programming! The compiler must "weave together" the sources from all different aspects into a single object code. Please see the AOP pages for an example. This is closely related to implementing reflection by doing a partial evaluation of the meta-level and sticking it into the base-level's object code. The bottom line is that I find AOP very exciting, but not really needed if you have a *very* good MOP. -- Jecel

1 0

Re: class, prototype, meta
by wirth＠almaden.ibm.com 01 Mar '98

01 Mar '98

Alan, It's delightful to read your comments on Object Models and MOPs -- always interesting topics to me, and especially useful now as I'm trying to do some work in this area, with Squeak as the testbed. One of the regrets of my 4+ years at Apple, much of it working on dynamic languages (e.g., SK8) and even located just down the hall from your team, was that I didn't get to interact more with you and them. Now, through the marvels of this mailing list and the active participation of the whole Squeak team, we're all getting the benefit of that interaction. Keep the postings (and the "blue plane" changes to Squeak) coming! Now a couple questions and an emotional reaction: Gregor apparently published another book on MOPs by himself after "Art of the Metaobject Protocol", at MIT Press, titled "Open Implementations and Metaobject Protocols", in both hardcover (Sept 94, ISBN: 0-262-11192-6) and paperback (June 95, ISBN: 0-262-61103-1). But my attempts to get a copy at all the usual places (MIT Press, Amazon, Stacey's in Palo Alto, and even the Stanford Bookstore) have failed. How different is this book from the "AotMP" (which I have)? Should I persist in trying to get a copy? Gregor seems to be pursuing a new topic, "aspect oriented programming". Any comments on this line of research? A quick read of the intro web pages didn't leave me with enough concrete understanding to assess the ideas. You said: ....But it is really terrible if you just ban such things. That is too moralistic and smacks of the Wirth school of (non)programming. This is why well thought out metasystems should allow the good designer/programmer to have their cake and eat it too. The "Metaobject protocol" by Greg and Danny, et. al., at PARC is an inspiring further advance in what we had done there in the '70s, and it gives some tantalizing insights into what could yet be invented.... Ouch! How can I clear my name? :-) Maybe I'll just have to convince you that Nicklaus is the "call-by-name" Wirth and I'm the "call-by-value" Wirth :-) Mike Wirth IBM Almaden Research Center

3 4

Re: auto-delegate messages
by staypufd＠gte.net 01 Mar '98

01 Mar '98

Hello all, With all the discussions of MI, prototyping and what-not, I thought I'd throw in something I've been thinking of. I'd like to have an implementation of 'interfaces' for squeak. I believe it would help with the self documenting idea and when coupled with delegation, could help implement a facade of MI. Objective-C uses interfaces and delegation very effectively in this way. Mixins could be built on top of this structure and conflict resolution for methods could be based on order of mixin declaration, and each conflicted method getting called autmatically in the order of the declarations. I believe this way, we could have MI of interfaces, a manageable MI of implementation and a very defined way of dealing with colissions. Just a thought... Another thought I had was related to what the Disney team thinks of the Dylan language relative to Squeak. It has MI, everything is an object, somewhat of a MOP, typing (if wanted), generic functions, etc. Sam Griffith Jr. Objective Methods Software, Inc. staypufed(a)aol.com staypufd(a)gte.net (512) 267-4893 (h) (913) 534-2959 (w) (913) 895-9591 (apt) "Sunshine on my shoulder, makes me happy!" by John Denver

1 0

Re: auto-delegate messages
by Eliot & Linda 01 Mar '98

01 Mar '98

Tim Olson wrote: > > Hi, all: > > Here's a cute trick / crufty hack I recently posted to > comp.lang.smalltalk. It was in regards to someone complaining that they > had to recreate a bunch of methods when using a delegate to implement > multiple-inheritance-like operation. Instead of manually doing this > (painful) or dynamically doing this by implementing doesNotUnderstand: > (slow), why not combine the two and have the doesNotUnderstand: method > install the custom-created method? > > Comments? The technique was the basis of Dan Ingalls' and Allan Borning's multiple inheritance system for Smalltalk-80 v2.0. An instance of a class with multiple superclasses checked its extra superclasses for methods in doesNotUnderstand: and recompiled them in its own class so that the next time it was sent there would be no doesNotUnderstand:. The scheme maintained a dependency graph so that if one changed a method (either modified or deleted) that was copied all the copies would be removed. When a class with multiple superclasses was first created for all selectors that had more than one reachable implementation, i.e. ambiguous methods, the class would create a method that did ^self conflictingInheritanceError. The programmer could then resolve the ambiguities as required. The implementation was buggy; self was not renamed when copying down; conflicting inheritance methods overrode the resolutions if you redefined the class; redefining superclasses could cause bugs due to the traversal machinery expecting a tree and not a graph, etc. Evewn with these bugs fixed the general feeling was that it was too complex. The best alternative I've seen is Gilad Bracha's mixin-based multiple inheritance scheme. http://java.sun.com/people/gbracha/mwp.html _______________,,,^..^,,,_______________ Eliot Miranda

1 0

Re: class, prototype, meta
by John Albert Fehr 01 Mar '98

01 Mar '98

wirth(a)almaden.ibm.com wrote: > > While we're on non-CS points of view, let me ask a new question about > method bindings. I'm really interested in biological analogs (and was much > taken by the ones you mentioned in your OOPSLA keynote). I've been trying > to figure out how one might do method dispatching for prototypes that are > floating around a distributed, sometimes-connected environment (as span the > set of electronic gadgets I have in my pocket, briefcase, etc.). Cells > have receptors on their cell walls that signal what messages (proteins) > they can receive. Can we use a similar mechanism for objects? (The answer > to which leads to more questions about where the methods are stored, how > they're inherited, etc. The fantastic redundancy of having the full > "source code" in the DNA in each cell is a marvelous thing.) Comments? > Pointers to other writings on computational vs. biological systems? > > Mike i don't have any "pointers to other writings" but i want to comment. i liked what Alan had to say about the region between a prototype and a "kind" -- that something starts out as a sketch and evolves into a "kind of" something. i've wondered if a behavior for a prototypes or classes couldn't die if unused, like entrophy. one could prototype a method definition, allow it to keep track of its invocations and versions, and the most frequently sent definitions could persist across the temporal prototype-to-kind evolution phase. those methods definitions that are unsent would either die or remain in the prototype for further refinement -- excluded from the emerging "kind." furthermore, in an local image, unwanted (unsent) behavior could be treated like unreferenced objects -- eligible for garbage collection. if the behavior is ever needed, its definition might be fetched from another local image, compiled for that platform and evaluated -- as in a set of local images "floating around a distributed, sometimes- connected environment" or a kind of cyber-image. one could measure when a prototype is a more-stable "kind" by the frequencies of its instantiation and the utilization of its respective behaviors. excuse me if this has all been discussed. i just subscribed to this forum. i liked your question about method bindings and wondered if dispatching might be assisted by somehow tracking behavior invocation, -John F. *********************************************************************** John Albert Fehr Ranch to Market, Inc. PO Box 162404 Austin, Texas 78716-2404 (512) 472-6726 jfehr(a)sprintmail.com ***********************************************************************

1 0

Re: class, prototype, meta
by wirth＠almaden.ibm.com 01 Mar '98

01 Mar '98

Ken Dickey said: Note that I did a prototype dispatcher which did not use global tables (for precisely the case that network objects might have a very small local lifetime). The basic idea is that the selector is handed to such an object which does its own dispatch. When an object 'enters the system' it gets the selector values and creates an optimized dispatch function (perhaps lazily). [I can send you a page of html and a couple of tiffs with sample code in Scheme if you are interested]. Sounds like ideal material for one of the Wiki sites. Why not send a text version to the mailing list and put the html and tiffs (converted to gif?) on one of the Wiki sites. We ought to create a discussion topic for this thread (if it doesn't exist already). Mike

1 0

Re: (where to find) "Open Implementations and Metaobject Protocols"
by wirth＠almaden.ibm.com 01 Mar '98

01 Mar '98

Thanks to Allen Wirfs-Brock's suggestion: For more information on Gregor Kiczales' work on meta-programming and open implementations see: http://www.parc.xerox.com/spl/projects/oi/default.html which leads directly to the publication abstract and download links at: http://www.parc.xerox.com/spl/groups/eca/pubs/complete.html#Kiczales:TUT95 I downloaded this document (Postscript) and converted it to PDF. The result is titled (surprise :-) "Open Implementations and Metaobject Protocols", is 330 pages long, last modified Sep. 8, 1996, and appears to be the draft Alan refers to below. The PDF file is 827KB. I'll be happy to upload it if someone can tell me where (presuming Gregor doesn't mind). Mike Wirth "Alan C. Kay" <alank(a)wdi.disney.com> on 03/01/98 03:52:08 PM To: cohenb(a)gemstone.com, squeak(a)cs.uiuc.edu cc: wirth(a)almaden.ibm.com Subject: Re: "Open Implementations and Metaobject Protocols" (was Re: class, prototype, meta) At 3:36 PM -0800 3/1/98, Bruce Cohen wrote: -- snip --> >Gregor was circulating early drafts to the object community, which may >be why Alan Kay remembers reading a copy. Yep, now that I vaguely recall, it very likely was a draft of someone's that I perused. What is so interesting about this subject area is the tantalizing notion that by several mechanisms (many of them involving various kinds of confinement) one should be able to get almost everything in a system to be late bound without either great danger or significant performance hits. Cheers, Alan

2 1

Pink Plane Biology
by Brian Foote 01 Mar '98

01 Mar '98

> >While we're on non-CS points of view, let me ask a new question about >method bindings. I'm really interested in biological analogs (and was much >taken by the ones you mentioned in your OOPSLA keynote). I've been trying For you (other) pink-plane Darwinian dilletantes out there: Squeak seems like a wonderful example of of an evolutionary phenonmenon called "neoteny", where an organism adapts by essentially reverting to an earlier stage in its development. The phenotype does this by arresting it's development at an earlier, juvenile stage, before the mature features that the genome is abandoning have developed. Sometimes the mature organism is hamstrung by adaptations that are no longer useful, and needs to "draw back to leap", to be able to explore the earlier paths not taken. (I first saw this notion in Koestler's books (Act of Creation/Ghost in the Machine), as an undergrad, which Alan also mentioned in his talk, as I recall.) >Pointers to other writings on computational vs. biological systems? We did a patterns paper that cast evolving code in terms Dawkin's selfish gene notion: http://laputa.isdn.uiuc.edu/selfish/selfish.html. There's are some fresh patterns on the Wiki web that explore some bio angles: http://c2.com/cgi/wiki?BeeHive is a good place to start. --BF

1 0

Re: class, prototype, meta
by Brian Foote 01 Mar '98

01 Mar '98

>>But I think a critical point here is that just being able to clone willy-nilly >>is confusing one metalevel with another -- and here is where I disagree with >>the "Lieberman" and SELF (what I think of as the LISP, or "data structure") >>schools of prototypes. I feel it is very important to at some point make a >>commitment to "kind" (I use this word because better terms like "type" and Kind is as kind does, I would think. Given that, even Lieberman and Self were still enjoined to make sure that no matter how you fiddle with your objects, they'll still know what to do when they are asked to respond to the subset of their vocabulary that each client throws at them. (I too, am trying to avoid loaded terms.) As long as what you do to an object at runtime doesn't violate the assumptions of the code that uses it, Smalltalk's traditional implicit dynamic "kinds" will still be intact. Indeed, it's interesting to try to explain to programmers who are now being weaned on interfaces that Smalltalk programmers have been casually using this notion implictly for twenty-five years. The notion of somehow formalizing protocols has hung as an under-ripe piece of low hanging fruit for fifteen years (I first saw it in the Dan Ingall's Green Book chapter sometime during mid-Reagan era.) The original impetus was to use types to generate better code (as was the custom during that period). Indeed our group went down that road with Typed Smalltalk. I think this one reason this one is ripening now because people are finally becoming convinced that black-box components are better for building flexible code that inhertiance, and are looking for better language support , mechanisms, and tools for it. Over half of the Gang-of-Four design patterns involve some sort of delegation or forwarding, so it's natural to want to be able to express, for example, that for a given class (or instance, for that matter) all messages in a given set (Protocol, etc.) will be forwarded or delegated to a particular component. Therein can lie a tale. >>"class" have already been colonized with too-specific meanings in the computer >>world). So, while I think that you should be able to do absolutely anything >>with and to your programming system, I also think there should be "guardians at >>the gates" when you go from one metalevel to another. E.g. it shouldn't be as >>easy to change the inheritance chain as it is to send a safe message to another >>object. The issue isn't as much whether its easy as whether the meta-architecture, or language objects, tell a good story and provide the right hooks to let you accomplish what you want in a way that is clear to readers, and not merely diabolically clever. Good language objects, like any other objects emerge from experience with trying to solve a range of real problems, and diligent cultivation and refactoring. This means you need a coherent architecture at the metalevel, cast in terms of concepts that make sense to people who need to tailor the language to solve their problems, and not just an wide open door. >>get rid of data structures is because an assignment statement is a different >>metalevel than a function call, and you just should not be able to do either They really are on different "levels", only <level> isn't quite the right way to think of it. Rather, independent design dimensions emerge as you factor the language objects. Having <state> be a distinct metalevel concern is valuable because lots of issues arise that have to do with state indepentent of what is being modelled by an object: memory management, persistence, marshalling, to name but three. These are the kinds of issues I think Alan was getting at when he talked about tangling one metalevel with another earlier. You can't do these with one flat, single inheritance/delegation chain very easily. It's the architecture behind these, the one that was built in C++ in Self, under-the-hood, where some of the really interesting stuff happens. The pieces you build the chain of still need to be first-class themselves too. >>Smalltalk-76 we perhaps reacted too much in the opposite direction, and didn't >>put a more appropriate meta-level in the language for defining syntax -- but >>the earler way we worked simply led to a tower of Babel. When the language itself is built out of objects, who cares how many semicolons can dance on the head of a pin? We know how to build different, dynamic views of things that are built out of objects. >you mentioned this book in your oopsla keynote, but i haven't been able to >get my hands on it. to be honest, i haven't tried that hard to get it >because you remarked that it was probably only comprehensible to someone >with an extensive Lisp back ground (which ain't me) and it really needed to As a Smalltalker who learned Common Lisp expressly to get his hands on the early MOP and review the book, the Lisp just wasn't an huge obstacle given where I'd already been. I hope the part of Alan's recommendation that sticks with people is that it's a fascinating book, and not that the land of parentheses will eat you alive. >be rewritten for Object Land at large (for which, i believe, you offered a >second Smalltalk balloon like the one you gave Dan). so, since *you* read it >and seemed to get a lot out of it, why don't you clue the rest of us in on >some of its more salient points and how you think we might be able to >translate them in squeak (or the next blue thang). > The sound bite goes something like: When the language itself is built out of objects, which can be extended, specialized, customized, and manipulated on the fly like any other objects, it can become the vehicle for its own evolution. A language built out of objects can adapt (within certain confines), without your having to spend five years before a standards committee to get it to change. Instead, when you need new mechanisms and features, you build them. The "Art" of the MOP is coming up with a compeling, powerful, disciplined set of objects that make sense to people who want to change the language in the same way that Collections and Dictionaries make sense to people who want to juggle piles of other objects. Otherwise, you're throwing people blindfolded into the boiler room without knowing what levers will blow up the ship (as Alan alluded to with the ST76 experience). The CLOS/MOP was designed after Smalltalk's, and given that it was fitted to CLOS and Lisp, has an oddly complimentary object model, in which generic functions (selectors) rather than reciever objects control the lookup and dispatch process, and all the arguments to a generic function call can be involved in the dispatch process (that is, it has multimethods). I suspect Alan is more enamored with the notion of a simple, extensible, reflective, accessible kernel of language objects that have compelling, useful architectural identities than with multimethods and generic functions per se (though you can build these in ST80, and if you get the objects right, you can start to make it look pretty. This is one of the issues we've been looking into.) There is, too, the beauty of weaving the reflective braid; of constructing the hall-of-mirrors illusion, and bootstrapping it out of bits, and establishing an interesting relationship between the under-the-hood objects and the language objects, and... The MOP tale, of course, has a long history, in which ST80 and Lisp both play prominent roles. The Smalltalk philosophy of making as much as possible be as open and first-class as possible was one of the primary influence on the MOPers. The philosophy above is one I first saw in the ST74/6/80 languages, and can traced back to McCarthy's little blue book, as Alan noted in Georgia. --BF (who has been doing the MOP and Reflection stuff with STxx for a Real Long Time(TM). http://laputa.isdn.uiuc.edu

1 0

TGEN for Squeak?
by Erik Gjovik 01 Mar '98

01 Mar '98

Has anyone ported TGEN to Squeak? I am thinking of creating a web URL sorting agent and would love to use the scanners in TGEN 2.2 as a starting point. Erik ><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>< Erik Gjovik Internet: erikgj(a)earthlink.net AOL: ErikGj Go Packers -Twelve Championships and counting ><><><><><><><> '29-'31,'36,'39, '44,'61,'62,'65-'67,'97 <><><><><><><><><><><

1 0