On 6/10/2011 10:23, Orchid XP v8 wrote:
> On 10/06/2011 04:49 PM, Darren New wrote:
>> On 6/10/2011 8:18, Invisible wrote:
>>> I think Smalltalk will also let you accidentally redefine 3 to mean
>>> something else.
>>
>> I think anything the parser sees is hard-coded, but I could be wrong there.
>
> 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. :-)

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

>> (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. Are you talking about interred 
strings? They're not really *quite* the same thing. FORTRAN only does that 
because most machines existing when FORTRAN was created didn't have 
immediate-mode machine instructions.

-- 
Darren New, San Diego CA, USA (PST)
   "Coding without comments is like
    driving without turn signals."

Post a reply to this message