6 ms·

Python, Haskell, Java, Go have formal and even context-free grammars. It makes me as a developer happy since it's much easier to predict how the language will p

by lucian1900 14y ago

Python, Haskell, Java, Go have formal and even context-free grammars. It makes me as a developer happy since it's much easier to predict how the language will parse something.

cllns 14y ago
Ah okay. Cool, thanks!
peterwoo 14y ago
Python is not context free.
- masklinn 14y ago
  And there's no way java is. Not sure about Go.
  - lucian1900 14y ago
    The Java language specification includes a description of the language as a context free grammar. That alone does not make it a nice language, of course.
    - masklinn 14y ago
      > The Java language specification includes a description of the language as a context free grammar. I can only assume that it's lying its pants off, as I noted in an other subthread `(a) - (b)` can't be parsed (to an AST) without knowing the identity of `a` in the current scope: if it's a type the expression is a cast of `-(b)` to `a`, if it's a value it's a subtraction of `(b)` from `(a)`.
      - peterwoo 14y ago
        It can be parsed to an AST -- as you note, it can be parsed into two ASTs. It's called an ambiguous grammar, which can still be context free.
        masklinn 14y ago
        > It can be parsed to an AST -- as you note, it can be parsed into two ASTs. By "it can't be parsed to an AST" I meant "it can't be parsed to a useful AST used to run or generate code" on its own, it needs to be disambiguated through contextual information before anything can be done with the prospective subtree. Sorry for the lack of clarity. > It's called an ambiguous grammar, which can still be context free. The only way to disambiguate is to provide expression context (namely visible name bindings at this point), it's essentially the same problem Eli Bendersky described when talking about C grammar's context-sensitivity: http://eli.thegreenplace.net/2007/11/24/the-context-sensitivity-of-cs-grammar/ http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv...
- Scaevolus 14y ago
  Indentation is handled by the lexer, not the parser. The parser is context free-- LL(1), actually. The lexer maintains one extra stack to track indentations, meaning it's more of a PDA than a DFA, but the actual complication is mild.
  - peterwoo 14y ago
    The language is not context free, although I agree there is a parsing solution which is not terribly complex.
    - lucian1900 14y ago
      It is context free. INDENT and OUTDENT are directly equivalent to { and } in other grammars.
      - peterwoo 14y ago
        The difference is that INDENT and OUTDENT have to be defined by context-sensitive productions. Even if this occurs in what would otherwise be the "lexing" stage of the parser.
indspenceable 14y ago
That's orthogonal to the point, though - when I write ruby, I don't care about how it will get parsed, I care about how it will run.
- npc 14y ago
  This is sort of an odd statement since the way a piece of code is run is directly related to how it is parsed. If an alternative implementation like Topaz parses something differently than MRI then you'll have code that does two different things on two different interpreters. Having a complicated and informally specified grammar makes this a lot harder to avoid.
jshen 14y ago
I've done a lot of java and a lot of ruby. Anyone that states that Java makes them happier as a developer is viewing the world from a very different perspective than I am. That right there is why I disagree with your point. I'm far happier programming in ruby than java, even though there is more ambiguity to the syntax.
- lucian1900 14y ago
  Java is indeed pretty nasty, but I would consider it easier to parse visually than Ruby. Less ambiguity.
  - jshen 14y ago
    I think your definition of "parse visually" is very different than mine. The java version of the below would be much harder to parse visually for me. https://gist.github.com/jaydonnell/4735159 https://gist.github.com/jaydonnell/4735159
    - jchan 14y ago
      Perhaps you should consider a different field of employment. https://gist.github.com/anonymous/4736156 https://gist.github.com/anonymous/4736156 (Pardon the tabbing, I don't have that much time to waste on uneducated comments like the above)
      - jshen 14y ago
        Unlike you, I'll avoid the ad hominem. The commenter I was replying to said that java is EASIER to visually parse. Your java code is harder to visually parse than my ruby code. It's not hard to visually parse, but it's harder than the ruby code which was my point. btw, I've added a sort to mine, what would that look like for yours? https://gist.github.com/jaydonnell/4735159 https://gist.github.com/jaydonnell/4735159 Edit: I see you don't have the courage to use your real account.
        14y ago

