3 ms·

I appreciate the need to have parens to remove ambiguity and for something like an AST it is a very concise expression. It just seems like there are common patt

by lowboy 14y ago

I appreciate the need to have parens to remove ambiguity and for something like an AST it is a very concise expression. It just seems like there are common patterns that could be abstracted out, such as the code at the bottom of this lispyscript example[0]. Every new line gets a open paren, LF + tab indicates another open paren on next line, otherwise LF is a closed paren. Again, I'm not a lisp guy (could you tell?) and maybe this is just because it's a js variant and not pure lisp code. I appreciate when languages don't make me insert/edit/move over/count/deal with/etc. more characters than necessary. Maybe there's a good vim setup to do that already - that would go a long way to alleviate my concerns. [0]: https://github.com/santoshrajan/lispyscript/blob/master/examples/twitter.ls https://github.com/santoshrajan/lispyscript/blob/master/exam...

wonderzombie 14y ago
Abstract out how? For instance, this is valid code: (if (empty? x) foo bar) edit: lolz. failed at example. fixed. foo is the result of if x is empty, and you can tell it is not a function call because it has no parens. Whitespace is merely a style consideration, as it is in C++ or Java. There are ways to save time/trouble within the language. For instance, in Clojure (foo (bar (baz (quux x)))) can be rewritten as ((comp foo bar baz quux) x) There's also stuff like apply, ->, and ->> in Clojure, which have similar purposes (flattening out the nesting a bit). And for anything particularly syntactically onerous, you can always add sugar with macros. Ultimately syntax is more about ease than it is about power or simplicity. I think it's worthwhile to try to look beyond that into what the code is saying rather than how it's saying it. You have to do this anytime you learn a significantly different language anyway, right?
- lowboy 14y ago
  True, and to me the ease of use increases by getting rid of what I perceive to be superfluous parens. I'd rather write the first code block and have mean the same as the second. This is a trivial example, but when LF + indentation become significant it eases deep nesting. Ideal: if (empty? x) foo bar Less ideal: (if (empty? x) foo bar) The clojure comp shortcut looks good to me, but why even need the outside parens if it was the only line in that block? (comp foo bar baz quux) x Ideally, that should be valid as well. I know this kind of reduction won't work in a lot of cases, but I appreciate syntax sugaring like this where I can get it.
  - wonderzombie 14y ago
    Sugar is nice, but it ought to make the code clearer. I worry that in trying to make this appear simpler, in reality it would be substantially less so. I think significant whitespace works for a language like Python, but I'm less convinced that it's a great idea for a Lisp. As it stands now, the trade-off is some unfamiliarity and discomfort up front for rather elegant consistency for the entire time you use the language. When you're optimizing for the people who'll use the language, the former is a lot less significant. :) One thing worth noting is that Clojure does introduce constructs which use square brackets, braces, etc. It's a little nicer to use brackets for grouping, in lieu of parens for lists or declaring function params.
    - lowboy 14y ago
      I agree with your priorities on how long term concerns trump up-front discomfort when learning a language. But to me it would be of long term benefit to never see parens that could be otherwise indicated by sig whitespace patterns like the empty/foo/bar indented block we have above. The elegance seems to come from having a simpler parser, and one less thing to explain to people when they're learning the lanuage. As a user of a language and not a developer of a parser, the first doesn't concern me and the second should be trumped by long-term concerns. Using significant whitespace to eliminate syntax is elegant in its own way as well. Again, maybe this is just because I'm not a lisper, but keeping implicit parens that follow a well-established pattern should be a trivial mental task for a developer. Could you provide a piece of lisp code as a contra example?
      - deleted 14y ago
        [deleted]
      - wonderzombie 14y ago
        I guess what I'm trying to say is that syntax is probably the least significant difference between a Lisp like Clojure and your average imperative C-like. So you can make incremental improvements to the syntax, but since it's not going to significantly alter how and what kinds of programs you write the way immutability and purity do, I don't see it as all that worthwhile.

by lowboy 14y ago

wonderzombie 14y ago

Abstract out how? For instance, this is valid code: (if (empty? x) foo bar) edit: lolz. failed at example. fixed. foo is the result of if x is empty, and you can tell it is not a function call because it has no parens. Whitespace is merely a style consideration, as it is in C++ or Java. There are ways to save time/trouble within the language. For instance, in Clojure (foo (bar (baz (quux x)))) can be rewritten as ((comp foo bar baz quux) x) There's also stuff like apply, ->, and ->> in Clojure, which have similar purposes (flattening out the nesting a bit). And for anything particularly syntactically onerous, you can always add sugar with macros. Ultimately syntax is more about ease than it is about power or simplicity. I think it's worthwhile to try to look beyond that into what the code is saying rather than how it's saying it. You have to do this anytime you learn a significantly different language anyway, right?

lowboy 14y ago
True, and to me the ease of use increases by getting rid of what I perceive to be superfluous parens. I'd rather write the first code block and have mean the same as the second. This is a trivial example, but when LF + indentation become significant it eases deep nesting. Ideal: if (empty? x) foo bar Less ideal: (if (empty? x) foo bar) The clojure comp shortcut looks good to me, but why even need the outside parens if it was the only line in that block? (comp foo bar baz quux) x Ideally, that should be valid as well. I know this kind of reduction won't work in a lot of cases, but I appreciate syntax sugaring like this where I can get it.
- wonderzombie 14y ago
  Sugar is nice, but it ought to make the code clearer. I worry that in trying to make this appear simpler, in reality it would be substantially less so. I think significant whitespace works for a language like Python, but I'm less convinced that it's a great idea for a Lisp. As it stands now, the trade-off is some unfamiliarity and discomfort up front for rather elegant consistency for the entire time you use the language. When you're optimizing for the people who'll use the language, the former is a lot less significant. :) One thing worth noting is that Clojure does introduce constructs which use square brackets, braces, etc. It's a little nicer to use brackets for grouping, in lieu of parens for lists or declaring function params.
  - lowboy 14y ago
    I agree with your priorities on how long term concerns trump up-front discomfort when learning a language. But to me it would be of long term benefit to never see parens that could be otherwise indicated by sig whitespace patterns like the empty/foo/bar indented block we have above. The elegance seems to come from having a simpler parser, and one less thing to explain to people when they're learning the lanuage. As a user of a language and not a developer of a parser, the first doesn't concern me and the second should be trumped by long-term concerns. Using significant whitespace to eliminate syntax is elegant in its own way as well. Again, maybe this is just because I'm not a lisper, but keeping implicit parens that follow a well-established pattern should be a trivial mental task for a developer. Could you provide a piece of lisp code as a contra example?
    - deleted 14y ago
      [deleted]
    - wonderzombie 14y ago
      I guess what I'm trying to say is that syntax is probably the least significant difference between a Lisp like Clojure and your average imperative C-like. So you can make incremental improvements to the syntax, but since it's not going to significantly alter how and what kinds of programs you write the way immutability and purity do, I don't see it as all that worthwhile.