Squeak-dev October 1998

squeak-dev@lists.squeakfoundation.org

107 participants
209 discussions

Structure of objects and execution (with effects on visual programming, and reversible debugging, )
by Daniel Vainsencher 24 Oct '98

24 Oct '98

Hi Ian, remember the idea of replacing CompiledMethods in MethodDictionaries with closures? More thoughts on that direction. There are three main representation of executable stuff, AFAIK. They differ in three main aspects - structure, human useability, machine usability (efficiency) Text - freeform, human readable, not directly executable. ParseTree - structure represents code semantics, not human readable but can be reasonably represented, requires only a little context to be runable. CompiledMethod - a VM datastructure that specifies execution, not human readable at all and hard to access via messages, but directly executable by Interpreter. If we look at Squeak, two of the three form are clearly dominant, and much more visible to the user - the first and the third. The user directly edits Texts all the time, and can find CompiledMethods by inspecting any class. ParseTrees are mere shadows, temporary constructs built by the Compiler, and thrown away. (if you're not sure I'm right about this, in a standard distribution image CompiledMethod allInstances size => ~13,000 MethodNode (the root of ParseTrees) allInstances size => ~1 ) The point I'll make is that this is all wrong. ParseTrees should be dominant, the others mere shadows. I'll propose some changes, and ask some feasibilty questions. 1. Text is not really a very good way for users to program. It's true, it is superficially easy (the UI is the same like working with simple, non executable text). But right now, it doesn't give much information back. Decorated Text (eg, format with left-shift held), which can include more information, is rare in the system right now, and doesn't give much more. Graphical ways of visualizing program execution might be more useful even than Decorated Text. But that's not the point - the point is that both Decorated Text and Visualization of the program are manufactured from a ParseTree. One might say, they are simply alternative ways to render or specify a ParseTree. So why is so much focus on the source code, and so little on the ParseTree? 2. On the system side, one might call CompiledMethods a premature (though great at the time) optimization. The direction of DynamicPrimitives, and JIT compilers is to give us more efficient ways to represent code. In addition, we find that we sometimes want to modify the execution environment. We already have a system simulator, and we've seen we might want to stretch that in other directions - reversible debugging, for example. What am I proposing? make classes have dictionaries of selector -> ParseTree (Concretely, MethodNode, or we might choose to wrap it) pairs. At runtime, the ParseTree can be dynamically decorated by other representations - selector -> ExecutingDecorator-> ParseTree where the decorator will only take over functions it does better (execution). Note that this would make it easy to experiment with lots of options, for example, to setup a fast-compiler/optimizing-compiler pair like in Self. 3. If we already make execution much more transparent, implementing extensions like MethodWrappers and such should become much easier. Refactoring operations become quite natural, as does having a ParseTree "reattach" - bind itself to a new class, instead of it's old context. So aClass when: aSelector do: aBlock aBlock reattachToClass: self self atSelector: aSelector putCode: aBlock. becomes pretty easy. To me that suggests that blocks also stay mere ParseTrees until they're used, but then that's only natural... Possible problems - The size of the ParseTree representation - bytecode is pretty small, but we can keep rarely used trees compressed, and open them on access. Efficiency of dynamic translation - if we have a method cache, and we keep that always equiped with directly executable code, we probably will not have a problem. Self worked using something like this, though I'm not sure what their intermediate representation was like. What do you think? I'd like to try to do a simple version of this (that simply converts MethodNodes to CompiledMethods). Do you have tips on navigation in the VM code for dispatch and such?

3 2

RE: prototypes vs classes was: Re: Sun's HotSpot
by David Stes 24 Oct '98

24 Oct '98

