Self-interest August 1995

self-interest@lists.selflanguage.org

10 participants
23 discussions

Re: macros / code construction (and assignment)
by David.Ungar＠Eng.Sun.COM 29 Sep '95

29 Sep '95

Good stuff, Brook--! Rainer, I'll try to explain my viewpoint one last time: I believe that whether or not you like macros depends a lot on your background and expectations. If you are mathematically grounded and inclined, you may see computer programs as rewriting systems sort of like proofs. There is a whole tradition in CS, starting with (pure) Lisp that springs from this well, and it has contributed a lot. Macros fit in fine here, just another way to do rewriting. It's fine with me for suitably inclined, educated, and abled folks to take this viewpoint, but I (and in my opinion many others) are unable to. If you come from physics, or your early exposure was to interpreted languages like APL, or ST, you are likely to feel that working with a computer is about the direct & immediate manipulation of stuff--objects, matrices, etc-- and macros seem silly. After all, the base language already lets me extend the behavior of the computer, adding a second step, another execution model, just complicates things. In this school, you hope that the syntax is bearable enough not to need extension-- after all English speakers manage pretty well with those 26 letters-- and you try to build extensible semantics in the language. (Blocks are a great example here.) You also try to build an implementation that supports this. With our implementation the sort of "if: bool Then: b1 Else: b2" method runs as fast as a macro--in fact we beat Lisps in benchmarks. So, you trade off simplicity of language and execution model against some amount of low-level extensisibilty and complexity in the implementation. That's why Self is as it is (IMHO)--Randy will have a different view. As far as assignment is concerned--I am more interested in building things with objects than inside of them. But my favorite treatment of this area may well be Glyphic's, by Mark Leczner (sp?). Again, my values are simplicity and explainability. I don't give a fig for expressive power beyond what Self already has. I have even toyed with reducing Self a bit--but all these types of arguments generally bottom out on assumptions about how frequently certain kinds of programs will be written, and that is very, very subjective. Personally, I listen to (in no particular order) Randy, Peter, Mario, and of course, Ole Madsen (and others-- please don't feel bad if I forgot to include you) I feel that I share their values and trust their clarity of vision. Ole in particular has had many many years of experience (himself and through working with his colleagues) in OO stuff, and the Beta (and I guess Simula) folks seem to have more experience in the statically-typed OO area than anybody. Rainer, I will leave you with one last thought-- my worst mistakes have always resulted from being too clever. - Dave -- Dave

2 1

Re: macros
by urs＠cs.ucsb.edu 24 Sep '95

24 Sep '95

