![]() Wizard and Szabolcs reasonable points (that also clarified my thinking) to show that in fact this design change is not ambiguous nor does it represent a loss of scope (unlike the current post-10.1 change which for the above reasons is ambiguous). ![]() I think this is a design oversight for the following reason:įirst note (by the same reasoning) the following "redundancy": (n.b, and to also become consistent with let me adress Mr. Consequently, even with an Association containing the key, a, an error message is produced, with the "positive" affect of guiding users to the simpler usage assoc (that is, without the "esoteric" Key key already existing in the Association in which case its value would be returned instead). Hence, the usage assoc] appears redundant and presumably underpins the post V10.1 design decision to interpret it as the literal key, Key, (similar to all other literal key interpretations). The functional assoc key extraction has no indexing precedent so arguments can apparently always be assumed to be literal keys. The implemented disambiguation is to wrap Key over expressions intended to be interpreted as keys with no wrapping required for strings since their key status is implicit.Īt first pass, assoc] doesn't seem subject to such a disambiguating imperative. So while a construction like assoc] traditionally defines the first part of assoc, once keys are allowed to include arbitrary expressions, a potential conflict arises since assoc] can potentially also refer to the value of key, 1. The need for an initial disambiguation involved separating the specification of a part by (traditional) position and by (recently introduced) name. The issue here seems to be one of meta-language and disambiguation with a certain incoherency present with the current semantics. While related to language design, subtlities such as these do impact de-bugging, the selection of apt data structures and internal consistency as a WL Data Science code bases mature. Summary: Yes it is a "bug" and it also suggests changing, #& and KeyTake's key extracting semantics:īackground: A Disambiguating Imperative Emerges: ![]() You would be of course right if you said that using key names which themselves include Key is not a very good idea anyway, but if the language can be designed to avoid ambiguities, I think it is really better to do so. This is what I'd consider a bug instead of wrapped forms not working where only names are expected. Both Lookup, default] and Lookup give 1 even though Key =!= "z". You noticed that Lookup does indeed accept both wrapped and unwrapped keys, and this leads to some strange behaviour. Wizard points it out, how could we even test reliably if a key exists or not? What would asc] refer to? The key "z" or the key Key? As Mr. ![]() (* 5 Missing]] *)Īllowing both wrapped ( Key) and unwrapped names in situations where only key names are expected would lead to ambiguities. These rules will make key handling convenient and unambiguous: asc = 1, 1 -> 2, Key -> 3, "z" -> 4, Key -> 5,ĭuring evaluation of Part::pkspec1: The expression a cannot be used as a part specification. Any other expression is disallowed.įunctions that can only take keys, interpret the key name literally. An exception is strings, which are automatically treated as if they were already wrapped in Key.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |