[Grace-core] On numbers and objects

[Andrew P. Black]

On 9 Nov 2010, at 0:11, James Noble wrote:
> 
> 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.


I don't see that it's an issue at all.  Implementors should follow Dan Ingalls' golden rule: cheat as much as you like, but be sure not to get caught.   If the implementor hashes immutable objects into a table and re-uses an existing object rather than creating a new one, that's just fine.  So long as he makes sure not to get caught, by, for example, making sure that any other effects of the factory method still happen.


>>> 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 :-)
>> 
'
The problem is _not_ that your doing this will slow down your program, but that by me _allowing_ you to do this, I will slow down my program and all other programs, even if they never dream of doing it.


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

If we have a VM, then checking tags is not very expensive.  Maybe that's true on today's hardware on a real machine too.  In which case, whole-number operations on Rationals that happen to be whole numbers should execute as fast as they would on Integers.

	Andrew