4 ms·

> For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement I think this may

by bch 9y ago

> For example, a “line number” isn’t much help if the “line” refers to 90% of the file and Tcl thinks all of that is essentially one statement I think this may have improved since you last looked: $ cat j #!/usr/bin/env tclsh puts [ set a [ expr { 9 + [set x]}]] $./j can't read "x": no such variable while executing "set x" invoked from within "expr { 9 + [set x]}" invoked from within "set a [ expr { 9 + [set x]}]" invoked from within "puts [ set a [ expr { 9 + [set x]}]]" (file "./j" line 3) > there are tons of places where a variable is referenced both like "$this" and "this" $this is essentially [ set this ], returning its value, or deferencing the value, if you will. The entire set of rules that Tcl abides by are contained entirely in a small document (here [0], with commentary). It's really not difficult to figure out. [0] http://wiki.tcl.tk/10259 http://wiki.tcl.tk/10259

makecheck 9y ago
That trace is not as bad as I remember but if you write that in a nice long multi-line series of if-statements (say) it’ll still print out the whole mess and only tell you one useless line number. If there’s a "proc" it’s a little better but it can only show the bad line number relative to the "proc", requiring you to do some manual work to find the function within the file and then the offending statement line. Also, I have no problem with the logical "$x" syntax; rather, the fundamental flaw is that the string "x" could be used to change the variable "x" without any clue in the syntax that this may happen (e.g. no "&x" like in C, no "\$x" like in Perl; just "x", or worse "$y" that resolves to "x"). And don’t even get me started on multi-level "upvar". This whole thing is a minefield, especially if people use simple variable names that can’t be searched in a code base. If you’re really unlucky, you accidentally swap the order of parameters and it just so happens that your "$x" value is almost plausible so you never notice the disaster you just created. It’s simply a “write once, modify never” coding style: it saves the programmer 10 seconds and creates the most brittle of code. I would never recommend it to anyone.
KasianFranks 9y ago
Why would you set a var to null in a language that expects a string every time you invoke set to null?

by bch 9y ago

makecheck 9y ago

That trace is not as bad as I remember but if you write that in a nice long multi-line series of if-statements (say) it’ll still print out the whole mess and only tell you one useless line number. If there’s a "proc" it’s a little better but it can only show the bad line number relative to the "proc", requiring you to do some manual work to find the function within the file and then the offending statement line. Also, I have no problem with the logical "$x" syntax; rather, the fundamental flaw is that the string "x" could be used to change the variable "x" without any clue in the syntax that this may happen (e.g. no "&x" like in C, no "\$x" like in Perl; just "x", or worse "$y" that resolves to "x"). And don’t even get me started on multi-level "upvar". This whole thing is a minefield, especially if people use simple variable names that can’t be searched in a code base. If you’re really unlucky, you accidentally swap the order of parameters and it just so happens that your "$x" value is almost plausible so you never notice the disaster you just created. It’s simply a “write once, modify never” coding style: it saves the programmer 10 seconds and creates the most brittle of code. I would never recommend it to anyone.

KasianFranks 9y ago

Why would you set a var to null in a language that expects a string every time you invoke set to null?