Revisiting Decimal (generic algorithms)

Brendan Eich brendan at
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.


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


More information about the Es-discuss mailing list