Damien Doligez wrote:

>AFAICT from a quick look at the source, it's more like this:
>
>delete: the binding may or may not be presented subsequently
>add: the binding may or may not be presented
>replace: the binding may be presented with the old or the new data
>value; if it was already presented, it will not be represented
>otherwise: the binding will be presented with its initial data value.
>
Ok: that's perfectly reasonable, it just needs to be documented.

[The replace semantics you describe are unfortunate for me: my unification
algorithm keeps a hashtable of variable -> term bindings into which
I have to incrementally subtitute while iterating through the table.
At present, I'm building a fresh table, but then I have to clear
the original one and copy the whole contents up. I was hoping
to just modify the table in place .. ~2.5 times faster ..]


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners