From: Trevor D. (Twylite) <tw...@cr...> - 2012-12-13 13:39:21
|
Hi, On 2012/12/13 03:16 AM, Colin McCormack wrote: > I've not been following this too closely, but I get the impression that > proponents of this evolution are primarily interested in making exprs > look better. > > You could always alias = to expr, and then write: > > [= {expression text}] > > Is that not pretty enough? No ;) The motivation (for me at least) is a combination of terseness and reducing the likelihood of incorrect application. We (should) all know that "expr 1 + $a" is unsafe if $a can originate from outside the source code, yet unbraced use of [expr] is still common. Using "alias {} = {} expr" doesn't fix this, nor even "proc = {exp} { expr $expr }" (you could still use [= 1+$a] which is unsafe). To avoid double-substitution we have to introduce new syntax. The big question is whether the syntax should be allowed to break existing code. {=}{...} doesn't break existing code, but it's also not intuitive. (...) is intuitive (it's already used to group sub-expressions in an expression) but will break some existing code. Terseness and prettiness are closely related, and can be illustrated using inline computation of indices or coordinates: string range $buffer [expr {$pos-2}] [expr {$pos+10}] string range $buffer ($pos-2) ($pos+10) string range $buffer $($pos-2) $($pos+10) string range $buffer {=}{$pos-2} {=}{$pos+10} On 2012/12/13 03:04 PM, Andreas Leitgeb wrote: > Making exprs look better requires one step that's more controversial > than aliasing "expr": namely getting rid of one "enclosement"-level: > a typical expression use involves both, braces and brackets around the > actual expression. That's probably, why even {=}{...} is perceived as > a win by some: while it's just 4 chars saved, two of them are the brackets. I think the prettiness argument (saving brackets) is less relevant than the correctness argument. {=}{...} doesn't permit accidental or subversive evaluation of a variable. Regards, Twylite |