Python, Haskell, Java, Go have formal and even context-free grammars. It makes me as a developer happy since it's much easier to predict how the language will parse something.

cllns 14y ago

Ah okay. Cool, thanks!

peterwoo 14y ago

Python is not context free.

masklinn 14y ago
And there's no way java is. Not sure about Go.
- lucian1900 14y ago
  The Java language specification includes a description of the language as a context free grammar. That alone does not make it a nice language, of course.
  - masklinn 14y ago
    > The Java language specification includes a description of the language as a context free grammar. I can only assume that it's lying its pants off, as I noted in an other subthread `(a) - (b)` can't be parsed (to an AST) without knowing the identity of `a` in the current scope: if it's a type the expression is a cast of `-(b)` to `a`, if it's a value it's a subtraction of `(b)` from `(a)`.
    - peterwoo 14y ago
      It can be parsed to an AST -- as you note, it can be parsed into two ASTs. It's called an ambiguous grammar, which can still be context free.
      - masklinn 14y ago
        > It can be parsed to an AST -- as you note, it can be parsed into two ASTs. By "it can't be parsed to an AST" I meant "it can't be parsed to a useful AST used to run or generate code" on its own, it needs to be disambiguated through contextual information before anything can be done with the prospective subtree. Sorry for the lack of clarity. > It's called an ambiguous grammar, which can still be context free. The only way to disambiguate is to provide expression context (namely visible name bindings at this point), it's essentially the same problem Eli Bendersky described when talking about C grammar's context-sensitivity: http://eli.thegreenplace.net/2007/11/24/the-context-sensitivity-of-cs-grammar/ http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv...
Scaevolus 14y ago
Indentation is handled by the lexer, not the parser. The parser is context free-- LL(1), actually. The lexer maintains one extra stack to track indentations, meaning it's more of a PDA than a DFA, but the actual complication is mild.
- peterwoo 14y ago
  The language is not context free, although I agree there is a parsing solution which is not terribly complex.
  - lucian1900 14y ago
    It is context free. INDENT and OUTDENT are directly equivalent to { and } in other grammars.
    - peterwoo 14y ago
      The difference is that INDENT and OUTDENT have to be defined by context-sensitive productions. Even if this occurs in what would otherwise be the "lexing" stage of the parser.

indspenceable 14y ago

That's orthogonal to the point, though - when I write ruby, I don't care about how it will get parsed, I care about how it will run.

npc 14y ago
This is sort of an odd statement since the way a piece of code is run is directly related to how it is parsed. If an alternative implementation like Topaz parses something differently than MRI then you'll have code that does two different things on two different interpreters. Having a complicated and informally specified grammar makes this a lot harder to avoid.

jshen 14y ago

I've done a lot of java and a lot of ruby. Anyone that states that Java makes them happier as a developer is viewing the world from a very different perspective than I am. That right there is why I disagree with your point. I'm far happier programming in ruby than java, even though there is more ambiguity to the syntax.

lucian1900 14y ago
Java is indeed pretty nasty, but I would consider it easier to parse visually than Ruby. Less ambiguity.
- jshen 14y ago
  I think your definition of "parse visually" is very different than mine. The java version of the below would be much harder to parse visually for me. https://gist.github.com/jaydonnell/4735159 https://gist.github.com/jaydonnell/4735159
  - jchan 14y ago
    Perhaps you should consider a different field of employment. https://gist.github.com/anonymous/4736156 https://gist.github.com/anonymous/4736156 (Pardon the tabbing, I don't have that much time to waste on uneducated comments like the above)
    - jshen 14y ago
      Unlike you, I'll avoid the ad hominem. The commenter I was replying to said that java is EASIER to visually parse. Your java code is harder to visually parse than my ruby code. It's not hard to visually parse, but it's harder than the ruby code which was my point. btw, I've added a sort to mine, what would that look like for yours? https://gist.github.com/jaydonnell/4735159 https://gist.github.com/jaydonnell/4735159 Edit: I see you don't have the courage to use your real account.
      - 14y ago