Rainer Blome wrote: > > You can get 90% of 'if bool then else': > > if: bool Then: thenClause Else: elseClause = > > ( bool if: thenClause False: elseClause ). > > Oh, OK. In this case, a macro would indeed be an efficiency hack. Because > using a message would give up locality there. Where is the `if:Then:Else:' > slot? In globalBehavior, I guess. And that slot takes time to find. If > its content is a normal method, it will be evaluated over and over again. > Maybe the compiler can optimize that away, but I don't think so. Well, I couldn't let *that* bait go :-) Here's a little experiment: put the if: .. method in defaultBehavior and create a test object called foo containing (| parent* = defaultBehavior*. test: n With: x With: y = ( n do: [ x < y ifTrue: 'true' False: 'false'] ). test2: n With: x With: y = ( n do: [ if: x < y Then: 'true' Else: 'false'] ). |) [Hint: never put such testing code in the shell, because it has a dynamic parent that can mess up performance.] On my system, [foo test: 100000 With: 3 With: 4] time is 135..161 and [foo test2: 100000 With: 3 With: 4] time is 137..162. No difference. Of course, a *really* smart compiler would execute both in 0 ms, but that's another story. -Urs

2 1

Re: assignment (was: macros / code construction)
by David.Ungar＠Eng.Sun.COM 31 Aug '95

31 Aug '95

Thanks--your interpreter idea is interesting. You could choose whether or not to expose slot types. We have talked about exposed slot types in the past-- it is an interesting debate. - Dave -- Dave

1 0

assignment (was: macros / code construction)
by Jecel Mattos de Assumpcao Jr. 31 Aug '95

31 Aug '95

On Thu, 31 Aug 1995 00:03:54 +0200, rainer(a)physik3.gwdg.de (Rainer Blome) wrote; >imagine doing assignment another way. assignment is a hack (from the >functional point of view). it manipulates its context. one should make >that explicit by revealing the reflection involved in assignment. first >get an object that represents the place (the slot). that is the reflective >part. then send it a normal message with the new value as an argument: > >(reflect: self slot: "x") store: 1 On Wed, 30 Aug 1995 16:26:55 -0700, ungar@self (David Ungar) wrote: > We have had lots of discussions about > assignment, but what it boils down to for me is > that containers are appealingly intuitive notion, > and so I am happy to ground out where it does. > Going deeper does not seem to me to buy so much. Here is who I did it in tinySelf: every slot in a map has a name, a value and a "type". The type is actually just a pointer to some code that gets called with the value as an argument. Right now this field points to C functions, but it would point to pre-compiled Self code in the future, allowing the user to create new slot types. Currently, these are the types that are avaiable: - constant: this code simply pushes the value on the stack - data: this code pushed *(self+value) on the stack - assignment: this code pops the stack and stores it in *(self+value) - code: this calls the interpreter with value, which is a method object When I write the compiler later, it could simply replace the pointer to the interpreter in "type" by a pointer to the newly generated code ( which would ignore "value", of course ). I won't do it this way, but the main idea it that "compiled code", "primitives" and the "assignment primitives" should all be made from the same stuff. On Mon, 15 Oct 90 14:40:43 PDT ( note the date - I have a good memory ;-), ungar@thoreau (David Ungar) wrote: > We believe strongly in the benefits of reusing the same code with different > representations. This implies that the code may not distinguish between > reading a variable and invoking a function. > > How to model this in a programming language? > > One way would have been to have different kinds of slots: data slots and > code slots. Had we done this we could have had functions which only > evaluated when fetched out of a code slot. > > We rejected this approach on two grounds: > 1. clutter caused by multiple slot types > 2. functions considered harmfull. > In OOP a receiver gets to decide what code to run. But if > you have functions they always do the same thing no matter > what the objects are. > I believe that functions perniciously weaken the power of > data abstraction by taking control away from the objects, > and by packaging up code without data. > > So, we opted for one slot type, and a model that says that an object is > always executed when fetched from a slot. Most objects simply return > themselves when they execute. > > As a result, you cannot have a naked method in Self, because it would have > run when you fetched it, and you would have gotten the result of the method. > So, we have mirrors. A mirror is a way to handle an object without > evaluating it, much like a "ten foot pole". When doing reflective > computation (as your example does) always stick with mirrors. I am not very happy with my solution of slot types, but I don't expect it to break any existing code. It is true that if you store a method object into a data slot, it will *not* be executed when you try to fetch it. But I don't think it is even possible to store a method in a data slot in Self 4.0, is it? It is strange how close assignment is to argument initialization - (| x |) x: 9 [| :x | ... ] value: 9 I used a block in this example to ignore the cloning that goes on in the argument initialization. The difference is that arguments are initialized by the *position* while the assignment works by *name*. Beta almost managed to unify these two notions, but didn't quite manage it. BTW, the more I learn Beta, the more I like Self! ( though I did find Beta much more fun than Oberon or C++ ) -- Jecel

1 0

scoping (was: implementation issues)
by Jecel Mattos de Assumpcao Jr. 31 Aug '95

31 Aug '95

On Wed, 30 Aug 1995 10:19:56 -0700, David.Ungar(a)Eng.Sun.COM (David Ungar) wrote: > And, I don't think Beta quite solves the block problem-- > > Consider that Beta still needs a built-in thing for if's, whereas ST & Self > (& Scheme) don't. > This is important because it means that it feels pretty heavyweight to use > a user-defined > control structure in Beta, compared to ST or Self. When I wrote a Smalltalk-72 interepreter, early this year, I tried very hard to get rid of the built-in "if", but failed completely. This is one of the neatest features of later Smalltalks and Self. As for Beta, it *is* possible to have a user defined IF. Here is my very first Beta program: ORIGIN '~beta/basiclib/v1.4/betaenv' ---- program: descriptor ---- (# (* if.bet: * ======================= * Author: Jecel Mattos de Assumpcao Jr * * Purpose: * tests a user-defined IF pattern. * *********************************************************) myIf: (# mthen:< (# do INNER #); melse:< (# do INNER #) #); myBool: (# i: ^myIf; enter i[] do INNER #); myTrue: myBool (# do i.mthen #); myFalse: myBool (# do i.melse #); do & myIf (# mthen:: (# do '1' -> putline #); melse:: (# do '2' -> putline #) #) [] -> myTrue; & myIf (# mthen:: (# do '3' -> putline #); melse:: (# do '4' -> putline #) #) [] -> myFalse; #) Of course, you can see that it is so ugly that a built-in IF is very desirable :-) David Ungar also wrote: > Also, consider that Beta has lexical scoping, as Jecel points out. > This is great for some things, but does add complexity to the language-- > should it be in or out? (Self has a little of it) I am not sure yet. I would say that Self has no lexical scoping at all but fakes it with a "runtime patched dynamic scoping". It is easy to see ( though a bit confusing at times ) that neither slot initializers nor inline objects are lexically scoped. This is a good thing for, as Rainer Blome points out, otherwise we would have problems with objects created graphically rather than by reading a file. How about blocks, then? I can write: | a. b | ......... [ | c, d | ....... .................. [ | e | e: a + b + c + d ] ... ....... ] This certainly looks like lexical scoping. It feels like lexical scoping. It smells like lexical scoping :-) But it is really done by setting up dynamic parents ( self* or <lexicalParent>* ) at runtime so that the normal method lookup scheme does the right thing. Once the compiler inlines the blocks away, any difference between this and real lexical scoping goes away. I had to think a lot about this when I was designing a Logo-like language that I derived from Self ( I called the language Troy ). Almost all logos are dynamically scoped, but some are lexically scoped. They can pass bits of code around, but don't have Self style blocks. I chose dynamic scoping but had to restrict it in order not to allow a violation of object encapsulation. Again, I was less that totally successful :-( -- Jecel

1 0

[ungar@self: Re: macros / code construction]
by Mario.Wolczko＠Eng.Sun.COM 31 Aug '95

31 Aug '95

Date: Wed, 30 Aug 1995 16:26:55 -0700 To: Mario.Wolczko@Eng (Mario Wolczko) From: ungar@self (David Ungar) Subject: Re: macros / code construction We have had lots of discussions about assignment, but what it boils down to for me is that containers are appealingly intuitive notion, and so I am happy to ground out where it does. Going deeper does not seem to me to buy so much. - Dave >Date: Thu, 31 Aug 1995 00:03:54 +0200 >From: rainer(a)physik3.gwdg.de (Rainer Blome) >To: self-interest(a)self.sunlabs.com >Subject: macros / code construction > > >yes, i know, macros as in the lisp family are a very unstructured way of >doing things. i don't actually care for macros, any way to make convenient >the use of useful but awkward idioms would do. > >i have heard about beta's facilities in that direction but have only just >printed the tutorial out, so i can't comment on that. (as always: no >library -> no book on beta :-( ) i like the common lisp/loops method >combination stuff, so i guess i'll like beta, too. > >there are more things that i miss in self: local methods and evaluation of >literals in the dynamic context (dynamic? lexical? what does lexical mean >anyway, when we don't have source-code anymore?). > > >imagine doing assignment another way. assignment is a hack (from the >functional point of view). it manipulates its context. one should make >that explicit by revealing the reflection involved in assignment. first >get an object that represents the place (the slot). that is the reflective >part. then send it a normal message with the new value as an argument: > >(reflect: self slot: "x") store: 1 > >(buggy, but you know what i mean. how the slot implements the `store:' >method? don't you ask! ;-) > >of course, this is to be put as a method in the `assignment slot'. now >this `slot:' (meta-) message will always eval to the same object (the `x' >slot), so it should not be computed every time the assignment method is >called. > >note that the method now _explicitly_ `knows' the slot it refers to, as >opposed to knowing that implicitly by reflecting on its (the method's) own >slot name. randy and dave mentioned a very similar way to implement >assignment in their ecoop95 paper. > >to make this scheme feasible, two things are missing (that means, i >can't see them, *I* might be missing them, not self, tell me if i do.): > > a way to do computation during initialization > > a convenient way to construct code. writing this kind of > assignment methods must be automated. > > >this is long already, i'll stop here. any thoughts? am i making sense? > >rainer -- Dave

3 3

loopExitContinue/loopExitValueContinue
by rainer＠physik3.gwdg.de 31 Aug '95

31 Aug '95

Ian just kindly explained loopExit to me so it seems I didn't phrase my question clearly enough :-) By loopExit[Value]Continue I mean loopExitContinue / loopExitValueContinue. They're not explained in the manual (there's a comment in the slot, but I couldn't correlate that with the code) and are not sent anywhere so there's no example of how to use them. How must a block look like that will respond correctly to this message? What does any argument to `exit:' have to look like? For example, making sense of the loopExit method is difficult without knowing that the block that you send it to must have an `:exit' slot that takes the `escape' block. [Hmm, I just realize X-Copy/Paste doesn't work with the Self window :-{ ] The comment says: `Same as loopExit, plus a second arg block that causes the loop body to restart' Looking at the code a little harder, I can now make sense of that line. ([[| :exit | value: [^ nil] With: [exit value]. ] exit ] loop) The message that will ultimately be sent to the receiving block is the third line and a template for a receiver might look like this: [| :exit. :continue. | mandatoryCode. shouldExit if: exit. shouldShortCircuit: continue value. "Is the `value' necessary here?" facultativeCode. ] So this provides sth like C's `continue' keyword. I think I understand how this works now, but I'm not 100% sure. Rainer

1 0

Re: types of people
by Mario.Wolczko＠Eng.Sun.COM 31 Aug '95

31 Aug '95

Date: Tue, 29 Aug 1995 15:13:17 +0200 From: rainer(a)physik3.gwdg.de (Rainer Blome) To: jecel(a)lsi.usp.br Cc: self-interest(a)self.sunlabs.com In-Reply-To: <9508282154.AA02536(a)obj.Eng.Sun.COM> (Mario.Wolczko(a)eng.sun.com) Subject: Re: types of people jecel wrote: > [...] how different kinds of people make (and use) different kinds of > systems [...] there are very few women in OS and language design [...] > the "types of people" are independent of sex [...] the available "types of people" (aka communities) are indeed independent of sex (imo), but the distribution of people over the types isn't. still, one shouldn't in general cater for a specific distribution but instead make sth useful for a wide range of types. a way to achieve that is to unify concepts used in different communities, then maybe sell them all the same stuff with just different labels. in other words, i think it's possible to make a language feel `just right' for a far wider range of users than the current languages do. for example, self has some of scheme in it but could use a lot more still: - unified blocks and methods (procedures aka closures) - more convenient representation of code as data - a macro facility - closures that may be used out of their lexical context - continuations - transformation of tail recursion into iteration - lazy allocation (scheme does not have this by default, but should) the first three issues are actually visible at the language level. they simplify library design and will probably make the system lighter or more effective. the last two are implementation issues, invisible at the language level. they complicate (do they?) interpreter/compiler construction but will make the system more efficient. out-of-context closures and continuations are implementation issues that are visible at the programming level. using heap allocation is a simple way to implement closures but that's slow. having lazy alloc would help a lot there (first, alloc on the stack, evacuate to the heap when necessary), but isn't trivial to implement fast. still, because it pays off in so many ways (including providing elegant and fast ways to implement the other three implementation issues), it seems the way to go. rainer

3 3

macros / code construction
by Mario.Wolczko＠Eng.Sun.COM 31 Aug '95

31 Aug '95

Date: Thu, 31 Aug 1995 00:03:54 +0200 From: rainer(a)physik3.gwdg.de (Rainer Blome) To: self-interest(a)self.sunlabs.com Subject: macros / code construction yes, i know, macros as in the lisp family are a very unstructured way of doing things. i don't actually care for macros, any way to make convenient the use of useful but awkward idioms would do. i have heard about beta's facilities in that direction but have only just printed the tutorial out, so i can't comment on that. (as always: no library -> no book on beta :-( ) i like the common lisp/loops method combination stuff, so i guess i'll like beta, too. there are more things that i miss in self: local methods and evaluation of literals in the dynamic context (dynamic? lexical? what does lexical mean anyway, when we don't have source-code anymore?). imagine doing assignment another way. assignment is a hack (from the functional point of view). it manipulates its context. one should make that explicit by revealing the reflection involved in assignment. first get an object that represents the place (the slot). that is the reflective part. then send it a normal message with the new value as an argument: (reflect: self slot: "x") store: 1 (buggy, but you know what i mean. how the slot implements the `store:' method? don't you ask! ;-) of course, this is to be put as a method in the `assignment slot'. now this `slot:' (meta-) message will always eval to the same object (the `x' slot), so it should not be computed every time the assignment method is called. note that the method now _explicitly_ `knows' the slot it refers to, as opposed to knowing that implicitly by reflecting on its (the method's) own slot name. randy and dave mentioned a very similar way to implement assignment in their ecoop95 paper. to make this scheme feasible, two things are missing (that means, i can't see them, *I* might be missing them, not self, tell me if i do.): a way to do computation during initialization a convenient way to construct code. writing this kind of assignment methods must be automated. this is long already, i'll stop here. any thoughts? am i making sense? rainer

1 0

tail recursion elimination
by Mario.Wolczko＠Eng.Sun.COM 30 Aug '95

30 Aug '95

Date: Wed, 30 Aug 1995 21:34:01 +0200 From: rainer(a)physik3.gwdg.de (Rainer Blome) To: self-interest(a)self.sunlabs.com In-Reply-To: <9508301651.AA23068(a)obj.Eng.Sun.COM> (Mario.Wolczko(a)eng.sun.com) Subject: tail recursion elimination jecel wrote: > While this optimization is invisible in a normal execution [during > debugging] you will find that a large chunk of your stack is missing. yes, the self group had written that in some place, i had forgotten. how about deoptimization then? with tre you can't really do that dynamically, you might have to rerun a huge amount of code, it might not even work at all. so it should be a user- (programmer-) selectable optimization. the debugger will have to explain that and why the frames are missing. i was just looking at the implementation of the looping behavior in traits block - it boils down to the _Restart primitive which is even better visible than missing stack frame in the debugger. btw, i tried to understand what the loopExit[Value]Continue methods do, but failed. they might have sth to do with this discussion, do they? there seem to be no senders of these messages, why are they there? rainer

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

1996

1995

1994

1993

1992

1991

1990

Self-interest August 1995