Jerome said,
>This is great! It is the only thing in the whole syntax and
> Smalltalk-2000 discussion I have really liked. I would
> also bet that it would make it easier to teach Smalltalk.
Are you sure?

I think that Smalltalk is NOT a language; it is a place.
Learning Smalltalk is learning how to work in a evolving environment.
We use a syntax because we currently use
 text panes (and keyboard) to express behavior.

I will appreciate advances in the gestual manipulation of objects
 and new ways to "feel" a virtual system (I said "feel",
 not only "see", morphic helps only in seen objects,
 but exploring/inspecting/reparing them requieres new
 tools for perception&expression).
If we change the syntax, we will not get a big diference
 because we are thinking only object "oriented".

In Smalltalk we HAVE objects (all the time);
 we do not have only a language. This diference is the most
 important (to me) and it makes Smalltalk
 really a new way of creating software.

A method (and block) defines a context.
A context is an interval of time in the life of the object.
The context also defines the objects seen by the receiver.
An object MUST know the name of an object to send messages to it.
Names in Smalltalk are very important because it defines the posibility
 to send messages when solving the problem defined by
 the context activation.

Why not to buid methods (on the fly) by naming objects
 while working with them?
I am thinking in a kind of interface where we can see the context
 as a box containing all available objects (arguments, local named
 objects, "self", globals -faded as far as they are from the receiver- )
We can work with prototype objects like in morphic,
 but encapsulated in the working context.
We can join many names and build a group of arguments to be
 send to a(named) object; then the object (receiver) will present
 all the messages that can be posible candidates for messages
 sending.
When confirmed the message is sent to the object
 and a new object (te result, unnamed) appears in the context.
We can, now name the object and continue "working" in this context.
The actions done in this context can be used to build a method
 (or a block)...

We can see this kind of programming WITH objects as
 a "programming throught time" (PTT), where we build
 methods and blocks (contexts) as a consecuence of working
 with real objects. [working with the objects of the environment,
 and not with objects in our minds].
This kind of working focuses the atention in objects,
 contexts (names & time) and object lifetime.

A method (in this kind of programming) can be seen as a movie,
 and we can rewind the movie and add new interactions at any point.
We can "read" a method looking the objects interact
 in a video secuence as in the moment of creation of the context.

Ale.

----------
De: 	Jerome E. Garcia[SMTP:jerome at lightsurf.com]
Responder a: 	squeak at cs.uiuc.edu
Enviado el: 	Miércoles 16 de Febrero de 2000 18:16
Para: 	squeak at cs.uiuc.edu
Asunto: 	RE: Squeak (ST80) syntax

I have to second this!

This is great! It is the only thing in the whole syntax and Smalltalk-2000
discussion I have really liked. I would also bet that it would make it
easier to teach Smalltalk.

Jerome

