If all you want is the vspace savings, you could easily make this happen as an editor mode.
iGo: a new Syntax for GoLang
71–80 of 94 posts
Re: iGo: a new Syntax for GoLang
#72Why sacrifice consistency for some minor syntax changes? We have gofmt so that everyone's code looks the same, and now this? I don't see the benefit.
It seems like a real "because we can" thing. Coffee script is smelly in the same way.
Re: iGo: a new Syntax for GoLang
#73Earlier quoted context omitted.
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.
No, it's not. Because if you're used to reading igo code and then you're browsing normal Go code in GitHub or watching a talk or reading a tutorial, you're going to have to mentally translate that code to igo. It's needless mental acrobatics.
Re: iGo: a new Syntax for GoLang
#74Earlier quoted context omitted.
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
#75I kinda want to see Rust without braces or semicolons, although I'm not sure what you'd do with implicit return.
Nimrod solved that... The solution in a nutshell: If a statement list contains a 'return', it enforces a 'void' context for the statement list, otherwise the statement list has the type of the tailing expression e in (s; s; e).
Re: iGo: a new Syntax for GoLang
#76I am usually wary of new languages, because they come at a great cost. All the code I've written, libraries I've discovered, standard library I'm used to and take for granted are suddenly gone, and I have to start from scratch. On the plus side, the new language may have desirable aspects that are improved. However, this is not that. Despite looking like a different language, in reality, it's just a different _interf…
http://en.wikipedia.org/wiki/Bidirectional_transformation
It might be interesting to hook up different AST representations directly into an editor, in this case iGo would never exist on disk. Really all he has done is push what would be an editor completion into a new sytnax.
Re: iGo: a new Syntax for GoLang
#77Re: iGo: a new Syntax for GoLang
#78Earlier quoted context omitted.
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 c…
You are meaning that it is an LL(k) parser. Rust is an example of an LL(1) parser. Various things that might be convenient to have in the language in certain circumstances have been rejected because they would cause ambiguity in the parser which would require arbitrary lookahead.
Re: iGo: a new Syntax for GoLang
#79Earlier 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…
You are meaning that it is an LL(k) parser. Rust is an example of an LL(1) parser. Various things that might be convenient to have in the language in certain circumstances have been rejected because they would cause ambiguity in the parser which would require arbitrary lookahead. https://en.wikipedia.org/wiki/LL_parser
What I have in mind is more loosely defined than LL(k) and in a way more restrictive than a general LL(k) grammar, but LL(k) is probably a good way to formally capture something close to what I had in mind. I try to avoid using the term "almost regular" as it is imprecise. I only used it since it was relevant to the context and I'd heard Rob Pike describe Go as having almost regular syntax several times.
Re: iGo: a new Syntax for GoLang
#80Earlier quoted context omitted.
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.
No, it's not. Because if you're used to reading igo code and then you're browsing normal Go code in GitHub or watching a talk or reading a tutorial, you're going to have to mentally translate that code to igo. It's needless mental acrobatics.
Don't forget about godoc.