Re: [xacml-comment] Public Comment

[Polar Humenn <polar@syr.edu>]

Haruyuki-san,

n Fri, 12 Nov 2004, Haruyuki Kawabe wrote:

> The background of my comment is as follows:
>
> In some programming languaces based on functional evaluation
> such as Common Lisp, it is specified that prior to applying a function,
> all of its argument should be evauated.

That evaluation strategy is called "pass-by-value", and is indeed what
many common programming languages have today.

> But AND and OR are not obeyed the rule, so they are called as "Special
> Form" and distinguished from (normal) functions.

First of all in Common lisp, "and" and "or" are macros. However, one may
think of them as "special-forms". As such, (AND and (OR, and (COND are
syntactic "forms" of the language (i.e. "control-structure" as Guy Steele
writes it), much like "if-then-else" of C, Pascal, Java, etc. They are
only modeled as S-Exp, and are indeed called F-exp (in the older MIT
terminology). Therefore, the (FUNCTION 'AND) is not a valid construct (I
think in Common List it would be written as #'and), as AND, OR, and COND
are not first class objects in LISP.

> And higer order functions such as MAP could not take a special form as
> its functional argument.

You are correct, as the following:

	(MAP (FUNCTION 'AND) (LIST t nil t))

is not valid. However, there is nothing preventing you from writing:

(defun myAND (list)
	(COND ((NULL list) [])
              (AND (CAR List) (myAND (CDR list)))

and use it in

	(MAP (FUNCTION 'myAND) (LIST t nil t))

     (Note: this expression maps 'AND to each element in the list. It is
            not a list reduction).

However, in Common Lisp, I believe, this expression does force the "list"
argument to map to be fully evaluated to [t,nil,t] before MAP can be
applied.

> As for policy evaluation of XACML, it permits lazy evaluation
> but it is still true for all functions except AND, OR and N-Of that the
> arguments have to be evaluated prior to applying a function since all of
> them need the result of evaluation of their arguments to compute their
> result (i.e. return value.)

In XACML the type of the "and" function is:

AND:: Boolean* -> Boolean

(the "*" type suffix means an arbitrary number of arguments of that type)
takes an arbitrary number of Boolean arguments and returns a Boolean.
Therefore expressions such as:

(AND True False)
(AND True False True)

are valid.

Hence, in the higher order functions such as map.

(MAP (Function AND) [true])

is also valid, and type correct.

As map is defined as:

map:: (a -> b) -> [a] -> [b]
map f [] = []
map f (x:xs) = (f x) : (map f xs)

The type (Boolean* -> Boolean) maps correctly to the type (a -> b)

The above expression has its declarative expansion as the following:

(AND True): map (Function AND) []

(AND True) : []

True : []

[True]

i.e. is a list containing one element of True, i.e. [True].

> So I recommend that above three logical functions SHALL NOT be specified
> as the functional argument of higer order functions.
> It makes the evaluation process of policies clearer.

I think the only problem you really have with this if you take the
"pass-by-value" strategy for *all* functions. Then, in order to maintain
some sanity to the evaluation process, as is taken in Common Lisp, you
must take the view that IF, AND, OR, and N-OF are "special-forms" of the
language control structure.

If you take that view, then in XACML when you write

	<Function "...:and"/>

to pass to a higher order function, you can effectively notice it as your
"special-form" and apply the appropriate function implementation (which
will require all its arguments to be evaluated first).

Also, since you take the strategy that all arguments must be evaluated
before passed, this will not present a problem, since <Function "...:and">
as an argument needs to be "evaluated", and that takes a name and
*evaluates* it to a function that may be applied in a higher order
function.

> >A particular implementation may be extremely lazy in it evaluation.  For
> >instance, imagine a function F that takes three arguments, a boolean b and
> >two integer expressions, A and B, (F b A B). The function F returns the
> >"expression"  of A (not the evaluation) if the first argument evaluates to
> >True, otherwise it returns the "expression" of B (not its evaluation). The
> >only thing that needs to get evaluated is "b".
> >
> >Now, evaluate the expression (F False (F b A B) 3). You will find out that
> >the expression (F b A B) will not even be attempted to be evaluated.
> >
> >However, you will notice that if your implementation chooses to evaluate
> >all the arguments, you will still get the same answer. (i.e. 3).
> >
> >Cheers,
> >-Polar
> >
> >
> As for your special function F,  is it convinient if <type>-if's are
> introduced
>  into XACML functions ? For examle,
>
> - urn:oasis:names:tc:xacml:2.0:function:integer-if
>     This function SHALL take an argument of  data-type
>     "http://www.w3.org/2001/XMLSchema#boolean"; as the first argument
>     and "http://www.w3.org/2001/XMLSchema#integer"; as the second and
>     third arguments. If the first arguement evaluate to "True", then the
>     result is the evaluated value of the second argument. Otherwise
>     the result is the evaluated value of the third argument.
>
> It is worth mentioning that IF is one of special functions in Common Lisp.

Well, it doesn't need to be datatype specific. But, Hmm, we don't have a
polymorphic "if-then-else" function? Really? If we don't, we should
probably have one.

- urn:oasis:names:tc:xacml:2.0:function:if-then-else
    This function SHALL take three arguments. The first argument
    SHALL be of the
   "http://www.w3.org/2001/XMLSchema#boolean"; datatype.
    The second and third arguments SHALL be of the same datatype. If the
    first argument evaluates to "True", then the
    result of the application of this function SHALL be the second
    argument. If the first argument evaluates to "False", then the result
    SHALL be the third argument. If the first argument evaluates to
    Indeterminate, the value of the application of this function SHALL
    be Indeterminate.


Really? It's not there? Hmmm.

Cheers,
-Polar



>
> Haruyuki Kawabe
> Haruyuki.Kawabe@unisys.co.jp
>
> >
> >
> >>If the XACML specification allows such a usage, it should be noticed.
> >>
> >>
> >>
>
>