> De: Dan Ingalls <DanI(a)wdi.disney.com>. > > My experience is that it's about equally difficult to get the benefits of classes > using prototypes as to get the benefits of prototypes with classes. I'm interested > in this topic because I think one can pretty much have the best of both worlds. With the computer algebra kit, I felt that in some cases, the prototype based approach was "right" since you could take a polynomial in some representation, and then make a "similar" polynomial, but in a sligthly different representation, so in that case, a "clone" message was appropriate. But in other cases, I'd just want to create a Term instance as a group of coefficient, symbol and exponent, and in that case, I just want to use a factory message for a factory (class) like Term. If there weren't a Term class, I'd have to add it anyhow. > I detect a bit of an attitude behind your question (since I'm sure you knew > the answer) and it makes me curious about what your motivation is. It's very complicated ... Steve Dekorte is (or perhaps, was, I don't know) an Objective-C supporter. See homepage : http://www.slip.net/~dekorte/Objective-C/. So if you look for motivation, look in the area of Objective-C. I think Squeak is setting a standard for other languages ..., certainly for systems like Objective-C (derived in some sense from ST). If Squeak would move over to prototypes, then this is a strong argument for other languages to "follow". Or as a minimum, it would be a reason to call class-based systems like O-C "out-dated" because they would still be class-based, while Squeak and "modern" systems would all be prototype based.

1 0

