Es-discuss - several decimal discussions
Mark S. Miller
erights at google.com
Sun Aug 24 22:02:54 PDT 2008
On Sun, Aug 24, 2008 at 9:48 PM, Brendan Eich <brendan at mozilla.org> wrote:
> On Aug 24, 2008, at 7:57 PM, Mark S. Miller wrote:
>> Given a
>> function F that one knows is functional, it should be possible to
>> write memoize such that memoize(F) acts like F, trading space for
>> time. Without Object.eq or the equivalent, how does memoize tell
>> whether its got a cache hit or miss?
> We had this in the ES4 RI, implemented in ES4 (builtins/Map.es). The Map
> class takes type parameters K and V and has a constructor:
> function Map(equals = (function (x,y) x === y),
> hashcode = intrinsic::hashcode)
> NaNs all hash to code 0 (any constant would do, 0 was picked for simplicity
> and interoperation). You have to avoid mapping NaN or else provide a
> non-default equals function that tests isNaN() or x !== x.
Let's say you did that -- make a special case for NaN but not for -0.
Let's say you use this Map to build memoize. Now let's say someone
writes a purely functional function F such that F(0) is 3 and F(-0) is
7. Let's say G is memoize(F). Would you find it acceptable for G(0) to
sometimes yield 3 and sometimes 7?
> Ignoring the ES4 details (type parameters, default arguments), there's
> nothing here that adds a new equality operator to the language as a whole.
> Anything like Map in Harmony, sans distinct type parameters (any such would
> be value parameters), could do likewise. No need for an Object.eq analogue.
Once you fix your Map defaults to distinguish 0 and -0, what you've
done here is implemented Object.eq easily using ===. Good. So long as
that's practical, I agree we don't need to codify a built-in
Object.eq. But if the introduction of decimal means that it is no
longer practical to build Object.eq from ===, what then? Perhaps we
can avoid facing that dilemma?
More information about the Es-discuss