>> I did something like define a method that returns #[1 2 3], and then I
>> took
>> the result and manipulated it. To my surprise, the method now returns the
>> new, manipulated value, instead of what it claims to return. (!)
>>
>> Apparently you shouldn't do that.
>
> Especially not in a functional language? That's exactly the sort of
> thing a pure functional language is guaranteed not to do. :-)

Yeah, well, Smalltalk is no functional language. ;-)

>> You can define a new number type, and have it implement arithmetic any
>> way
>> you desire. This works because "2" is not an integer. It's a number. It's
>> *any* number type.
>
> I see. So it's not really the integer 2, but the lexical symbol 2 that
> you're talking about.

Basically, yes. I can make it so that when you type an integer or a 
decimal, it resolves to something utterly unexpected.

Of course, monads let you do strange things to what look like simple 
imperative statements. (E.g., time travel, quantum superposition, etc.) 
Strangely, the Haskell list syntax is so hard-wired that you can't touch 
it, however.

>>> (I.e., in most fortran implementations, "3" refers to
>>> an anonymous global variable that holds the value "3".)
>>
>> Isn't that almost exactly what Smalltalk does with [at least] class
>> names?
>
> I'm not sure what you're talking about.

When you define a class named Foo, it defines a global variable named 
Foo which contains a Class object describing the class.

The fun thing is, since True and False are classes, they are also global 
variables, and you can do something like True := 42, which utterly 
confuses everything.

Then again, Smalltalk := Nil is always fun...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message