[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] straw poll on "<type>-map" or "map"
On Mon, Nov 25, 2002 at 04:22:52PM -0500, Polar Humenn wrote: > The primitive functions, i.e. integer-equal, are named with their > arguments' particular type, not their resultant type. If you named > functions for their resultant type, as is suggested with "integer-map" > returning a bag of integers regardless of what its argument type is, then > to be consistent with that naming convention would mean the "equals" > function between integers would be called really be called "boolean-equal" > because equal returns a boolean. And that would lead to inconsistent, not > to mention, nonsensical naming. I think there's been too much emphasis in this conversation on comparing map and type-equal. The better comparison is between map and things like type-one-and-only. The one-and-only functions could have been defined like the map function, operating on any type and returning a single value of the same type, just like map is now defined [1]. Instead, it works on pre-defined types [2]. This is useful because we know specifically what type is being returned by the function, and what type we expect to work with inside the function. There are other type-* functions that are in the same position (think Bag and Set functions), which is why Daniel and I are talking about consistency. Arguably, it could be useful to change all of the type-* functions to be defined like map, so that the generic functionality could be used by any type, but it would require an overhaul of the entire spec, and therefore is inappropriate for now (maybe a 1.1 or 2.0 version) > Furthermore, this "map" function didn't come out of nowhere, it is the > most popular polymorphic function on the planet. :) Those Gallop people check up on everything :) seth [1] In the map function the type it operates on is the return type of the function, and that is indeed the same type it returns. [2] It is relatively easy for an implementation to let new types be used in this system, so it's not hard to extend.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC