Live data from Hacker News

iGo: a new Syntax for GoLang

igo.herokuapp.com

61–70 of 94 posts

Re: iGo: a new Syntax for GoLang

#61
So what's the intended workflow here? You write your code in IGo syntax. Now, you can't compile that code until it's been converted to real Go.

And you need to commit the Go source, not just the IGo source, because other people don't want to see your Python-esque Go.

And once you compile your code, now any error messages are going to have the wrong line number associated with them if you look at the IGo source. So when it comes time to debug, I guess you have to switch to reading the auto-generated Go and making changes in your IGo from there.

This seems like an awful lot of hassle in order to achieve what is arguably the worst part of Python syntax: significant whitespace.

Re: iGo: a new Syntax for GoLang

#62
post #59

Earlier quoted context omitted.

Yes, that's the idea. The current implementation may not be finished/perfect. > Also, if you use igo won't you have to adjust to read other peoples non-igo code? Or will you use a converter tool whenever you read any go code? "Converter tool" makes it sound like you find it unreasonable. Do people use "converter tools" to view .html files in a rendered format? No, they use a browser. Or to display '\t' characters wit…

The converter tool comment was in the context of reading code on GitHub, for example.

I believe his point is that iGo is just a way of editing .go files. It's not as though you would be saving .igo files to disk or anything. So, it's totally unrelated to any kind of version control or file management, much less to Github.

Re: iGo: a new Syntax for GoLang

#63
post #39

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…

It'd certainly be possible to have a tool -- let's say "go edit" -- which would read a set of user preferences, and apply transformations (e.g. setting spaces or tabs, variables-in-camel-case, comment-styles , etc.) to Go code. It'd be fine as long as each transformation was bijective in a way "go fmt" could revert. Interestingly, the code existing between the "go edit" and "go fmt" steps wouldn't necessarily need to…

[deleted]

Re: iGo: a new Syntax for GoLang

#64
post #55

Earlier quoted context omitted.

> 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 c…

Do you have the timestamp of when in this talk Rob Pike mentions this? If he says that it is "almost regular", then that settles it in my book, but I am pretty certain that you are wrong about most block oriented high level languages being context free. C++ is an extreme case, as it's Turing complete, but C is definitely context sensitive ( http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv... ), Perl is ju…

In that video mentions regularity around minute 51. I have seen him using that term in person too.

The blog post you mentioned is misinformed. YACC does not parse all context-free grammars. It generates LALR parsers, that parse a strict subset of context-free languages (called deterministic context free languages). Not parseable with YACC does not imply not context free.

It is important to distinguish the programming language and its syntax. In most real compilers, the parser accepts a superset of the programming language and then other components of the compiler restrict it with semantic rules like type checking. What I am talking about here is the syntax only. In that sense, things like C, Java, and C# are most definitely context-free. The language specification usually comes with a context-free grammar describing the syntax. Whether you can use it to parse programs efficiently (in O(n)) and meaningfully is another matter.

Re: iGo: a new Syntax for GoLang

#65
post #39

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…

It'd certainly be possible to have a tool -- let's say "go edit" -- which would read a set of user preferences, and apply transformations (e.g. setting spaces or tabs, variables-in-camel-case, comment-styles , etc.) to Go code. It'd be fine as long as each transformation was bijective in a way "go fmt" could revert. Interestingly, the code existing between the "go edit" and "go fmt" steps wouldn't necessarily need to…

This is mostly the aim of this project.

Re: iGo: a new Syntax for GoLang

#66

Earlier quoted context omitted.

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 white…

Many things are valuable. Conciseness per se is valuable (I don't think you will argue in favor of unnecessary verbosity in programming). However, of course this is just one of many factors, and any programming language will have to find a balance between these many factors, depending on how important each is, and so on.

If you think you are getting conciseness by decreasing readability then you probably have a balancing issue, but if you can get more concise code without decreasing readability then that's good news.

Re: iGo: a new Syntax for GoLang

#67
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.

> Not sure this is what Go needs though.

Yep, a generics prototype would be better spent time.

Re: iGo: a new Syntax for GoLang

#68
I really respect the way this was posted. A simple side by side. Most of the times stuff like this is posted, it is a horrifically convoluted example to try to show the massive code savings, this one is just -- honest. You save a few lines of code.

That all said, the syntax is godawful. It brings back so many horrors from Python, whitespace, self, ugh. The next step to make it truly awful would be have those minor whitespace errors only show themselves at runtime so writing complex applications becomes a nightmare.

Love the attitude, abhor the project.

Re: iGo: a new Syntax for GoLang

#69
post #55

Earlier quoted context omitted.

Do you have the timestamp of when in this talk Rob Pike mentions this? If he says that it is "almost regular", then that settles it in my book, but I am pretty certain that you are wrong about most block oriented high level languages being context free. C++ is an extreme case, as it's Turing complete, but C is definitely context sensitive ( http://eli.thegreenplace.net/2007/11/24/the-context-sensitiv... ), Perl is ju…

In that video mentions regularity around minute 51. I have seen him using that term in person too. The blog post you mentioned is misinformed. YACC does not parse all context-free grammars. It generates LALR parsers, that parse a strict subset of context-free languages (called deterministic context free languages). Not parseable with YACC does not imply not context free. It is important to distinguish the programming…

If a piece of C code that parses in two different ways, depending on what other code may have also been parsed, isn't context sensitive, then what is?

Re: iGo: a new Syntax for GoLang

#70
post #67
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.

> Not sure this is what Go needs though. Yep, a generics prototype would be better spent time.

I was actually going to include that in my comment. Go really needs generics.
Post reply on HN