Hacker News Reader

Comment by qwertyuiop924 | Hacker News Reader

I actually think that easy parsing is something you should try for. the easier your language is to parse, the less edge cases there are, and simpler it is for programmers to understand. In short, I'd rather have Scheme than Ruby. But I seem to be in the minority...

View on HN

I agree in that easy parsing is a good quality of languages. But i also think a language can have a rather rich (i.e. big) syntax that's also straightforward to parse. That is, that the dichotomy of either having a very lean syntax like Scheme or a bloated and complicated syntax like Ruby is not so clear-cut.

The difficulty of parsing Ruby's syntax (both for machines and for humans) comes from some unfortunate design decisions, not so much from its vastness. For example, using the same symbols, {}, to denote hash literals and blocks makes parsing/understanding the syntax of method calls more difficult:

  def foo(*args)
    puts "args: #{args}, block_given?: #{block_given?}"
  end
  # Parentheses can be omitted when calling methods:
  foo           # args: [], block_given?: false
  foo 42        # args: [42], block_given?: false
  foo 42, "bar" # args: [42, "bar"], block_given?: false
  # *Except* when the first argument is a hash. This:
  foo({})       # args: [{}], block_given?: false
  # Means something completely different than this:
  foo {}        # args: [], block_given?: true
  # But if the hash is not the first argument then it's OK, you can omit parens
  # again :3
  foo 42, {}    # args: [42, {}], block_given?: false

This is not a problem of having dedicated syntax for blocks and hash literals. It's a problem of having chosen conflicting syntactic forms for them. If blocks could only be denoted with do/end, or with a different set of symbols than hash literals, this would not be a problem.

And this is just one example of conflicting syntactic forms. In Ruby, sadly, there many cases of this. E.g., using * both for multiplication and for argument "splatting" means that

  a * b

is not the same as

  a *b

when `a` is a method, but actually is the same when `a` is a local variable; or `foo "bar"` and `foo"bar"` being two perfectly valid ways of calling foo with "bar" as an argument, but `foo [42]` and `foo[42]` not being two perfectly valid ways of calling foo with [42] as an argument; and probably more.

So, as long as syntactic forms are carefully chosen so that they don't have weird and conflicting edge cases between each other, i think a language can have a rather big syntax without it being difficult to parse/understand.

Disclaimer: i love Ruby; it's my bread-and-butter language. But i wish it didn't have as many syntax quirks as it does :)

This is what I mean. Syntactic ambiguity is evil, and pretty common. Even C has it (google "lexer hack"). And I definitely think that Scheme could do with a bit more syntax. Some of the whitespace indent extensions (WISP, for example) are nice, and I could do with hash table literals. So I'm off to go write those...:-D

