[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