OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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