[Grace-core] On numbers and objects

[James Noble]

Kim writes:

> [e-mail delayed by a server outage.]
> Yeah, I was confused about that e-mail as well.

hmm, well this email will be confused by half a bottle of chardonnay...

> I do think we are going to have to make pragmatic decisions like  
> that suggested by Andrew on Booleans.  At the worst case, we can  
> check to see if it is an object from the official Boolean class (I  
> suspect we'll have to have some mechanism like that, alas) and throw  
> an exception if not.

or we can just send it the message "negated" :-)

>>> The hard part is what about constructors for *user-defined value  
>>> types*.
>>> Do they always run? Or run most of the time?  Or run, but then the  
>>> object may be deleted
>>> and replaced with an indistinguishable clone?

so: the point here is that we can have user-defined objects
with all-constant fields (i.e. all fields defined by let).

Compared with EGAL, these will have the same behaviour as
"built in" objects like strings, in that the program will not be able to
tell if there is one share copy or many duplicated copies - its an
implementation issue.   But if their constructors can have side
effects, the program will be able to tell if the constructors
were executed or not.

so that's the issue.

>> Maybe this is the question:  Suppose I write an object constructor  
>> that creates an object (called maybe) whose type conforms to that  
>> of Boolean.   Can I use mabe in an if?
>> The pragmatic answer is "no".  This is a blemish on the language,  
>> because our story is that '''if''' is just a message on an object,  
>> and anything that quacks like a duck is a duck.   The Self answer  
>> is "of course yes", and we would end up standing on our hands  
>> trying to implement it efficiently, just like the Self team did.

that's the Self answer. There is another (more Graceful) possiblity:
yes you can, but we can't be answerable for the speed of your  
program :-)


>> In Emerald we just said that a few basic types can't be  
>> reimplemented by user-defined types.  I think that Boolean should  
>> be one of those.  I think that String should NOT be one of  
>> those.    If we had Nat32 built-in, then it should not be re- 
>> implementable either, but since we have Rational, which will be  
>> slow anyway, allowing re-implementation should be OK.

A serious implementation of Grace (which is a pretty forbidding  
prospect -
assuming you don't follow Mario Wolczko and just translate into self :-)
will use tagging so 31bit integers will be stored directly.
Actually, even on the JVM, there's no reason why using Rational for 32- 
bit
ints values  should much slower than the Integer class (although it may
need rather more space)

J