# Revisiting Decimal (generic algorithms)

Brendan Eich brendan at mozilla.com
Fri Jan 16 18:16:17 PST 2009

```On Jan 16, 2009, at 5:54 PM, Sam Ruby wrote:

>
> I must be dense.  My previous understanding of multimethods was that
> it depends on the assumption that the type of each argument can be
> determined.  That article doesn't change that for me.

Good! :-P

Not static typing, mind you; but typing nonetheless.

>>> My interpretation is that this means that internally there are three
>>> data types, one that is double, one that is decimal, and one that
>>> somehow manages to be both.  Internally in that this implementation
>>> detail ideally should not be visible to the application programmer.
>>> Again, I could be wrong (in the need for three data types, not on
>>> the
>>> opinion that this should not be visible), but pressing on...
>>
>> No, Allen allowed for that, but of course this generic type has to
>> propagate
>> at runtime through variable and function abstraction.
>
> I don't follow.

My reading of Allen's message was that the generic type was for
literals only, and would collapse (as in a superposed wave function)
into decimal or double on first operational use. but use can be
delayed through variable or parameter assignment. So the generic or
both-double-and-decimal type must be used more widely than just for
literal terms at runtime.

>>> function is_point_one(a) {var b=0.1; return b===a}
>>>
>>> Is the expectation that this would return true for *both* 0.1 and
>>> 0.1m?
>>
>> I don't see how this could work.
>
> Before proceeding, let me simplify that:
>
> function is_point_one(a) {return a===0.1}
>
> The point of "fuzz" was that 0.1 as a literal would be interpreted as
> a binary64 or as a decimal128 based on what it was combined with.  Why
> would this example be any different?

It wouldn't, but that breaks one of three important properties
(referential transparency, compatibility, or implementation
efficiency)  as DSH has pointed out.

>> It should be clear that I won't go this far. My reply to Allen was
>> gently
>> suggesting that his suggestion would not fly on implementation
>> efficiency
>> grounds, but I think you've poked bigger holes. I'm still
>> interested in
>> multimethods, including for operators.
>
> I don't see how this reasonably can be done half way.

Right.

> And while multimethods are appealing for other reasons, I don't think
> they relate to what Allen is suggesting.

They do not -- they are the only sane alternative that I know of.

/be
```