Re: Structure of objects and execution (with effects on visu
by Jerome.Garcia＠wj.com 24 Oct '98

24 Oct '98

Sorry to butt into this conversation so quickly but I just have to excitedly express my support for the idea that ParseTrees should be dominant. I have thought so since my days as project leader of the COBOL compiler development project at CDC in the early 80's. I then kept thinking "Why can't I get rid of all this text, focus on the parse trees and give the programmer a GUI to edit the parse trees?". Of course, no self respecting COBOL programmer would have gone for that :-( If I remember correctly, Prograph felt a little like what I wanted from the GUI but not quite correct. Since I don't know enough about the innards of Squeak to comment intellegently on most of Daniel's discussion, I will quiet down now but keep my fingers crossed. Jerome -- Jerome E. Garcia jegarcia(a)adventurousmind.com ______________________________ Reply Separator _________________________________ Subject: Structure of objects and execution (with effects on visual p Author: Daniel Vainsencher <danielv(a)netvision.net.il> at INTERNET Date: 10/23/98 10:47 PM Hi Ian, remember the idea of replacing CompiledMethods in MethodDictionaries with closures? More thoughts on that direction. There are three main representation of executable stuff, AFAIK. They differ in three main aspects - structure, human useability, machine usability (efficiency) Text - freeform, human readable, not directly executable. ParseTree - structure represents code semantics, not human readable but can be reasonably represented, requires only a little context to be runable. CompiledMethod - a VM datastructure that specifies execution, not human readable at all and hard to access via messages, but directly executable by Interpreter. If we look at Squeak, two of the three form are clearly dominant, and much more visible to the user - the first and the third. The user directly edits Texts all the time, and can find CompiledMethods by inspecting any class. ParseTrees are mere shadows, temporary constructs built by the Compiler, and thrown away. (if you're not sure I'm right about this, in a standard distribution image CompiledMethod allInstances size => ~13,000 MethodNode (the root of ParseTrees) allInstances size => ~1 ) The point I'll make is that this is all wrong. ParseTrees should be dominant, the others mere shadows. I'll propose some changes, and ask some feasibilty questions. 1. Text is not really a very good way for users to program. It's true, it is superficially easy (the UI is the same like working with simple, non executable text). But right now, it doesn't give much information back. Decorated Text (eg, format with left-shift held), which can include more information, is rare in the system right now, and doesn't give much more. Graphical ways of visualizing program execution might be more useful even than Decorated Text. But that's not the point - the point is that both Decorated Text and Visualization of the program are manufactured from a ParseTree. One might say, they are simply alternative ways to render or specify a ParseTree. So why is so much focus on the source code, and so little on the ParseTree? 2. On the system side, one might call CompiledMethods a premature (though great at the time) optimization. The direction of DynamicPrimitives, and JIT compilers is to give us more efficient ways to represent code. In addition, we find that we sometimes want to modify the execution environment. We already have a system simulator, and we've seen we might want to stretch that in other directions - reversible debugging, for example. What am I proposing? make classes have dictionaries of selector -> ParseTree (Concretely, MethodNode, or we might choose to wrap it) pairs. At runtime, the ParseTree can be dynamically decorated by other representations - selector -> ExecutingDecorator-> ParseTree where the decorator will only take over functions it does better (execution). Note that this would make it easy to experiment with lots of options, for example, to setup a fast-compiler/optimizing-compiler pair like in Self. 3. If we already make execution much more transparent, implementing extensions like MethodWrappers and such should become much easier. Refactoring operations become quite natural, as does having a ParseTree "reattach" - bind itself to a new class, instead of it's old context. So aClass when: aSelector do: aBlock aBlock reattachToClass: self self atSelector: aSelector putCode: aBlock. becomes pretty easy. To me that suggests that blocks also stay mere ParseTrees until they're used, but then that's only natural... Possible problems - The size of the ParseTree representation - bytecode is pretty small, but we can keep rarely used trees compressed, and open them on access. Efficiency of dynamic translation - if we have a method cache, and we keep that always equiped with directly executable code, we probably will not have a problem. Self worked using something like this, though I'm not sure what their intermediate representation was like. What do you think? I'd like to try to do a simple version of this (that simply converts MethodNodes to CompiledMethods). Do you have tips on navigation in the VM code for dispatch and such?

1 0

Re[8]: Does Squeak include a generic node class?
by Jerome.Garcia＠wj.com 23 Oct '98

23 Oct '98

Sort of like a template was the first thought that came to my mind. I agree that this is could be a better approach. Do you think that what you are describing is similar to "Aspect Oriented Programming" as Joe Davison has suggested or is it somehow significantly different? I took a look at the web site and at first glance it seems similar. Jerome ______________________________ Reply Separator _________________________________ Subject: Re: Re[6]: Does Squeak include a generic node class? Author: Les Tyrrell <tyrrell(a)canis.uiuc.edu> at INTERNET Date: 10/23/98 1:18 AM > I think I understand what you are saying but I am not sure. Could you > give me a description of what you mean by "parameterized mixin" or > provide a URL for a site. It is not a term with which I am familiar. Analagous to a Template, but in my case perhaps more analogous to a macro expansion. However, neither of these would cover variations in implementation, but would take care of such things as variable and method names. Variations in implementation starts getting into a somewhat more involved discussion. Essentially, it is a recognition that there are usually several ways to achieve a certain goal, hence various means of resolving the conflicts of a Pattern ( in the Alexandrian sense ). So a means of accomodating and managing those variations is needed, along with a means of composing patterns from other patterns, optimising the shape of a pattern to best fit a particular problem but according to the rules governing a pattern,etc. Which is to say that at this point it is for me the beginnings of some notion about a way of doing some things... It gets involved. To describe it better, I'd have to build it. This is only one of many things I would like to do, but never seem to get around to doing them. Rather aggrevating, actually. les

1 0

RE: help needed attributing a quote
by Helge Horch 23 Oct '98

23 Oct '98

First, thanks to Dan, Alan, and all others who helped here on the list and by email to nail the quote down. Funny what time (and a bad memory) can do to a quote. Another couple of years, and it comes out as either Haiku or Limerick. <g> At 07:07 23.10.98 -0400, Bob Jarvis wrote: >Is this paper available on the web or in print anywhere? I don't think it's on the web, but Universities' C.S. library departments usually carry a lot of ACM publications and proceedings (at least here in Europe). That's where I discovered my copy many years ago. (If you can't find the SIG-POPL volumes anywhere, don't hesitate to contact me directly.) Cheers, Helge

1 0

Re: Re[4]: Does Squeak include a generic node class?
by Les Tyrrell 23 Oct '98

23 Oct '98

One of the reasons I would not favor a TreeNode abastract class is that the thing I want to reuse is the pattern, and possibly multiple times within the same class. For instance, to a certain extent this happens whenever I maintain several collections of different things within an object. Having a superclass in which only one of these one-to-many relationships is covered does not help. That's why I do not bother with a commonly used TreeNode, but instead manually do the work that a parameterized mixin could do for me. I do the rubberstamping because I currently do not have a facility within the system to accomplish the same goal. Such a facility would have to manage more than simply stamping out code- I would want it to do things in a manner such that good software engineering and reuse practices become a natural part of working with the environment. As far as running inheritance ( delegation, actually ) through patterns... that would be an interesting project for someone. The motivation is based on the observation that many patterns are used again and again, that there are variations in implementation of these patterns, and that quite often I am able to parameterize them and stamp them out on a grand scale. At that point I am not writing individual methods nor specifying individual instance variables, I am saying "put this pattern into that class". That is a different mode of programming, and it will require a different set of tools to facilitate it. One aspect of that might be that it would be worthwhile to run inheritance and behavior through behavioral patterns rather than classes, which accumulate several patterns into one context. This leaves the issues of working out how to deal with the inter-pattern interactions, and the extent to which individual patterns are decoupled from other patterns in a given context. In that model, classes are contexts in which patterns live and interact, and ideally to the greatest extent possible the atomic particles of a class would be individual patterns, rather than individual methods and instance variables. Or, in another way, the patterns within a class context would be the instantiations of pattern "classes". Something like that... Whether this would ultimately be good or not I have no idea. BTW, I am sure that this is a somewhat different connotation for the word "pattern" than that used by the Patterns people... the problem is that "pattern" is such an appropriate name for what I have in mind, but unfortunately it was appropriated decades ago and I don't have a decent replacement term to use instead. So keep that in mind... I don't intend to redefine the term, I just haven't found a better name for what I'm after. les

2 1

RE: help needed attributing a quote
by Mark Wai 23 Oct '98

23 Oct '98

At 07:07 AM 10/23/98 -0400, you wrote: >Is this paper available on the web or in print anywhere? > >Bob Jarvis >The Timken Company Bob - Check with ACM (www.acm.org). I am sure they have a copy in Digital Library. The paper is also included in the POPL 10 years CD. -- Mark Wai Wator Innovision mailto: mwai(a)ibm.net or:[ mwai(a)frontiersa.com ] __

1 0

RE: help needed attributing a quote
by Jarvis, Robert P. 23 Oct '98

23 Oct '98

Is this paper available on the web or in print anywhere? Bob Jarvis The Timken Company >-----Original Message----- >From: Dan Ingalls [SMTP:DanI@wdi.disney.com] >Sent: Thursday, October 22, 1998 11:30 PM >To: Helge Horch >Subject: Re: help needed attributing a quote > >Helge - > >>a friend of mine intends to use one of my favourite quotes for a paper: >> >>"Programming with objects is like working with trained animals, >> instead of pushing around data with a broom." >> >>Since I was the one who mentioned it to him, my friend now demands a clear >>attribution. 8-) > > >"Beyond this I must add that programming in Smalltalk is fun. On the one >hand, the act of assembling expressions into statements and then into methods >is not very different from conventional programming. On the other hand, the >experience is totally different, for the objects which populate and traverse >the code are active entities, and writing expressions feels like organizing >trained animals rather than pushing boxes around." > >The Smalltalk-76 Programming System >Design and Implementation >Daniel H. H. Ingalls >Proceedings of ACM conf on Principles of Programming Languages >Tucson, AZ, 1978 > >I like your version a lot. The broom is good. > > - Dan >

