Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

iGo: a new Syntax for GoLang

igo.herokuapp.com

Post reply on HN
Print view View original

31–40 of 94 posts

Re: iGo: a new Syntax for GoLang

#31

Post by enneff »

shurcooL wrote: post #26
enneff wrote: post #17

Why 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.

I can write code in iGo and save it as .go. You'll never know if the code was written using Go syntax or iGo syntax, whether the person used tabs of width 4, 8, or 2 (it'll be a '\t' character in the file), or if they used Sublime Text or vim or emacs.

Oh really? So the igo code won't be checked into your repo? The comments you've made will be preserved and in the right place in the resulting code? And you'll be writing go code that other go programmers will find idiomatic and easy to read?

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?

Re: iGo: a new Syntax for GoLang

#32

Post by mehrdada »

chimeracoder wrote: post #21

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.

Re: iGo: a new Syntax for GoLang

#33

Post by mseepgood »

hhm wrote: 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?

Re: iGo: a new Syntax for GoLang

#34

Post by CatMtKing »

donpark wrote: post #30

IGo as-is could've been just an alternate colored-syntax mode with color of curly characters set to background color. Much less work with same result.

I don't think that's a fair statement. You would still have to keep track of and type curly braces, only now they'd be invisible.

Re: iGo: a new Syntax for GoLang

#35

Post by georgemcbay »

xxchan wrote: post #29

I appreciate the inline if-else statements. I'm so tired of having: if err != nil { return err } Take up 70% of all lines in a function.

the cost in making the code harder to parse (both for compilers and, IMO, humans) isn't worth it. Using short assignment mixed with if makes the Go error handling branch code not so bad, eg instead of:

  err = doSomething

  if err != nil {
    return err
  }
do:

  if err = doSomething(); err != nil {
    return err
  }
Also if your function only returns err, I'd use a named return to save even more typing. I know they are seen as a bit of a red-headed stepchild by much of the Go community these days, but I still like them if used carefully:

  func whatever() (err error) {
    if err = doSomething(); err != nil {
       return
    }

    ...

  }

Re: iGo: a new Syntax for GoLang

#36

Post by shurcooL »

enneff wrote: post #31
shurcooL wrote: post #26

Earlier quoted context omitted.

I can write code in iGo and save it as .go. You'll never know if the code was written using Go syntax or iGo syntax, whether the person used tabs of width 4, 8, or 2 (it'll be a '\t' character in the file), or if they used Sublime Text or vim or emacs.

Oh really? So the igo code won't be checked into your repo? The comments you've made will be preserved and in the right place in the resulting code? And you'll be writing go code that other go programmers will find idiomatic and easy to read? 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?

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 with different widths? Use a text editor: http://img534.imageshack.us/img534/1627/zo3w.png

If you're gonna write Go code using iGo syntax, you're probably going to be using a code editor that supports iGo (I don't think one exists yet, this is just a prototype).

You're not gonna be converting from .go to .igo manually, that'd be like running gofmt manually. I don't run gofmt manually, it happens on save (and in fact, I use goimports instead of gofmt).

Re: iGo: a new Syntax for GoLang

#38

Post by bunkat »

manuletroll wrote: post #7

For some reason I find this less readable than the original syntax. I couldn't say why, as I quite like Python or Coffeescript.

I'd agree. I think the biggest thing for me is that I had to think about what was being expressed on the left hand side while the right hand side seems more explicit and straight forward. Provided that and the fact that only a handful of lines were actually saved, I don't see much advantage.

Re: iGo: a new Syntax for GoLang

#39

Post by derefr »

chimeracoder wrote: post #21

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 be executable as plain Go. If the Go compiler's parser+lexer shared their canonicalization logic with "go fmt", then feeding "go edit"-munged Go to the compiler would implicitly re-canonicalize it before compiling it. So you could have transformations involving things like significant whitespace.

In fact, the pair of filters "go edit" and "go fmt" could even be made into a read/write filter-pair for a FUSE filesystem: in effect, the code on-disk would always be represented in the canonical "go fmt"ed manner, while the code you'd see in your editor would always be in your own personal "go edit" style.

And then, 56 years after McCarthy's LISP, we'd finally have our M-expressions. ;)

(And the serialized representation could finally be stored as a binary AST tree, and we could embrace visual-symbolic hybrid languages, and entertain divergent syntaxes with unified AST-level semantics, and have one universal runtime library, and...)

Post reply on HN