**> On Mon, 27 Jun 1994 15:36:37 -0400, "Michael Grant Wilson" mcq@oti.on.ca said: Michael> on Tue, 28 Jun 1994 12:29:30 -0400 urs@cs.stanford.edu wrote:

On the other hand, they would be a wonderful tool for an annual Obfuscated Self Contest. :-)

Michael> Not required. After C++, Self is already the most easily obfuscated Michael> language on the planet.

Oh yeah, right :-) You forgot Perl, Tcl, Postscript, and everyone's favorite, machine language that writes over itself.

Not meaning to start a language war, just trying to throw a little perspective in here. Some languages can't help being obtuse: syntax-crazy monsters like C++ and Perl are a haze of hash marks and funny braces. I feel that a keyword syntax like Self's, has the potential to produce extremely readable code. Change it just a bit, and it reads like directed commands:

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.

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.

Michael> However, I agree with ivan@cs.man.ac.uk's point. Generality is Michael> important. You should be able to use a method for your parent Michael> slot. If you can't it exposes a hole where the implementation is Michael> showing through. Essentially, it's wrong for the same reason Michael> that it's wrong that most Smalltalk implementations prevent you Michael> from changing the implementations of many of the "critical" Michael> low-level methods (like SmallInteger>>#+).

I completely agree: parent slots that are also methods are a gaping hole in the indistiguishability of data and behavior in self. But as Randy pointed out, the desired semantics are unclear.

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))?

Michael> Besides, it's not as if you can't detect this case, so it doesn't Michael> prevent you from optimizing methods which don't use the feature. Michael> It's just a bit more internal bookkeeping.

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.

Michael> Infinite recursion is only a problem if you let it be a problem. Michael> We are talking about a powerful feature, that has to be used carefully. Michael> There are lots of ways to blow yourself away with infinite recursion Michael> now. This one's just a bit more subtle.

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).

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]

At any rate, some thoughts.

Lets' keep this thread going.

Brook