1 0

help needed attributing a quote
by Helge Horch 23 Oct '98

23 Oct '98

Hi all, a friend of mine intends to use one of my favourite quotes for a paper: "Programming with objects is like working with trained animals, instead of pushing around data with a broom." Since I was the one who mentioned it to him, my friend now demands a clear attribution. 8-) I *think* it was Alan Kay, and I *had* thought it was somewhere in either the 1981 BYTE, the Dynabook papers, Green Book, ThingLab paper, etc. I have now leaved through many pages - I can't find it. So: Is the quote accurate? Alan's? Dan's? (Too bad you're all at OOPSLA now...) Where might I have read it? Desperately yours, Helge P.S. This is for a Forth paper. Curiously, while not being a new concept for the Forth community, OOP (OOF) is constantly rediscovered.

3 2

Just a remark about prototype language semantics
by ducasse＠iam.unibe.ch 23 Oct '98

23 Oct '98

Hi, I just want to have your view on the following point. The prototype model has some different qualities than the class model and I do not want to dicuss this point here. For my an object in prototype and class based language is has an identity that refers to a Private non sharable set of data and a sharable set of behavior (via inheirtance or delegation). I just want to stress that what was a source of problem in some prototype models was the sharing of value between prototypes i.e. the fact that if I'm a prototype a that refers to my parents I shared their slots and so if I modified one my slot my parents are modified too. (Note that here I'm discussing if self does or not implement maps, trait and so other implmentation techniques that are certainly valuable.) For me the sharing of values is not good thing, it introduce to manage the split of object problem (see oospsla papers). I prefer to see a prototype like an object having its private data and sharing its behavior. This is the semantics of Pico developed by Pr. D'hondt from VUB http://dinf.vub.ac.be/prog/pico/ Stef

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
21
Older →

Jump to page: