Neugram, briefly

October 2017

If you program a lot in Go, you may find Neugram interesting.

I started working on Neugram because as I spent more time programming in Go I found myself writing a larger fraction of the scripts better suited to Python or Perl in Go. My daily programming came to be dominated by bash and Go.

The problem is, bash is an awkward language for a ~100 line program, and sometimes so is Go. While it is thoroughly enjoyable to use the same standard library in scripts as in big complex projects, Go is slower to work in than Python and Perl for a few reasons:

  • No read-eval-print-loop.

  • No shebang support.

  • Lots of unhelpful error handling. (Go’s explicit error handling is wonderful in large programs, but in small scripts where all you write is if err != nil { log.Fatal(err) } it is a drag.)

At first glance these look like features missing from Go. So I went about figuring out how to add them. Turns out, they are missing quite deliberately.


The grammar of Go needs to be changed to support line-by-line evaluation. Top-level constructions in a .go file are declarations, not statements. There is no sequence in the declarations, all are evaluated simultaneously across all the files in a package. A declaraction on an earlier line in a file can happily refer to a name declared later in the file. If you want to type Go declarations into a REPL, nothing can execute until you declare the package done.

So the first thing you need to do to define a REPL for Go is to step down a level. Instead of declaractions, process statements. Pretend everything typed into the REPL is happening inside the func main() {} of a Go program. Now there is a sequence of events and statements can be evaluated as they are read.

This shrinks the set of programs you can write dramatically. In Go there is no way to define a method on a type inside a function (that is, using statements). There is a good reason for this: all the methods of a type need to be defined simultaneously, so that the method set of a type doesn’t change over time. It would lead to a whole new class of confusing errors if you could write:

  1. func main() {
  2. type S string
  3. var s S
  4. _, ok1 := s.(io.Reader)
  5. func (S) Read(b []byte) (int, error) { ... }
  6. _, ok2 := s.(io.Reader)
  7. fmt.Println(ok1, ok2) // Prints: false, true
  8. }

That is why you cannot write that in Go.

So for the language to be REPL-compatible it needs serious grammar surgery, which would make a REPL possible, but hurt the readability of big complex programs.

Neugram has its own its own statement-based method syntax, which diverges in a small but significant way from Go. (Though it won’t be properly functional until the Go generating backend is complete.)

Error handling

Explicit vs. implicit error handling is a contentious issue, but it is a safe bet that if you have chosen to use Go you strongly favor explicit error handling. The language does not make it easy to avoid handling your errors.

Unfortunately, there is one place where even a strong supporter of explicit error handling can admit the process is tedious: when writing “all or nothing” scripts. That is, programs that either follow the narrow success path completley, or if they step off the path even slightly exit immediately in error. Small Python scripts follow this process by default, and bash script authors often do by placing set -e at the top of their scripts.

Indeed, a common source of consternation for Java or Python programmers coming to Go is discovering that the small program they attempted to write to try out Go ended up needlessly wordy. This:

  1. #!/usr/bin/python
  2. f = open("hello.txt","w"
  3. f.write("Hello, World!")
  4. f.write("Next line.")
  5. f.close()


  1. package main
  3. import (
  4. "os"
  5. "log"
  6. "fmt"
  7. )
  9. func main() {
  10. f, err := os.Create("hello.txt")
  11. if err != nil {
  12. log.Fatal(err)
  13. }
  14. if _, err := fmt.Fprintf(f, "Hello, World!\n"); err != nil {
  15. log.Fatal(err)
  16. }
  17. if _, err := fmt.Fprintf(f, "Next line.\n"); err != nil {
  18. log.Fatal(err)
  19. }
  20. if err := f.Close(); err != nil {
  21. log.Fatal(err)
  22. }
  23. }

This is not quick to write and is one of the few places where explicit error handling in Go is unhelpful. Our script is no more robust for handling these errors explicitly.

Neugram is designed to help with scripts like these.

Neugram is set -e for Go:

  1. #!/usr/bin/ng
  3. import "os"
  4. import "fmt"
  6. f := os.Create("hello.txt")
  7. fmt.Fprintf(f, "Hello, World!\n")
  8. fmt.Fprintf(f, "Next line.\n")
  9. f.Close()

The elided errors in the Neugram program will turn into panics if they are non-nil. The result is a script which is not too much wordier than the python version, while taking advantage of all my Go knowledge. If you are a Go programmer, this may be interesting to you.

What’s next

Go is syntactically a big language. Neugram’s front end has to match it, and that’s a lot of work, much of which is still to do. The mountain of bugs is my first priority.

If you want to help out, try writing something and file all the bugs you run into (you will) on the issue tracker.

After that there are several other language extensions I’m interested in, focusing on making Neugram a good language for data analysis. In particular:

I am hesitant to enter any discussion about programming languages, especially given how much more work Neugram needs to be generally usable. But there is only so long I can work quietly on a project, so I may as well at least admit it exists. Let me know what you think on the mailing list.

By David Crawshaw (@davidcrawshaw)

ft_authoradmin  ft_create_time2017-11-01 10:56
 ft_update_time2017-11-01 10:58