From: SourceForge.net <no...@so...> - 2012-12-31 18:51:38
|
Bugs item #3598385, was opened at 2012-12-24 10:37 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3598385&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 16. Commands A-H Group: current: 8.6.0 Status: Open Resolution: Wont Fix Priority: 5 Private: No Submitted By: Poor Yorick (pooryorick) Assigned to: Donal K. Fellows (dkf) Summary: [dict exists] doesn't produce an error for non-dict values Initial Comment: set data {one 1 two}; dict exists $data one ;# -> 0 ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-31 10:51 Message: To add to pooryorick's arguments, a natural source of odd-length lists is the typo [dict get d $k] (should be "$d"). This typo is likely to occur because the dict API mixes both styles (for good reasons). But the net result of the Jan-2012 commit is that this case will NO LONGER raise an error. Instead, it will just silently behave as though the dict had been emptied (ie return 0 for all keys). For this frequent case at least, it looks to me like an obvious regression. ---------------------------------------------------------------------- Comment By: Poor Yorick (pooryorick) Date: 2012-12-31 08:12 Message: Donal says he hasn't seen a compelling reason to revert. In the case that led to this report, a function wanted to assume that its argument was a dict, and when it wasn't, it took some development time to trace back to the fact that the "type" of the argument was invalid in the first place. Perhaps Donal could explain how "will this [dict get] work" is actually the operation of greatest practical utility. It seems to me that any programmer asking about the existence of a key in a dict would be surprised if that dict wasn't actually a dict, and would want to know about it via an error message in order to fix the problem in the program logic. Also, doesn't [dict exists], like the other [dict] commands, have to convert the value to a dict first, and at that point, wouldn't there be an opportunity to raise the standard "missing value to go with key" (I'm now used to that verbiage as meaning the dict is invalid) error? Regarding [string is...], maybe it should be promoted to [is], and given some mechanism for extension. But I digress. ---------------------------------------------------------------------- Comment By: Joe Mistachkin (mistachkin) Date: 2012-12-26 15:53 Message: How about an alternative suggestion. Let's add 'string is dict' and leave the current dict exists behavior alone? ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-26 11:09 Message: OK, here's my reasoning: Turning a tristate (bool + error) into a boolean loses information: what's gained by this intentional loss ? Given a tristate, a simple [catch] restores the simple yes/no behavior that seems to be so important. While with the current state, the accidental un-dictness of a value is silently disguised as an empty dict. Would you advocate for [lsearch] to just return false when SetListFromAny fails ? ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-12-25 16:15 Message: I've also yet to see a compelling reason to revert. Not closing yet, but tending to a "won't fix" as I'm not convinced that thrashing back and forth between these two behaviors is a good idea at all. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-12-25 16:12 Message: When we had it the other way, people also grumbled. Right now, [dict exists] answers the question "will this [dict get] work?" and that is the operation of greatest practical utility. The problem is that when you get into nested dictionaries, the cases become extremely difficult to tell apart. At the C level, I can tell that the lookup fails. I can't tell the deep reason why this is the case: did someone get the path wrong, or did they get the value wrong in the first place? Two cases (according to whose mistake it was) that you might possibly want distinguished, but the information to do that isn't there with the type of type system that we have. All we have is that it didn't work (with potentially some information in the error that *might* track it down, if it is from a useful perspective; that's the info that is dropped in [dict exists]). I suppose the error message "missing value to go with key" could be improved. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-24 17:28 Message: For the record, the commit "fixing" the bug you mentioned is 22ec97b057 . Donal, I really don't buy that move. It does comply to an unclear documentation, but in the most surprising way, by freezing into law what is only the most counterintuitive of the possible interpretations :} Please please consider reverting: as pooryorick rightfully points out, this leads to very hard-to-track bugs, for a dubious benefit... or am I missing a big thing ? ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-24 16:58 Message: Hmm, I suddenly realize the meaning of this error message "missing value to go with key": it does not refer to the key arg passed to [dict get], but to the odd list element... So it is just a cryptic form of "value is not a dict" ;) So, back to your suggestion, I agree that letting [dict exists] ignore the ill-formedness of the dict is just plain wrong. I'd vote for a fix with a marked POTENTIAL INCOMPATIBILITY as soon as 8.0.1. But that's Donal's realm, let him decide. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-12-24 16:30 Message: I agree with your intuitions. However, I wonder whether there was a change between 8.5 and 8.6 in this area: both tips from 8.5 and 8.6 branches yield: % set x {1 2 3} 1 2 3 % dict get $x 1 missing value to go with key Clearly, as you suggest, something like "value is not a dict" would seem better. Definitely for novem; unsure about 8.x. Donal ? ---------------------------------------------------------------------- Comment By: Poor Yorick (pooryorick) Date: 2012-12-24 11:02 Message: set data {one 1 two}; dict exists $data one ;# -> 0 ---------------------------------------------------------------------- Comment By: Poor Yorick (pooryorick) Date: 2012-12-24 11:01 Message: doc for [dict exits] states "This returns a true value exactly when dict get on that path will succeed", so I think the fix in 3475264 was to make behaviour conform, to the documentation. But even as currently written, the documentation could allow for an error if a if a key is checked in a value which isn't a dict ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3598385&group_id=10894 |