>
>> In special, a pattern like
>> l(F:V ...) would be intrinsically non-deterministic, don't you think?
>>
> Perhaps you should first explain what 'intrinsically non-deterministic'
> means to you.
Well, F:V might match against any feature-value pair. Of course you might
impose the standard arity order there, but I cannot really see why you
would want that. If you intend to process each feature-value pair that way
(much like taking the head of a list) that would be most unadvisable. You
would generate a series of record "types" (i.e. different arities by using
Record.subtract), which is really not healthy memory-wise.
In other words, your proposal seems to cater for exactly those cases where
it is advisable to use Record.toListInd, Arity, Record.forAllInd and so
on.
By the way, the case statement supports some of the cases you stated in a
less graceful manner. For example:
----------------
declare
proc {Test X}
case X of
l(...) andthen {Width X} == 1 then
F = {Arity X}.1
in
{Browse F#X.F}
[] l(...) andthen {Width X} > 1 then
F = {Arity X}.1
in
{Browse F#X.F}
{Test {Record.subtract X F}}
[] Rec andthen {IsRecord Rec} andthen {HasFeature Rec f} then
{Browse f(Rec.f)}
else {Browse nothing} end
end
{Test l}
{Test l(a:1)}
{Test l(2 b:3)}
{Test k(f:3)}
-----------------------
Cheers,
Jorge.
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
