Hi, Joel
> There are a number of "strange things" in the use of paths; using > I don't understand the purpose of the inconsistencies: > > 1) when to generate an error vs. returning NONE to indicate > data-not-found, and I agree. It is documented, but i do not like it. > 2) the fact that /: performs access-by-position or access-by-key > depending on the type of the second word's value. So we can end with: >> x: 4 == 4 >> a/x ** Script Error: Invalid path value: x ** Where: do-boot ** Near: a/x >> a/:x == none but neither 'x neither 4 are in block. It is like the value was re-evaluated, like it was a refinement of the path itself. Something of recursive evalutation of the get-word in the path: >>a/:s is re-evaluated like it was >>a/value-of-s if value-of-s is integer or decimal (!) -> numeric offset word -> word for select BTW now i understand why the set-word value change the block: >> a: [b 2] == [b 2] >> x: first [b:] == b: >> a/:x 3 == [b 3] is like: >> a/b: 3 == [b 3] --- Ciao Romano -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
