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

[Polar Humenn <polar@syr.edu>]

On Mon, 25 Nov 2002, Daniel Engovatov wrote:

> My vote is for <type>-map.
> I have explained some of my rational for this in a previous e-mail.
>
> Most important are - consistency

The proposed naming convention is NOT consistent with the other functions.

The current function names contain the type of their arguments, whereas
the proposed <type>-map names the resultant type.

> and ease of expandability

I really don't know what you mean by "expandability".

> - for the cases when the function name is supplied as an argument that
> has its value determined during the evaluation time.

The function name is supplied EXPLICITLY in the FunctionId attribute of
the <Function> element. It's value is already determined at compile time.
That was the specific reason for the <Function> element.

Now, of course, you can take any IMPLEMENTATION route you chose, such as
using the "interpreter" approach where you might not know its value until
evaluation time, but that is certainly not FORCED by the specification.

>  Not specifying the return type of the enclosing "higher" order function
> would make it extremely cumbersome to define a consistent and optimized
> interface.

One thing that is really frustrating especially over email is that people
make comments like "confusing" and its "extremely cumbersome" but don't
substantiate those claims.

Cheers,
-Polar

>
> -----Original Message-----
> From: Polar Humenn [mailto:polar@syr.edu]
> Sent: Monday, November 25, 2002 1:23 PM
> To: Anne Anderson
> Cc: XACML TC
> Subject: Re: [xacml] straw poll on "<type>-map" or "map"
>
>
>
> My vote is for "map".
>
> Rationale:
>
> 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.
>
> The functionality of "map" is independent of the primitive type of the its
> arguments, where as "integer-equal"  is not, "integer-equals" requires two
> integers as arguments. The function "map" only requires the supplied
> function and the supplied bag to agree on types, no matter what the type
> happens to be. It is truly polymorphic.
>
> I think naming "integer-map" is really confusing as it only states half
> the type story, the rest is left in the air. If you were to fully specify
> the type in the name, you'd have to say something like "integer-float-map"
> for functions that map bags of integers to floats (or visa versa depending
> on how you want it". That would cause an explosion of type names, which is
> unnecessary, because the <Function> argument really specifies the type.
>
> Also, for extension types, the function "map" can easily and with formal
> integrity, be used for any extension type and any other extension
> functions that do conversions or selections of that type.
>
> Furthermore, this "map" function didn't come out of nowhere, it is the
> most popular polymorphic function on the planet. :)
>
> Cheers,
> -Polar
>
> On Mon, 25 Nov 2002, Anne Anderson wrote:
>
> > The list discussion is not coming to any resolution on Comment#
> > 0033.
> http://lists.oasis-open.org/archives/xacml-comment/200211/msg00061.html
> > Subject: map function
> > From: Seth Proctor <seth.proctor@sun.com>
> > Date: Wed, 20 Nov 2002 16:22:32 -0500
> >
> > Since it looks like a vote may be required, but a vote will not
> > be possible until December 5, I would like to take a straw poll
> > to see how the vote is likely to go.  This will allow intrepid
> > implementors to implement "the most likely" outcome now (at some
> > risk of having to change after Dec. 5).
> >
> > This is not an official e-mail vote, and is non-binding: on
> > December 5, we can vote "officially" and your vote can differ
> > from the one you submit to this straw poll.  But if you think you
> > know how you would vote and are willing to post that now, please
> > do.
> >
> > My straw poll vote is: <type>-map
> >
> > Rationale:
> > 1) Consistent with type system implied by every other XACML
> >    function.
> > 2) If we polymorphic output "map", then we should use polymorphic
> >    functions everywhere (i.e. "equal", not "string-equal"
> >    "integer-equal" "boolean-equal", etc.)
> > 3) Makes type checking easier for the user and for the
> >    implementation.
> >
> > Anne Anderson
> > --
> > Anne H. Anderson             Email: Anne.Anderson@Sun.COM
> > Sun Microsystems Laboratories
> > 1 Network Drive,UBUR02-311     Tel: 781/442-0928
> > Burlington, MA 01803-0902 USA  Fax: 781/442-1692
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>