Hi Rob
You could consider using "bounded open records":
declare
proc{CreateBOR Fs Label R}
D={NewDictionary}
in
R={RecordC.tell Label}
for F in Fs do D.F:=unit end
thread
for F in {RecordC.monitorArity R _} do
if {Dictionary.member D F} then
{Dictionary.remove D F}
else
raise invalid_feacture end
end
if {Dictionary.isEmpty D} then R={Record.make Label Fs} end
end
end
end
BOR={CreateBOR [a b] bor}
{Browse BOR}
BOR^a=_ BOR^b=_
This will fix the problem you are mentioning of leaving threads hanging
around (since the record will get closed when all the features has been
added) and take care of the issue of dealing with invalid features
Cheers,
Luis
Robert Van Dam wrote:
I appreciate all the solutions. I had come up with a solution myself
based on some slight modifications to Luis' original reply but without
the need for reflectArity or monitorArity because in my particular
case, I know ahead of time the set of potential branches and so I
created a thread that blocked until that branch was needed. The
downside there of course is that I'll end up with dozens (probably
hundreds) of blocked threads that may never get unblocked. Some of
the later solutions seem like cleaner approaches and so I think I
change to using monitorArity.
As for the issue of creating branches that shouldn't exist, that
actually wouldn't be a big negative in the problem I'm working on
since those branches would just get appropriately terminated as leaf
nodes with no data to store and the results would still be
consistent. I imagine there are other problems where trivial such
leaves are not a problem (assuming of course that the leaves don't so
outnumber the valid branches that you run into problems with the
overall size of the tree). Sometimes its nice to not have to do extra
sanity checking (and sometimes its vitally important :).
Rob
On 3/15/06, *Raphael Collet* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Luis Quesada wrote:
>> P.S. Of course, you could give up on using records and use
objects or
>> functions instead. An object O is more than capable of calculating
>> O(x1) if and only if someone requests it, then caching it for
future
>> use, which is essentially how Robert is trying to use lazy
trees. Or
>> so it seems to me.
>
> What I like of the solution using open records is that it is
> declarative. So, there is no problem when binding several branches
> concurrently.
But your solution has a drawback: you cannot restrict the set of
branches. If the user asks for T^foo, and there is no branch 'foo' in
the tree, you're in trouble. You can actually wrap your solution
behind
a function that checks for valid branches, and never makes the record
public:
fun {MakeTree IsValid Create}
T=tree(...)
in
thread
for I in {RecordC.monitorArity T} do T.I={Create I} end
end
fun {$ I}
if {IsValid I} then T^I else
raise invalidBranch(I) end
end
end
end
You could be even more paranoid, and return !!(T^I). You never
know ;-)
Cheers,
raph
_________________________________________________________________________________
mozart-users mailing list
[email protected] <mailto:[email protected]>
http://www.mozart-oz.org/mailman/listinfo/mozart-users
--
Luis QUESADA
Catholic University of Louvain
Department of Computing Science and Engineering
Place Sainte Barbe, 2
B-1348 Louvain-la-Neuve, Belgium
Phone: (++32) (10) 47 90 13
Fax: (++32) (10) 45 03 45
Web: http://www.info.ucl.ac.be/~luque
_________________________________________________________________________________
mozart-users mailing list
[email protected]
http://www.mozart-oz.org/mailman/listinfo/mozart-users
