Luis Quesada wrote:
Maximilian Wilson wrote:
>
>I don't understand. What do you gain from wrapping the FOR loop in
>another thread? This code seems to bind each field of T to a lazy
>value, but only for fields which exist at the time the FOR loop is
>started (since reflectArity doesn't update itself). When I run this
>code, about half the time I get "tree(...)" and half the time I get
>"tree(x1:'branch'#x1 ...). (It's nondeterministic because
>reflectArity's result depends upon whether {Wait T^x1} has already
>executed.)
Sorry, I meant RecordC.monitorArity.
thread
for Id in {RecordC.monitorArity T _ }do
T.Id={CreateBranch Id}
end
end
>
>Executing T^R = Val makes R needed (but not Val), so you can use ^ to
>create lazy field values but not lazy features. As far as I know
>there's no way to make a record create new features only as they are
>called. Of course I would be pleased to learn if there was a way...
>
The idea is that feature F becomes one of the features of T the first
time T^F is applied.
At that moment, the for will execute the
corresponding T.Id={CreateBranch Id} since the outgoing stream is
updated by RecordC.monitorArity.
The thread is needed because the list returned by RecordC.monitorArity
only gets determined when all the features of the open record are known
(i.e., when the open record is a normal record). So, the for will finish
only after that moment.
Luis
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
