Re: [xacml] straw poll on "<type>-map" or "map"

[Polar Humenn <polar@syr.edu>]

On Tue, 26 Nov 2002, Seth Proctor wrote:

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

That is true. One-and-only can be polymorphic, and I certainly would NOT
complain if it were. However, the name is consistent with the other naming
convention is that the <type> in the name, names its argument. It is only
coincidence that it also names its return type as well.

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

The other functions, especially the set functions use an implicit
"type-equal" function in the reduction of the set. That is why the set
functions contain the type name.

As for the "type-bag", "type-one-and-only", "type-bag-size" functions, I
would be very happy if they were polymorphic as well. The type is pretty
meaningless to their functionality. However, the function "type-is-in"
calls an implicit function "type-equal" to handle the membership
determination. So, it can be said that it is needed.

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

Arguably, we could eliminate most of the "typing" information because it
could be deduced by the type system, especially since every attribute
value and designator has a required DataType XML attribute, but we've
already been down that route.


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

Not so. In the map function, the "type" it "operates on" is the argument
type of the given function not the resultant type.

The given function takes an arguement of type "a" and returns an item of
type "b". The map function converts every memeber of a bag of type "a" to
a bag of type "b". It is only a coincidence if the resultant type is the
same type as the argument type, i.e. a = b.

> [2] It is relatively easy for an implementation to let new types be used in
>     this system, so it's not hard to extend.

That is an implementation issue. I have a system for which "map" can
operate on any type, old or newly introduced. I don't have to create a new
map function for the new type.

-Polar