Self-interest June 1994

self-interest@lists.selflanguage.org

12 participants
13 discussions

Re: Re: Re: consistency in Self
by Michael Grant Wilson 30 Jun '94

30 Jun '94

on Tue, 28 Jun 1994 22:31:23 -0400 <dbc(a)cs.brown.edu> wrote: > Further, consider the implications of allowing arbitrary code to be > executed as part of message lookup. With the right kinds of mirrors > and assignable parent slots, you can probably completely re-write the > mechanics of message lookup (for all practical purposes). This isn't > a bad thing per se, but then you must ask: why have message lookup at > all? Why not just get rid of the implicit inheritance mechanism and > make everyone forward messages on themselves (explicitly (using the > Tready of Orlando verbiage here))? > I'm not claiming this is the correct viewpoint, but it should be noted that the CLOS people seem to think that they are getting a lot of value out of redefinable method lookup. It doesn't negate the value of the "standard" lookup mechanism, just extends it to cover some exceptional circumstances which you couldn't easily model otherwise. > Yes, but if it becomes commonplace, it will show up everywhere, and > optimization will go out the window. In our graphics system here at > Brown, we cache a lot of stuff (like Self does), in the expectation > that we'll use it again. As it turns out, most of the problems we're > trying to do these days have so much changing stuff, the caches are > never used more than once: we spend more time keeping track of the > caches than we could gain by using them. Needless to say, we turned > off large portions of the caching ability. > Right. Of course, my view is that it is unlikely that the use of the mechanism would become 'commonplace'. It really is a meta-level feature, and I expect you would only find it in a small number of system level places (examples: lazy method mutation, or dynamic link library interfacing). McQ.

2 1

Re: Re: consistency in Self
by Brook Conner 29 Jun '94

29 Jun '94

**> On Wed, 29 Jun 94 10:52:53 MET DST, mulet(a)info.emn.fr (Mulet Philippe 40448387) said: [ how syntax can make code more readable ] > jane goTo: theBallgame With: yourLittleBrother. > > A minor syntactic change, and you have an English sentence: > > Jane, go to the ballgame with your little brother. > > A cute example, just meant to show the possibilities of writing > the mythical and proverbial "self-documenting" code. Mulet> It is true, but remember that historically the syntax of Self is derived Mulet> from the one of Smalltalk. Of course -- this works for Smalltalk as well. I think it stops working for both Self and Smalltalk when you have to start bringing in strange characters to define things: parens, pipes, colons, and brackets come to mind in Self -- the definition of an object isn't terribly readable (meaning, try to read it as English instead of code). What I'm trying to say is that this: jane goTo: theBallgame With: yourLittleBrother. is more readable than its C++ equivalent: jane->goTo(theBallgame,yourLittleBrother); The purpose of the parameters is completely unidentified in C++, but at least _can_ be identified in a keyword kind of message send. > On the other side: Sure, Self has lots of potential for malicious > obfuscation, such as swapping the "ifTrue:Else:" slots on the true and > false oddballs. But some conversations here at Brown indicate that > Self's design enables a highly reflexive mode of computing without > recourse to the additional mechanisms provided for reflexive > computation in other systems (e.g., the macro systems found in Lisp, > Scheme, etc. provide the syntax-creation facilities that arise > naturally out of how Self works). I think this is a big plus. > Mulet> I am working on reflective object-oriented languages, and I wonder what Mulet> kind of behavioral reflection you can envisage in Self. A while back, a brief discussion started here when I asked "What do you really need a macro system for?" in the context of both the C preprocessor and Lisp-like macro systems. The most common useful purpose seemed to be "Creating new syntax." I brought up the point that, in a language like Self, the equivalent of new syntax can be created at the linguistic level. I didn't mean you could create the equivalent of reader macros and make Self look like Algol (for example). More, that the more common defmacro construct wasn't necessary: if-then-else is definable at the user level, as are various kinds of loops, iterators, etc. The point in the end was that macro-like systems are not per se necessary to accomplish what they are most often used for. Macros are approximately baby forms of full reflective capabilities. I haven't put enough time into figuring out what full reflection adds that you can't get with the builtin stuff. The only thing that comes to mind is implementation information, which you can get with mirrors. And of course, in general, such information is something you _don't_ want to see. Mulet> Mirrors are not causally connected to the structures they represent. Hmm? How do you mean? What reflective stuff do you want to do that can't be done with mirrors? This isn't a challenge: I'm trying to figure out how much extra junk you have to add to something like the base Self model to get full reflection. (Part of my research is in stripping down existing object models until you get something that you can use to build exciting new object models. TR available any day now). [...] > a bad thing per se, but then you must ask: why have message lookup at > all? Why not just get rid of the implicit inheritance mechanism and > make everyone forward messages on themselves (explicitly (using the > Tready of Orlando verbiage here))? Mulet> I like very much the idea of being able to compute dynamically the parent Mulet> object, this provides the same kind of flexibility as assignable parent slots, Mulet> with dynamicity in addition. If it provides the _same_ kind of flexibility, it isn't necessary. So what do you mean by "dynamicity?" Could you accomplish what you want by removing actual parent slots and adding a method to handle unresolved messages, resending the message to whatever slot (possibly computed) you wanted to be "the parent?" Mulet> In this way, you could easily implement a network with delegation link, Mulet> the routage algorithm could be handled by parent methods. I can't quite follow what you're looking for here. Can you give an example? [...] > Yes, but, at least in Self, it's infinite recursion introduced by the > programmer, not by the system (as it is in the infinite recursion in > the classes and metaclasses of Smalltalk and Dylan). Mulet> First the infinite regression of metalink in Smalltalk is not infinite at all, Mulet> it is closed in a very elegant way by admitting a circularity around Metaclass. You're right, it isn't infinite. But I see the recursion as being broken, not in an elegant way, but by admitting an arbitrary rule: "This single special-case object doesn't follow the rule that applies to every other object in the system." I don't like rules like that. I find it nicer and more elegant to set up the system without the recursion that requires a special rule just to break out of it (i.e., Self). Mulet> Then you can easily introduce programmer's infinite recursion in Smalltalk, Mulet> much harder is to stop them. If you couldn't recurse, it would be a poorer language for it. I feel that a system is easier to understand the fewer special rules it has governing the way it works. Recursion as part of the system's rules is one thing: recursion I write down myself is another. The first is a roadblock to understanding the system. The second is something I have a much greater chance of understanding, because I wrote it. Mulet> Self contains potential infinite regressions through mirrors and slot descriptors Mulet> that are dealed with lazy creation, but nevertheless it exists. How do you mean? Last time I checked, any time you asked for a mirror on an object, you always got the same mirror. I.e., mirrors were in a one-to-one correspondence with object identity (hmm -- another way to think of mirrors? The object's "identity"?). > Perhaps some thinking from the land of lazy evaluation is in order. I > was impressed by how elegant it is to define an infinite sequence in > languages like Haskell. E.g., the list of all even numbers looks like > this (excuse the syntax -- this is just the idea): > > def allEvens = [ 2, 2 * allEvens] > Mulet> Lisp/Scheme programmers are used for years to use such constructions, called streams. Mulet> They are easily implemented with closures, and probably inspired Haskell. Mulet> In Smalltalk and Self thanks to blocks you can achieve the same result to Mulet> create such infinite series. Yes, of course. Although I suspect lazy evaluation inspired streams, not the other way around (Lisp programmers implemented Prolog in a few pages of Lisp code, but not until after Prolog had been described). But I don't have any references to verify this. The point in Haskell, though, is not that you can get the same kind of functionality somewhere else (this is not a Turing-equivalence argument), but that the mechanisms of the language intrinsically provide streams without extra garbage. You can't simply take the next element of the list if you're using closures in something like Scheme In Lisp, (car (cdr allEvens)) is a closure, not a number. In Haskell, it's a number, not a closure. Haskell hides the implementation. Lisp doesn't. In Self, you can do better: an object with code and no argument slots is indistinguishable from an object (analogous to the equivalence in functional programming of literal constants and functions that return constants). Brook

