On Jan 16, 2009, at 5:54 PM, Sam Ruby wrote:
>>http://www.artima.com/weblogs/viewpost.jsp?thread=101605>> 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