Re: Re: consistency in Self

[Brook Conner <dbc@cs.brown.edu>]

**> 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