FWIW, as someone who does a lot of work with parsers, that block case is a bad example, as it is not at all ambiguous and does not make the language more difficult to parse. C and C++ have tons of things that make them frustrating or even nearly impossible to parse: if you just write down the naive description of this feature from Ruby you will see there are no ambiguities and it never even requires more than a single lookahead token to decide if you are using a hash or a block argument. A very similar example from JavaScript between and object literal and a block statement is actually a legitimate issue, but this feature of Ruby is so benign you can probably parse it correctly dropped into the middle of the file at the { with nothing but a single token of look-behind. The "splat" example, though, is spot on: there you have a context sensitivity. (Not so much in the [/" one, though: this does make the language more frustrating to parse, but only because the language is clearly defined over characters instead of tokens; but it is still a better example than the block argument.)

Thanks for the clarification :)

(And sorry for not having replied earlier, i seems HN doesn't notify about replies any more.)

The point i was trying to make was mostly about the difficulty of understanding the syntax (i.e. "parsing" for humans), not so much about syntax ambiguity or having to use a more sophisticated parsing strategy. The comments on the code represent the "rules" that a human might follow to try and make sense of that syntax. They are not as simple as they could be had Ruby only allows blocks to be denoted with do/end.

However, about the complexity on the parser itself, doesn't this case of block syntax need at least some dedicated logic to take care of ´foo {}´ not parsing the {} part as a hash literal expression but rather as a block? (e.g., maybe adding some explicit priories to the parser rules, or making the lexer add hidden parentheses so that the parser sees ´foo() {}´ and doesn't have to make that distinction).

Easy (for a computer) to parse does not necessarily mean simpler for programmers to understand. I think Lisp's deeply nested parens are a good example of this problem.

J is also quite easy to parse, but could be difficult to understand. (See e.g. http://sblom.github.io/openj-core/iojSent.htm#Parsing)

J is one of my favorites. The syntax is cryptic at first, but the lack of ambiguity makes programs easier to understand and easier to design in the long run.

I dunno, I think proper anonymous functions would have been a lot better than hooks and forks.

Though I'm not sure if that falls under syntax or semantics for purposes of this discussion.

Lisp has never been fully implemented. If M-expressions were in active use (and modernized over time) there wouldn't be so much parentheses hell.

The only people who refer to it as parens hell seem to be non-lispers. As I understand it m-exps were never implemented because people don't really want them. I definitely prefer s-exps over them.

"the only people" implies that non-lispers is a category that is not equal to "almost everyone"

It seems plausible that the implied causality is backwards - perhaps it's not that people don't mind the parens because they use LISP, but rather that people use LISP because they don't mind the parens. Personally, I don't think I ever did mind them, but I'd be really surprised if that's not at least a moderately important filter on the set of people who become lispers.

> The only people who refer to it as parens hell seem to be non-lispers.

Confirmation bias.

...Which is why we have WISP. And SRFI-49. And editors that can indent LISP code. All of these solve the problem rather nicely.

I've been diving into Lisp over the past few months and I already find it just as easy to read and even easier to edit/navigate with a proper editor. Sometimes it gets hairy when reading mathematical operations, but that's it. Sure it's definitely possible to write hard to read code, but I don't think s-exps are necessarily more prone to this than your typical C style syntax.

When I first started writing Lisp I was put off by how simple the syntax was. Everything looks the same and it was so hard to tells things apart. After working with Lisp for a long enough time I began to love the simplicity. Everything is so simple, nothing gets in the way of reading code.

To poorly paraphrase Bruce Lee: "When I first started to learn Lisp, I thought it was all just parens. After I truly learned Lisp, I realized it is all just parens."

Also tools become much easier. There are few good refactoring tools for C++ because the language is almost impossible to parse. In fact, even generating tags for vim/emacs is nearly impossible.

My thoughts exactly, as someone who has spent quite some time creating a (usable and readable) LALR syntax that can do everything modern C++ does (plus named arguments, a null-coalescing operator and extension methods) and is currently writing a transpiler based on it, I hope more people share your concern :)

Anyone who used Modula-3...

https://en.wikipedia.org/wiki/Modula-3

...knows that one can have key features of C++ for systems programming with an easy-to-parse, safer, and [for a time] more efficient language. The SPIN OS team even modified it with type-safe linking so one could hotload code into the OS. What I saw there was "hotload code into running system" w/ associated benefits during updates. Or safer, better JIT. ;)

Anyway, combined with LISP-style macros & irritating parts removed (eg uppercase, verbosity), you get a system language that blows C++ away in productivity (esp w/ DSL's), compiler efficiency, maintenance, and possibly run-time efficiency. The world might have went in a different direction but they better be honest about parsing pain they created. And all the productivity opportunities lost due to that.

Takes me back to the past when Metrowerks created a Modula-2 compiler for the Mac:

https://en.wikipedia.org/wiki/Metrowerks

Didn't know they started out with Wirth's compiler. Picked the best one. Then market rejected it. Then pivoted to a more successful approach supporting whatever crud was popular. The recurring pattern. Also didn't know they supported that many platforms. Impressive.

While syntax surely doesn't help, I think the real blocker is actually the preprocessor.

C has basically the same preprocessor, and ctags works mostly fine.

ctags is a pretty bare bones compared with what an IDE with semantic analysis is capable of.

No, the real problem is the both C and C++ are context sensitive. (In C compilers, though not C++ ones, 'the lexer hack' is the most common solution) That's fairly hard to parse, although not as bad as some languages. For preprocessing, it's fairly easy to write a C preprocessor, and then look at how your code will look if various options are defined... Actually that would be a really good debugging tool. I should go write that. And then make an emacs mode for it, so that you can type one command at any point, and see how your function/file/whatever will be transformed by the preprocessor.

The simplest parser style is assembly code: one line, at most one statement. But there's always some desire to get a little more code density than assembly, it's just a matter of how one wants to go about the problem.

The syntax of older-style BASIC, for example, hews close to the assembly parsing model, just adding a few special cases for different keywords. Algol syntax has a tradition of design based around algorithm description first, with generalized power second. The Forth or Lisp approaches, because they are very generic and powerful, naturally pull those languages in the direction of extensive metaprogramming.

In that sense one can see that the more sugary syntaxes treat the programmer more like an end-user, because they direct the workflow. Generalized ones encourage a DIY approach to everything. There are tradeoffs to each strategy.

And I don't think that Walter Bright would necessarily disagree with you. My interpretation of his "false gods" list is that those are probably OK as secondary goals, but that the "true gods" list should be primary goals.

In this case, "easy parsing" is OK, but not when it conflicts with "tried and true".

Choosing Lisp as your "tried and true" is acceptable, though...

Particularly he has CFG as a true god, for ease of parsing and tooling. Bright hangs out here so if he wants he can come in and expand but I think it's a case of look at the moon(CFG) not the finger(parsing ease) pointing at the moon.

Humans like parsing - witness the love for mathematical notation. It takes time to learn the grammar, but after that it's a background process.

Simpler general parsing (eg Lisp) is more powerful, but that's a negative for learnability of the language.

Reply on news.ycombinator.com