On 22/10/05, Christian Schulte <[EMAIL PROTECTED]> wrote:
> I am not that convinced after a decade of programming concurrent
> applications (and being the main implementor of Oz and its libraries).
> Anything that matters to the interface of a software artifact in general is
> worth to be explicated. Dataflow variables (variables used in that sense)
> tend to end up on the interface side: here an explicit statement would be
> useful (IMHO). If you are not forced to explicate you are not forced to
> understand what you are doing.
>
> I hate to disagree in principle. Yes, we designed Oz and the design is
> reasonably consistent. Today, I tend to make everything *explicit* (for the
> reason you yourself explicated on).
A convienant notation for marking variables that must be determined
would be a good addition to Oz. IsDet works fine but is not
convienant. I thought of creating one with gump during a project but
was too busy. It would have been useful when dealing with software
components from "outside" the core system. Essentially I didn't want
agents passing in undetermined variables (or determined variables)
where they should not and causing the core system to break, because
agents weren't trustworthy.
Something like...
proc {DoX +A +B -Z} ... end
mapping to
proc {DoX A B Z}
if {IsDet A} andthen {IsDet B} andthen {Not {IsDet Z}} then
...
else
raise invalidArgument end
end
end
The semantics would have been only those of IsDet, and it would still
have left the case of part of a structure being unbound but it would
have helped in most of the cases it was necessary to proceed with a
determined variable. For other cases, IsDet is still available and
allows more fine-grained checking.
Chris
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
