[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] Public Comment
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. > >> > >> > >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]