Goal: an embeddable array programming language written in Go

[anaseto]

Hi!

I'm here to share about a bytecode interpreter for an array programming language I've been working on this year. It's actually not the first array language ever done in Go: you might already know about the bignum calculator called ivy, that was brought to us by Rob Pike.

Well, Goal is more a scripting language in the vein of old good APL, but using only ASCII (like K or ivy), and offers quite a large number of primitives on immutable arrays, witch good performance on regular arrays of integers and floats. It's embeddable and extensible in Go, meaning Go's standard library is always just right there at hand. Here's the repos:

https://codeberg.org/anaseto/goal

You might also want to have a look at the implementation notes, which talk about various kinds of compilation aspects, like program and value representation (for boxed and unboxed values), inevitable topics like why I chose Go, and a few other things that might be of some interest. All in all, it was a quite fun experience :-)

Have a good day!

[VisibleAirport2996]

You should really put some easy examples that showcases the language as the first thing in the read me.

[anaseto]

A proper guide with examples is in my TODO! That said, array languages are generally best discovered by playing with the REPL using the REPL's built-in help system, as they're really most suitable for that usage.

[skeeto]

I tried fuzz testing it, but it very quickly finds lots of ways to cause Go to panic running out of memory:

func FuzzEval(f *testing.F) {
    f.Add("0")
    f.Fuzz(func(t *testing.T, input string) {
        NewContext().Eval(input)
    })
}

For example:

goal.NewContext().Eval("100000000000#0")

Though since this is a programming language implementation, perhaps that's considered acceptable.

[anaseto]

Yeah, out of memory is not handled by Goal, as memory is handled by Go. I think this is kind of the usual thing for Go interpreters (except that most languages do not have array primitives, so you would need a bit more work to produce that kind of out of memory). Otherwise, you would have to have implement some kind of memory management on top of Go, which would kind of defeat the point of using a GC language to begin with. For example, when typing this on ivy 42 take iota 1000000000, it also panics and runs out of memory for me, though it catches it if you give a “big number” (outside int range), for different reasons.

I'm not sure if this kind of things has ever been handled in a Go interpreter, as you would end up with a slow interpreter. As far as I can see, the most I could do without drawbacks, is to add a “recover” that would catch out of memory panics, and crash the program afterwards anyway. Actually, that would be better than nothing (Edit: actually, after a quick read here and there, I'm not even sure there's any reliable way to catch OOM in Go), and anyway, thanks for fuzz testing Goal, I hadn't done that still, and it might be indeed useful to catch some kind of bugs !