4 ms·

I agree, ^{} is fairly inadequate to delimit a function.

masklinn 15y ago
Likewise. Why the hell did they get a syntax shoehorned into C for a language which does not have such constraints? If they wanted "smaller" lambdas, why not use e.g. C#'s syntax? Or Scala's? Also, implicit scoping => yet an other broken language. Not worth looking at.
- tomp 15y ago
  May I ask, why is implicit scoping bad? I think it is very good for a dynamically typed language, where variables do not need to be declared beforehand. What other solution do you propose? Demanding all variables are declared? That's a very good idea, but it goes against the spirit of javascript and other dynamic languages.
  - masklinn 15y ago
    > May I ask, why is implicit scoping bad? I think it is very good for a dynamically typed language, where variables do not need to be declared beforehand. After extensive experience with it in Python and Ruby, I don't. It's just too prone to typos and broken scoping to be worth it. > What other solution do you propose? Demanding all variables are declared? yes. > That's a very good idea, but it goes against the spirit of javascript and other dynamic languages. No it does not. * Javascript has explicit scoping, it's mandatory in strict mode (ES5) and extensions add even more flexible scoping methods (e.g. `let` in Mozilla's JS 1.7[0]) * Likewise with Perl under `use strict` * Or even in VB and VBScript using Option Explicit * Smalltalk mandates declaring local variables * Scheme (and more generally lisps) make extensive use of `let`-type blocks Dynamic typing and implicit scoping are entirely orthogonal, and I truly find no value whatsoever in implicit scoping: it's a hindrance in every situation, and it helps in none. [0] https://developer.mozilla.org/en/New_in_javascript_1.7#Block_scope_with_let_(Merge_into_let_Statement) https://developer.mozilla.org/en/New_in_javascript_1.7#Block...
    - jashkenas 15y ago
      To give the counter-argument some weight: I disagree, wholeheartedly. Explicit variable declaration is a throwback inherited from statically-typed language, where a variable's type must be declared before use, and has no place in a dynamic language. > It's just too prone to typos and broken scoping to be worth it. Predeclared variables are just as prone to typos, which will also break your code -- and just as prone to broken scoping. By accidentally shadowing an external variable you make it unreachable for the remainder of the current function, and all nested functions within. Clearly, declaring the type of a variable is not necessary in a dynamic language, so the only purpose of a variable declaration is to manually mark it's scope, shadowing any potential name conflict. There are no situations where shadowing a variable is desirable. It's always best to be able to reach any variable that exists in the current lexical scope, should you find the need. The only ambiguous situation in which you'd want to use a "var" on purpose is to explicitly shadow an external variable of the same name -- if you accept that shadowing is undesirable, and choosing a more descriptive name for the inner variable is preferable, then QED. Dynamic languages should not have variable declarations.
      - masklinn 15y ago
        > Predeclared variables are just as prone to typos, which will also break your code Not so: declaring variable name & scope ensures immunity to the "I wanted to change this variable, but I'm creating a new one instead", and this can be checked statically even in dynamically typed languages. > There are no situations where shadowing a variable is desirable. While I do not agree with this assertion, I can see where you come from and explicit scoping is still superior to implicit for this: if there are no situation where shadowing is desirable, you can make the language statically forbid shadowing. There, done. > It's always best to be able to reach any variable that exists in the current lexical scope, should you find the need. It is not, however, desirable to reach and unknowingly alter an existing variable in an ancestral lexical scope when you did not mean to and just happened to pick an existing name in a callback 2-levels down the stack. The result of this is silent corruption of program state, and it is a risk in any implicitly-declared scoping system with mutable bindings. > The only ambiguous situation in which you'd want to use a "var" on purpose is to explicitly shadow an external variable of the same name -- if you accept that shadowing is undesirable, and choosing a more descriptive name for the inner variable is preferable, then QED. Then QED nothing, since as I pointed out it is perfectly possible to make variable shadowing statically illegal, ensuring that no variable is hidden and no variable is silently reused or replaced either. > Dynamic languages should not have variable declarations. Nope. Furthermore, explicit scoping significantly increases readability and lowers cognitive burden: readers don't have to wonder whether a given assignment is local to the current lexical scope, it's spelled out for them. And if it's a bare assignment (not a new variable), explicit scoping makes it easier to find out where the variable is first used. Not to mention it allows the language to protect against in-scope reuse (in cases of debatable-quality imperative code with scopes more than a screenful long), as the second declaration may (and generally will) be statically marked as the redeclaration of an existing variable, and will be refused by the language's runtime. And all of that for the cost, in most languages, of 3 characters. Almost nothing. All the issues you mentioned (since you didn't mention typing) are not issues of explicit scoping but with specific implementations thereof.

Likewise. Why the hell did they get a syntax shoehorned into C for a language which does not have such constraints? If they wanted "smaller" lambdas, why not use e.g. C#'s syntax? Or Scala's? Also, implicit scoping => yet an other broken language. Not worth looking at.

tomp 15y ago
May I ask, why is implicit scoping bad? I think it is very good for a dynamically typed language, where variables do not need to be declared beforehand. What other solution do you propose? Demanding all variables are declared? That's a very good idea, but it goes against the spirit of javascript and other dynamic languages.
- masklinn 15y ago
  > May I ask, why is implicit scoping bad? I think it is very good for a dynamically typed language, where variables do not need to be declared beforehand. After extensive experience with it in Python and Ruby, I don't. It's just too prone to typos and broken scoping to be worth it. > What other solution do you propose? Demanding all variables are declared? yes. > That's a very good idea, but it goes against the spirit of javascript and other dynamic languages. No it does not. * Javascript has explicit scoping, it's mandatory in strict mode (ES5) and extensions add even more flexible scoping methods (e.g. `let` in Mozilla's JS 1.7[0]) * Likewise with Perl under `use strict` * Or even in VB and VBScript using Option Explicit * Smalltalk mandates declaring local variables * Scheme (and more generally lisps) make extensive use of `let`-type blocks Dynamic typing and implicit scoping are entirely orthogonal, and I truly find no value whatsoever in implicit scoping: it's a hindrance in every situation, and it helps in none. [0] https://developer.mozilla.org/en/New_in_javascript_1.7#Block_scope_with_let_(Merge_into_let_Statement) https://developer.mozilla.org/en/New_in_javascript_1.7#Block...
  - jashkenas 15y ago
    To give the counter-argument some weight: I disagree, wholeheartedly. Explicit variable declaration is a throwback inherited from statically-typed language, where a variable's type must be declared before use, and has no place in a dynamic language. > It's just too prone to typos and broken scoping to be worth it. Predeclared variables are just as prone to typos, which will also break your code -- and just as prone to broken scoping. By accidentally shadowing an external variable you make it unreachable for the remainder of the current function, and all nested functions within. Clearly, declaring the type of a variable is not necessary in a dynamic language, so the only purpose of a variable declaration is to manually mark it's scope, shadowing any potential name conflict. There are no situations where shadowing a variable is desirable. It's always best to be able to reach any variable that exists in the current lexical scope, should you find the need. The only ambiguous situation in which you'd want to use a "var" on purpose is to explicitly shadow an external variable of the same name -- if you accept that shadowing is undesirable, and choosing a more descriptive name for the inner variable is preferable, then QED. Dynamic languages should not have variable declarations.
    - masklinn 15y ago
      > Predeclared variables are just as prone to typos, which will also break your code Not so: declaring variable name & scope ensures immunity to the "I wanted to change this variable, but I'm creating a new one instead", and this can be checked statically even in dynamically typed languages. > There are no situations where shadowing a variable is desirable. While I do not agree with this assertion, I can see where you come from and explicit scoping is still superior to implicit for this: if there are no situation where shadowing is desirable, you can make the language statically forbid shadowing. There, done. > It's always best to be able to reach any variable that exists in the current lexical scope, should you find the need. It is not, however, desirable to reach and unknowingly alter an existing variable in an ancestral lexical scope when you did not mean to and just happened to pick an existing name in a callback 2-levels down the stack. The result of this is silent corruption of program state, and it is a risk in any implicitly-declared scoping system with mutable bindings. > The only ambiguous situation in which you'd want to use a "var" on purpose is to explicitly shadow an external variable of the same name -- if you accept that shadowing is undesirable, and choosing a more descriptive name for the inner variable is preferable, then QED. Then QED nothing, since as I pointed out it is perfectly possible to make variable shadowing statically illegal, ensuring that no variable is hidden and no variable is silently reused or replaced either. > Dynamic languages should not have variable declarations. Nope. Furthermore, explicit scoping significantly increases readability and lowers cognitive burden: readers don't have to wonder whether a given assignment is local to the current lexical scope, it's spelled out for them. And if it's a bare assignment (not a new variable), explicit scoping makes it easier to find out where the variable is first used. Not to mention it allows the language to protect against in-scope reuse (in cases of debatable-quality imperative code with scopes more than a screenful long), as the second declaration may (and generally will) be statically marked as the redeclaration of an existing variable, and will be refused by the language's runtime. And all of that for the cost, in most languages, of 3 characters. Almost nothing. All the issues you mentioned (since you didn't mention typing) are not issues of explicit scoping but with specific implementations thereof.