Live data from Hacker News

iGo: a new Syntax for GoLang

igo.herokuapp.com

41–50 of 94 posts

Re: iGo: a new Syntax for GoLang

#41

One of the best parts of Go is that the grammar is (almost) entirely context-free - it is one of only two languages I know of in this regard - Lisp is the other[0]. This comes in handy because it is very easy to parse Go and make syntactic transformations while preserving semantic meaning. The "go fix" tool (which was used to port pre-1.0 code to Go 1.0) meant that Go never had a "py3k" moment[1]. This is not like py…

> One of the best parts of Go is that the grammar is (almost) entirely context-free

If the threshold is almost-context-free there's a host of matching languages: C (IIRC it's context-free if you remove typedefs), Rust, Pascal and descendants (Oberon), Python, java, …

If the threshold is actual context-freedom, I don't recall anything outside lisps.

Re: iGo: a new Syntax for GoLang

#42

One of the best parts of Go is that the grammar is (almost) entirely context-free - it is one of only two languages I know of in this regard - Lisp is the other[0]. This comes in handy because it is very easy to parse Go and make syntactic transformations while preserving semantic meaning. The "go fix" tool (which was used to port pre-1.0 code to Go 1.0) meant that Go never had a "py3k" moment[1]. This is not like py…

> One of the best parts of Go is that the grammar is (almost) entirely context-free You mean almost regular . Almost all programming language grammars are context-free. Regularity is a much higher bar to reach.

Pretty sure he means 'almost' context free (as opposed to 'very' context sensitive. C is context sensitive. A language like C++ is heavily context sensitive (actually, C++'s templates make it recursively enumerable iirc, so even worse..)).

Being regular would mean that you could decide it with regular expressions. Regular expressions are insufficiently powerful for matched parentheses of arbitrary depth, which is a good hint that Lisp and Go are not regular (or 'near' regular).

Re: iGo: a new Syntax for GoLang

#43

One of the best parts of Go is that the grammar is (almost) entirely context-free - it is one of only two languages I know of in this regard - Lisp is the other[0]. This comes in handy because it is very easy to parse Go and make syntactic transformations while preserving semantic meaning. The "go fix" tool (which was used to port pre-1.0 code to Go 1.0) meant that Go never had a "py3k" moment[1]. This is not like py…

> One of the best parts of Go is that the grammar is (almost) entirely context-free You mean almost regular . Almost all programming language grammars are context-free. Regularity is a much higher bar to reach.

> Almost all programming language grammars are context-free.

Er no, almost no programming language grammar is actually context-free (in the sense that they can be parsed unambiguously according to a context-free grammar)

Re: iGo: a new Syntax for GoLang

#44

Why is significant-whitespace vs. braces a significant issue for people? I've coded in both and while I suppose I would have to say that I'm "most" comfortable with braces, I don't find SW that different. The semantics of the code haven't changed at all. It's not like we're going from C to O'Caml here. This doesn't enable a different way of thinking about the code. I guess I just feel that, if I could run a set of ve…

Personally, it's not a significant issue, but it is a preference. Do you indent code when coding with braces? How anal are you about keeping your code formatted consistently (i.e. spaces after operators)?

Re: iGo: a new Syntax for GoLang

#45
post #14

The most obvious advantage here is that the code at the left is much more concise. This is good because then more code will fit in the same screen. Not sure this is what Go needs though.

How is more code on the same screen a good thing?

A lot of programmers seem to think that (the more code they can jam on the screen at a time the better, and thus any unnecessary newlines are superfluous), but I also don't understand why many are so rabid about it.

We generally don't code on 80x25 character terminals anymore, super high res monitors are cheap, vertical lines in code aren't a scarce commodity.

Personally I tend to like a fair amount of vertical whitespace (either in pure whitespace form or comments) in my code to split things up logically, even within the same function and when the newlines aren't required, eg:

  x = 10
  y = 20
  z = 0

  speed = 80
Variables assignments/func calls, etc that are closely coupled kept together, but some whitespace as things become less directly linked. I'd rather be able to quickly scan code in 10-40 line chunks than fit more code on the screen at once.

Re: iGo: a new Syntax for GoLang

#46
post #37

People who are willing to reinvent the syntax of a language only to shave a few parens and braces have a lot to learn yet about what truly matters.

Agreed. I spent a lot of time worrying about syntax in my first year or two of programming. Then, I gradually opened my mind and discovered a whole world of amazing languages with syntax I had found distasteful and previously avoided.

Re: iGo: a new Syntax for GoLang

#47
post #42

Earlier quoted context omitted.

> One of the best parts of Go is that the grammar is (almost) entirely context-free You mean almost regular . Almost all programming language grammars are context-free. Regularity is a much higher bar to reach.

Pretty sure he means 'almost' context free (as opposed to 'very' context sensitive. C is context sensitive. A language like C++ is heavily context sensitive (actually, C++'s templates make it recursively enumerable iirc, so even worse..)). Being regular would mean that you could decide it with regular expressions. Regular expressions are insufficiently powerful for matched parentheses of arbitrary depth, which is a g…

> Being regular would mean that you could decide it with regular expressions.

Hence almost regular. Of course, there is no concrete definition for "almost regular", but what I mean by it (Rob Pike himself also characterizes it as such too[1]), is that you get to decide which way to parse a construct quite definitely early in the token stream and you don't have to read arbitrary following tokens to figure out how to construct a parse tree branch.

C++ is the exception here. Most other block oriented high level programming language (at the syntax level) are indeed fully context-free, so just being context-free does not deserve a high prize.

[1]: http://www.infoq.com/presentations/Go-Google

Re: iGo: a new Syntax for GoLang

#48
post #8

It's hilarious to see someone add semantic whitespace to Go, which seems to be the opposite of Python With Braces[0]. I'm in the whitespace > braces camp, but mandatory braces help with the dangling else problem and makes it easier for the parser. [0] http://www.pythonb.org/

I'm unfamiliar with this dangling else problem. I googled it and I don't see how it could be a problem with significant whitespace.

I can understand making it faster for the parser, though.

Re: iGo: a new Syntax for GoLang

#49
post #14

The most obvious advantage here is that the code at the left is much more concise. This is good because then more code will fit in the same screen. Not sure this is what Go needs though.

How is more code on the same screen a good thing?

2 lines is certainly better than 1 line. 10 better than 2. I don't know where it tops out, if ever.

100 chars/line better than 200. 60 better than 100. I don't know where it bottoms out.

That's how it's a good thing (not sure if you were being serious).

Re: iGo: a new Syntax for GoLang

#50

Earlier quoted context omitted.

> One of the best parts of Go is that the grammar is (almost) entirely context-free You mean almost regular . Almost all programming language grammars are context-free. Regularity is a much higher bar to reach.

> Almost all programming language grammars are context-free. Er no, almost no programming language grammar is actually context-free (in the sense that they can be parsed unambiguously according to a context-free grammar)

Unambiguous parsing is not a requirement for a language to be context-free. Your use of "actually context-free" is a stretch of the definition by a huge margin. In fact, the definition of a context-free language does not depend on a specific grammar at all. You can have a context-free grammar that parses a language unambiguously and another grammar that ambiguously defines the same language.

It is true, however, that most formal grammars for programming languages define a strict superset of the actual language and then restrict it according to semantic rules (e.g. type checking, definite assignment rules). That is why in my original comment, I was careful to use the phrase "programming language grammars", instead of "programming languages".

Post reply on HN