From: SourceForge.net <no...@so...> - 2012-08-02 22:21:05
|
Bugs item #3553586, was opened at 2012-08-02 04:47 Message generated for change (Comment added) made by ferrieux You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3553586&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: 18. Commands M-Z Group: obsolete: 8.5.10 Status: Closed Resolution: Invalid Priority: 5 Private: No Submitted By: Jean-Marie Cuaz (jmcuaz) Assigned to: Don Porter (dgp) Summary: Wrong argument to return command doesnt return error Initial Comment: In a proc we did the following mistake: return expr {[dict exists $dict $key] ? [dict get $dict $key] : 0} wich ought to be : return [expr {[dict exists $dict $key] ? [dict get $dict $key] : 0}] The surprise is that the execution of the faulty code returns an empty string and not an error. It might be that the 2nd word "epr" has been intrepreted as an option argument for the third form of return syntax (i.e. return ?option value ...? ?result?), but shoudn't any option begin with a dash ? On an other (but related) subject, the doc is not very clear about the differences betwen the 2nd (i.e. return ?-code code? ?result?) an third form (return ?option value ...? ?result?) of the syntax of return command : are each form exclusive from the other or can they be mixed together as shown in the examples witten in TIP 90 ? Many thanks Jean-Marie ---------------------------------------------------------------------- >Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-08-02 15:21 Message: Yes, of course I'm not against the whole of TIP 90, which is no less than the completion of the promise that every language construct is first-class... And yes I admit that the current report falls under the "works as documented" rule. It's just that the bit about relaxing -OPTION to ANYTHING was unwarranted overgeneralization. Sadly, this has been the case for so long that it is clearly too late to do anything about it. ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-08-02 14:03 Message: We most surely do not wish to remove the whole of TIP 90. But this is leaving the domain of bug reports. Open a FRQ or write a TIP if you really wish to pursue this; formally, it's currently Not A Bug as it is exactly intended behavior. ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-08-02 09:54 Message: That's a regrettable TIP. I'm sure none of us has ever seen, nor will ever see, code using a return option not prefixed by a dash; while the failure scenario reported here is very common, and goes out of reach due to this move. What about a TIP "-90" ? ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2012-08-02 07:22 Message: Not a bug. [return] accepts any string as an option, for maximum freedom in use by extensions and packages. As proposed (TIP 90) and documented "any values at all are acceptable" ---------------------------------------------------------------------- Comment By: Alexandre Ferrieux (ferrieux) Date: 2012-08-02 07:12 Message: The generated bytecode for "return a b" is interesting: % proc f {} {return a b} % ::tcl::unsupported::disassemble proc f ByteCode 0x0x83a0d28, refCt 1, epoch 5, interp 0x0x834a770 (epoch 5) Source "return a b" Cmds 1, src 10, inst 14, litObjs 2, aux 0, stkDepth 2, code/src 0.00 Proc 0x0x83ba258, refCt 1, args 0, compiled locals 0 Commands 1: 1: pc 0-12, src 0-9 Command 1: "return a b" (0) push1 0 # "" (2) push1 1 # "a b" (4) returnImm +0 1 (13) done ---------------------------------------------------------------------- Comment By: Donal K. Fellows (dkf) Date: 2012-08-02 07:05 Message: assign to the master of the rewritten [return] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3553586&group_id=10894 |