1 0

Re: Re: consistency in Self
by Michael Grant Wilson 29 Jun '94

29 Jun '94

on Tue, 28 Jun 1994 12:29:30 -0400 urs(a)cs.stanford.edu wrote: > On the other hand, they would be a wonderful tool for an annual > Obfuscated Self Contest. :-) > Not required. After C++, Self is already the most easily obfuscated language on the planet. However, I agree with <ivan(a)cs.man.ac.uk>'s point. Generality is important. You should be able to use a method for your parent slot. If you can't it exposes a hole where the implementation is showing through. Essentially, it's wrong for the same reason that it's wrong that most Smalltalk implementations prevent you from changing the implementations of many of the "critical" low-level methods (like SmallInteger>>#+). Besides, it's not as if you can't detect this case, so it doesn't prevent you from optimizing methods which don't use the feature. It's just a bit more internal bookkeeping. Infinite recursion is only a problem if you let it be a problem. We are talking about a powerful feature, that has to be used carefully. There are lots of ways to blow yourself away with infinite recursion now. This one's just a bit more subtle. McQ

2 1

Re: consistency in Self
by urs＠cs.stanford.edu 28 Jun '94

28 Jun '94

> Maybe this is an extreme point of view - but don't you think it's inconsistent > that you can't have a parent slot 'implemented' as a method? > OK - so it might be a bit slow - you'd have to call the parent slot method(s) > for an object for every message it received. Given the obvious implementation difficulties, a pragmatic answer could be to ask for some examples demonstrating the usefulness of methods-as-parents. (Implementation is difficult because it's hard to "constant-fold" a method execution and thus to inline a send whose lookup goes through a "method parent".) But besides the implementation difficulties there are some semantic problems: in what context is the method evaluated (i.e., what is "self")? And what happens if the method sends a self message? The resulting (potential) infinite recursion would seem to limit the usefulness of methods-as-parents (you could only send messages accessing slots in the object itself or in descendants). On the other hand, they would be a wonderful tool for an annual Obfuscated Self Contest. :-) -Urs

1 0

Re: consistency in Self
by Randall.Smith＠Eng.Sun.COM 28 Jun '94

28 Jun '94

> Maybe this is an extreme point of view - but don't you think it's inconsistent > that you can't have a parent slot 'implemented' as a method? > OK - so it might be a bit slow - you'd have to call the parent slot method(s) > for an object for every message it received. > > Does anyone agree? > > Ivan. > > > No, I don't think it extreem: it's also bothered me for the very consistency reason that you point out. Should the method in the parent slot be evaluated when a message lookup has to go through that slot? If so, why? And if so, what if that method sends subsequent messages to self that don't match directly in the receiver? Infinite regress city. But maybe the method in the parent slot is not evaluated when it is looked up through (new verb form there). If not, why not? And is there some utility to having parent as a message be different from parent used in lookup? These thoughts have always bogged me down.

1 0

consistency in Self
by Ivan Moore 28 Jun '94

28 Jun '94

Hello, Maybe this is an extreme point of view - but don't you think it's inconsistent that you can't have a parent slot 'implemented' as a method? OK - so it might be a bit slow - you'd have to call the parent slot method(s) for an object for every message it received. Does anyone agree? Ivan.

2 1

Re: Smalltalk interpreter of Self
by jecel＠lsi.usp.br 21 Jun '94

21 Jun '94

> I can ping it, but I still can't connect to that url with Mosaic. > I get: > > ERROR > > Requested document (URL http://lsi.usp.br/~jecel/merlin.html) could not be accessed. > > The information server either is not accessible or is refusing to serve the document to you. Oooops! I goofed on the URL. It should have read: http://lsi.usp.br:8000/~jecel/merlin.html ^^^^^^^ Sorry about the inconvenience. I looked at the the address several times and failed to see the problem. - Jecel

1 0

Re: Smalltalk interpreter of Self
by jecel＠lsi.usp.br 17 Jun '94

17 Jun '94

> I don't know if somebody may be interested, but Fred Rivard and me > wrote in 1991 an interpreter of Self 1.0 in Smalltalk 2.5 (Ultimardrev I'm interested! > Self). It contains a parser of the full Self-syntax, that was able to > reload most of the system files, for generating the initial Self > world. The sources may be available. While it never hurts to look at other people's code, it is main in their *ideas* that I am interested in. > Then starting from this interpreter, Pierre Cointe, Jacques Malenfant, > Christophe Dony and me have extended its virtual machine to decompose > message sending according to the lookupOapply model, supported by a > meta-object protocol. This is an alternative to limited mirrors for > reflecting upon Self. Could you elaborate a little on that? I have read all I can get my hands on about reflection, but haven't heard about lookup/apply. I found a lot of good stuff via ftp to p300.cpl.uiuc.edu in the /pub/washington directory. > Actually, we are defining our own full-reflective plateform, Moostrap, > inspired by some Self constructions, and we would be very interested > by any experience with reflection in Self. I am also trying to extend the reflection in Self in my Merlin Project. You can read a little about it in the Web as <a href=http://lsi.usp.br/~jecel/merlin.html> Merlin </a> Unfortunately, the part about reflection is among those that need to be greatly expanded. I based most of my ideas on the Apertos OS developed at Sony ( see ftp://scslwide.sony.co.jp ). =================== /\/\ Merlin Computers Jecel Assumpcao Jr / /\ \ + LSI - Universidade de Sao Paulo jecel(a)lsi.usp.br '-/----\-' + Pontificia Universidade Catolica =================== '------' Sao Paulo - Brazil

1 0

Re: decompiler
by Ole.Agesen＠Eng.Sun.COM 15 Jun '94

15 Jun '94

Hello, Is there a decompiler available that produces something that looks like source code from bytecode vectors? Ivan. Not that I'm aware of, but it shouldn't be too hard to make one, except for possible indentation being lost. And perhaps parenthesis (I like putting in a few redundant ones to make my code easier to read). If you use Mango to parse source, you get parse trees which can be "unparsed" back into source form. The unparsing is an exact inverse of parsing, preserving indentation etc. Ole

1 0

Smalltalk interpreter of Self
by mulet＠info.emn.fr 15 Jun '94

15 Jun '94

Hello, I don't know if somebody may be interested, but Fred Rivard and me wrote in 1991 an interpreter of Self 1.0 in Smalltalk 2.5 (Ultimardrev Self). It contains a parser of the full Self-syntax, that was able to reload most of the system files, for generating the initial Self world. The sources may be available. Then starting from this interpreter, Pierre Cointe, Jacques Malenfant, Christophe Dony and me have extended its virtual machine to decompose message sending according to the lookupOapply model, supported by a meta-object protocol. This is an alternative to limited mirrors for reflecting upon Self. Actually, we are defining our own full-reflective plateform, Moostrap, inspired by some Self constructions, and we would be very interested by any experience with reflection in Self. Philippe Mulet. ----------------------------------------------------------------- Philippe Mulet Phone: +33-40-44-83-87 Ecole des Mines de Nantes Fax: +33-40-71-97-40 3, rue Marcel Sembat 44049 Nantes Cedex 04 ----------------------------------------------------------------- e-mail: mulet(a)info.emn.fr -----------------------------------------------------------------

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 June 1994