> -----Original Message-----
> From: Lex Spoon [mailto:lex at cc.gatech.edu]
> Sent: Wednesday, February 16, 2000 1:07 PM
> To: squeak at cs.uiuc.edu
> Subject: Re: Squeak (ST80) syntax
>
>
>
> Wow, this is beautiful.  I'd disagree on "Manything", but the following
> are simply awesome:
>
> 	Thing
> 	Nothing
> 	Everything (though i like Universe (since World is taken))
> 	Kind
> 	yes, no
>
>
> I'd add one thing to your list:
>
> 	inject:into:  -->  accumulate:startingWith:
>
>
> Oh, and of course, don't forget:
>
> 	ifNil --> ifNothing
> 	ifNotNil --> ifSomething
>
>
> I'm not so sure about #ifNo:, beacuse it doesn't read very well in
> English.  How about #ifSo: and #ifNot: ?
>
> This is so fun.  I'd betchya this really would make it easier to teach
> Smalltalk, although as Dan pointed out, it will take data gathering and
> not abstract argument to decide for sure.
>
>
> Lex
>
>
>
>
>
> Travis Griggs <tgriggs at keyww.com> wrote:
> > Stefan Elisa Kapusniak wrote:
> >
> > > In edu.uiuc.cs.squeak, Dan Ingalls <Dan.Ingalls at disney.com> wrote:
> > >
> > > >Yes.  We refer to this as "implicit self".  Alan is the strongest
> > > >proponent of this appraoch in our group, actually, and SELF works
> > > >this way as well.  We seriously considered this also back in
> ST-74 (!).
> > > >The two things that have prevented enthusiastic adoption of this
> > > >approach are...
> > >
> > >    I have a nagging notion that part of the problem here
> > >    may be that "self" shouldn't have the name "self". I
> > >    think I'd feel better if it were "thisObject" or
> > >    something.  "self" really indicates me, myself, sitting
> > >    here at the keyboard typing this email.  I suspect
> > >    non-programmers find the overloading of the word a
> > >    bit confusing.
> > >
> > >    It's sort of like having to pretend you're the object
> > >    to work out what's going on or what to say.  I think
> > >    this might act as a hurdle -- tho' I don't have any
> > >    evidence of it.
> > >
> > >    Changing the name to something more like "thisObject",
> > >    would work better for 'typing in the air', and inspector
> > >    workspace type things, even if you didn't make any other
> > >    alterations.
> >
> > I think the ever presence of self is a good idea; I note that
> in discussing
> > C++ and Java code samples with people, it often becomes obvious
> that it's
> > just scoped subroutines and structures as well. The fundamental basis of
> > message sending is often missed. I think the ever presence of
> 'self' drives
> > home the reciever <- message paradigm.
> >
> > I do agree with Stefan on this name issue as well. My wife doesn't do
> > computer programming. Nor does my mother or brother or father
> or many other
> > people that one would find in other walks of life. Sometimes, the
> > discussions cross over to what I do. They recognize the "object
> oriented"
> > thing, because that's been made into a media buzz word. But
> they don't know
> > what it means. People ask "what IS an object?" And then I try
> to create a
> > map for them so that they can map terms that are familiar with
> them to the
> > OO way of thinking. I've always wondered why it is I have to do
> that. The OO
> > way of thinking is really a quite natural one, but it's masked in
> > computerese terms.
> >
> > A while back, I did some experiments where I changed not the syntax of
> > Squeak, but the semantics of some of the core pieces of the
> language. It was
> > a real riot. What's an object? That's always the question I get
> asked first.
> > I always answered "It's a Thing." Why tell people that over and
> over again,
> > why not just make it so? So object got renamed to Thing (One can do this
> > without really screwing up the system by simply renaming
> Object, but giving
> > it two entry points in the Smalltalk dictionary, Thing and Object). Then
> > came nil. What's that? It's the single instance of
> UndefinedObject. But now
> > I guess it's an UndefinedThing, which is a long way of saying it's a
> > placeholder for Nothing. So UndefinedObject became Nothing, and
> an alternate
> > pseudovariable representation was added for nil: nothing (for
> grins a put a
> > "notta" in there too). It was amazing how simple this was to do
> in Squeak,
> > and yet maintain backwards compatibility. At this point I
> started noticing
> > that there was something cool about this "thing" stuff, it had a certain
> > metaness to it that was fun. I was able to have the "is Nothing
> someThing?"
> > discussion right there in Smalltalk. Of course it was, because Nothing
> > derived from Thing. At that point, it got really fun. The
> Smalltalk global
> > got renamed to Everything. Collection became Manything. I still
> haven't hit
> > on what Anything and Something should've been. Then it came to classes.
> > What's a class? A class is a kind of Thing. So, it got renamed.
> Kind. That
> > was easy to explain to my wife. When we got talking about Kinds
> of Things,
> > the whole notion of classification became much more tractible.
> Vehicle was a
> > Kind of Thing. Car was a Kind of Vehicle. And a particular
> instance of a Car
> > was a Kind of Car. The message kind was implemented in Thing to return
> > class. On the Kind (er Class) side of Thing, kind returned
> superclass. Since
> > I'd renamed everything else, it was time to rename the psuedo
> variables. To
> > make Things more anthropomorphic, "I", "me", "my", and "this"
> were added as
> > variations of "self". Since many people aren't boolean logic
> masters, "yes"
> > was added as an alternative for "true" and "no" for "false". Parallel
> > versions of ifTrue: and ifFalse: were added. I never did come
> up with a good
> > rename for super or thisContext. But the code started to look
> kind of cool,
> > and Squeak's very natural language appearance helped.
> >
> > Set>>select: aBlock
> >     | result |
> >     result := self kind new.
> >     1 to: my size do: [:i | | something |
> >     something := I basicAt: i.
> >     something isNothing ifNo: [result add: something]].
> >     ^result
> >
> > I would think this kind of semantic evolution would be more
> beneficial than
> > a syntactic one. Unfortunately, I never finished the above up and got it
> > out. I got hung up on trying to create a parallel namespace for
> this stuff
> > and then one tangent led to another... sigh.
> >
> > --
> > Travis Griggs (a.k.a. Lord of the Fries)
> > Member, Fravenic Skreiggser Software Collective
> > Key Technology
> > P-P-P-Penguin  Power!
>
>