[Grace-core] On numbers and objects

James Noble kjx at ecs.vuw.ac.nz
Tue Nov 9 03:42:44 PST 2010


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

sure - but (as with Booleans) - there are choices we can make that  
makes things easier or otherwise.

In this case, we'd have the option of requiring e.g. a primitive  
constructor
(perhaps the automatic "new" you proposed) not have any side effects.

Alternatively, we can always do a constructor and always do any side  
effects
(even if the object ends up hashconsed)

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

right... so we can always fall back on the argument that we don't care  
about efficiency -
or at least say that programs that do this no longer use the standard  
prelude or something.
>
> 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.

so I hope! But really I don't want to be tied to a particular VM.

Where our choices make things difficult is e.g. JavaScript which I  
think has *only* floats.
(although there do seem to be arbitrary precision libraries for  
JavaScript too)

James


More information about the Grace-core mailing list