"Hernan Galante" <galanteh at smalltalking.net> wrote:
	I have been reading this track and I like the idea to change the names.
	The goal of this is to exclude the idea of "Variables" from Smalltalk.

It is only honest to try 'to exclude the idea of "Variables" from Smalltalk'
if you *first* actually exclude variables themselves from Smalltalk.
Of course, if you do *that*, you end up excluding objects as conventionally
understood, which might not be such a good idea.

Let me try to make this clear.
The programming language Mercury, Clean, and Haskell all have a notion
of 'typeclass'.  (Haskell had it first, but the Clean and Mercury designers
knew a good thing when they saw it.)

Here are some examples from the Haskell standard prelude.

    class Eq a where
	(==), (/=) :: a -> a -> Bool

	-- Minimal complete definition: (==) or (/=)
	x == y      = not (x/=y)
	x /= y      = not (x==y)

If you declare that a type T belongs to type class Eq,
then (a) you are asserting that it has functions (==) and (/=)
which take two arguments of type T and return a Bool result;
(b) you inherit definitions from the class;
(c) you may override any of the operations with type-specific ones.
(In this case you _must_ override one or the other.)

    instance Eq a => Eq [a] where
	[]     == []     =  True
	(x:xs) == (y:ys) =  x==y && xs==ys
	_      == _      =  False

If T is a type, [T] is the type "list of T".  This instance declaration
says that if type T is an instance of the Eq type class, then [T]
is also an instance of the Eq type class.  It also defines equality
for lists in terms of equality of elements:
    - an empty list is equal to an empty list
    - two non-empty lists are equal if and only if they have
      equal first elements and their tails are equal
    - any other combination of lists comes out unequal.

Note that *values* (like the number 1) are not instances of classes
in Haskell, *types* (like the type Int) are.

    class (Eq a) => Ord a where
	compare                :: a -> a -> Ordering
	(<), (<=), (>=), (>)   :: a -> a -> Bool
	max, min               :: a -> a -> a

	-- Minimal complete definition: (<=) or compare
	-- using compare can be more efficient for complex types
	compare x y | x==y      = EQ
		    | x<=y      = LT
		    | otherwise = GT

	x <= y                  = compare x y /= GT
	x <  y                  = compare x y == LT
	x >= y                  = compare x y /= LT
	x >  y                  = compare x y == GT

	max x y   | x >= y      = x
		  | otherwise   = y
	min x y   | x <= y      = x
		  | otherwise   = y

Type classes can inherit from other type classes.
In this case, if you declare that a type T is an instance of the Ord
type class, you must first have declared that it is an instance of
the Eq type class, so the functions in the body of Ord may use all
the functions in the Eq type class (as `compare` does).  As before,
the type class provides default implementations for its operations,
which can be overridden by subclasses and instances.

    instance Ord a => Ord [a] where
	compare []     (_:_)  = LT
	compare []     []     = EQ
	compare (_:_)  []     = GT
	compare (x:xs) (y:ys) = case compare x y of
				  EQ -> compare xs ys
				  lg -> lg
				  
The instance declaration which says that "list of T belongs to Ord
whenever T belongs to Ord" does override `compare`: an empty list
is less than a non-empty list; empty lists are equal; non-empty lists
should check their first elements and recur only if the first elements
are equal.

The classic OO trinity is
    Identity
    State
    Behaviour
Well, Haskell (and Clean and Mercury) have Behaviour all right.
In fact, the distinction between type classes and types is strongly
reminiscent of the distinction between traits and classes.  Just like
traits, type classes have nothing to say about data, they merely
provide chunks of behaviour for reuse.  Just like classes, types DO
describe data.

What's NOT there is any notion of identity or state.
In Haskell there are only values.  There is no distinction between
identity and equality.  Above all, there is no mutation of state.
If the expression e is legal and defined and the result is of
a type that belongs to the Eq typeclass, then e == e MUST be true.

*THAT* is what you get when you 'exclude the idea of "Variables" from
Smalltalk'.  It's useful.  It is even, to my mind, beautiful.  But it
is not Smalltalk, and it is not object-oriented.

State in the "OO trinity" refers to MUTABLE state.
Identity refers to an object retaining some uniquely identifying
property even though its state might change.
Mutable state is variables.

You can only exclude the IDEA of variables from Smalltalk if you
exclude mutable state.  If you leave mutable state in there,
the IDEA of variables _has_ to remain even if you exercise the
power of the Orwellian state and rule that from now on the
word 'variable' is to be replaced in Newspeak by the word 'constant'.

In the original Actors stuff, we were told that Actors had 'scripts'
and 'acquaintances'.  Lo and behold, 'scripts' meant something very
much like 'methods' and references to 'acquaintances' were held in
something indistinguishable from instance variables.

	We can have powerful expressions, not only for newbies
	programmers,

Yes, we do.  Already.

	we can have a powerful tool for people who are interesting
	in the use of squeak like a "virtual laboratory".

Yes, we do.  What else is E-Toys?

	My brother, for example use Squeak to study maths.

Good to hear it.  But to *USE* Squeak he doesn't have to be able to
*PROGRAM* Squeak.  And if he does program Squeak, he can, for example,
attach behaviour to objects without once encountering a class
declaration.

	Morph are a very good way to explore Arithmetic problems.

That's good.  But Morph is chock full of variables.  Even at the
user interface level, what is a StringMorph but a visible variable?
(I note that Clean, despite being a pure functional language with
no mutable state whatsoever in its semantics, nevertheless manages
to provide a GUI kit that provides the *appearance* on the screen of
boxes that can hold strings which can be changed.  Though you may
expell variables with a pitchfork, they will return.)

	He don't like "strutured" programs like Mathematica

I am not sure what is particularly "structured" about Mathematica
or why your brother is looking at the source code.  The Mathematica
*language* is, um, quirky.  Understanding _Mathematica_ variables is
tricky, but that does not mean that variables in Smalltalk are tricky.

	or to experiencie problems with languajes like Fortran.

I don't like to experience problems with languages like Fortran either.
Although it must be said that modern Fortran has much to commend it;
I'd say that it's easier to get a Fortran 90 program right than the
corresponding C++...  One of the sticks you can beat Fortran with,
of course, is that (due to the fact that some antique computers had weak
and bizarre subroutine calling conventions) it is ambigious about the
lifetime of variables.  Smalltalk is NOT ambiguous about the lifetime
of variables, it as about as clear as it could get.

	think it will be very useful to have:
	
	Morph	subclass: #BioMorph
		objectKnowledge: ' myTarget lastTime ' 
		classMembersKnowledge: ' CloseBoxImage '
		dictionaryOfVocableKnows: 'Colors '
		category: 'Morphic-Samples'!
	
BUT THIS IN NO WAY EXCLUDES THE IDEA OF VARIABLES!

All it does is eliminate the *WORD*.

'myTarget lastTime' are NOT object knowledge, they are VARIABLE NAMES.
'CloseBoxImage' is not the knowledge of some class member, 
it is a VARIABLE NAME.
'Colors' is not a dictionary of vocables, it's a dictionary of
VARIABLES whose values are colours.
The things that an instance "knows" (how pretentious it is to use
"knows" and "knowledge" here; Dijkstra, why did you die when we still
need you?)

"Vocable" is a moderately rare word in English.  The definition
in www.webster.com is "a word composed of various sounds or letters
without regard to its meaning".  "Brekekekek-koash-koash" (the sound
Aristophanes' Frogs make) is a vocable.

Not only is it morally wrong to replace clear technical terms
with gibberish, it is FUTILE to change words when your purported
aim is to eliminate an idea.