Twik: a tiny language for Go

[Gustavo Niemeyer]

In case you're not in the Google+ community, we've just published a
small leg of an experiment that is part of a larger project at
Canonical:

http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go



gustavo @ http://niemeyer.net

[David DENG]

A List that can be embedded with go?

David

[Mateusz Czapliński]

On Wednesday, July 17, 2013 4:45:08 AM UTC+2, Gustavo Niemeyer wrote:

http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go

Why:

    func Parse(fset *ast.FileSet, name string, code []byte) (ast.Node, error)
    func ParseString(fset *ast.FileSet, name string, code string) (ast.Node, error) 

not:

    func (fset *ast.FileSet) Parse(name string, code []byte) (ast.Node, error)
    func (fset *ast.FileSet) ParseString(name string, code string) (ast.Node, error)

?

/M.

[Jan Mercl]

On Wed, Jul 17, 2013 at 3:33 PM, Mateusz Czapliński <czap...@gmail.com> wrote:
> not:
>
> func (fset *ast.FileSet) Parse(name string, code []byte) (ast.Node,
> error)
> func (fset *ast.FileSet) ParseString(name string, code string)
> (ast.Node, error)

That's not valid Go.

-j

[Mateusz Czaplinski]

Heh, thanks, right, that would explain it :)

/M.

[Mateusz Czapliński]

On Wednesday, July 17, 2013 4:45:08 AM UTC+2, Gustavo Niemeyer wrote:

http://blog.labix.org/2013/07/16/twik-a-tiny-language-for-go

Also, (how) does it aim to differentiate itself from e.g.:

  - https://github.com/bytbox/kakapo
  - https://github.com/bobappleyard/golisp

?

Thanks,
/M.

[wkharold]

Interesting, but beware of: Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

[SteveD]

On Wednesday, July 17, 2013 4:54:26 PM UTC+2, wkharold wrote:

Interesting, but beware of: Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

It does make more sense to embed a battle-tested scripting language like Lua, which has most of the fun of Lisp without the parentheses overload.
 

[Dave Cheney]

Lua implementation in Go anyone ? Cgo bindings need not apply.

[luz...@gmail.com]

On Wednesday, July 17, 2013 4:54:26 PM UTC+2, wkharold wrote:

Interesting, but beware of: Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

That explains why the first Go program ever was a Lisp interpreter (actually just an s-expression parser). :)

http://blog.golang.org/first-go-program

[luz...@gmail.com]

There's a JavaScript interpreter in pure Go:

https://github.com/robertkrimen/otto 

[steve donovan]

On Thu, Jul 18, 2013 at 11:42 AM, Dave Cheney <da...@cheney.net> wrote:

Lua implementation in Go anyone ? Cgo bindings need not apply.

It would be an entertaining exercise - it's been done a number of times for Java and for C# (Robert Virding even did one for Erlang).  I know the C# translation fairly well and it's a very literal translation which works ok - the weakness is in the emulation of the C standard libraries which Lua builds on.  Jim Whitehead did a translation of Lua's excellent string library into Go once.  Basically possible but not for the faint-hearted; the advantage of such a version is that it would be goroutine-friendly from the word go.

[David DENG]

found one: http://go-search.org/search?q=Lua+pure+go

David

[Alexei Sholik]

> It does make more sense to embed a battle-tested scripting language like Lua

> Lua implementation in Go anyone ? Cgo bindings need not apply.

Kind of defeats the purpose, no?

On Thu, Jul 18, 2013 at 12:42 PM, Dave Cheney <da...@cheney.net> wrote:

Lua implementation in Go anyone ? Cgo bindings need not apply.

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Best regards
Alexei Sholik

[Alexei Sholik]

Just to be clear: Lua's primary implementation is 100% portable C and it is alone used all over the place on all possible platforms. So I think "Lua" was referring to "the Lua implementation" in the first quote. That one is indeed battle-tested.

[Martin Angers]

Yes, I did start a pure Go implementation of the Lua VM a while back. It does run very simple Lua programs compiled to binary bytecode using luac (v5.2 if I recall correctly). It is pretty much abandoned (I should update the README), but feel free to fork and hack away.

[Mateusz Czapliński]

On Thursday, July 18, 2013 11:42:18 AM UTC+2, Dave Cheney wrote:

Lua implementation in Go anyone ? Cgo bindings need not apply.

Some time ago I started: https://github.com/akavel/goluago
Long-term goal is to transition to pure-Go, but as an intermediate goal, I'm trying to port Lua (written in ANSI C) to Go suite's internal ANSI C compiler (i.e. cc, known better as 8c/6c/5c/...)
As a (planned) byproduct, I'm also creating: https://github.com/akavel/gostdc - a port of C Standard Library to Go platform, for others to be able to use it in similar ventures in future.
Things are going well and forward, albeit at somewhat leisure pace (it's a totally hobby project, so when I'm frustrated, be it with some hard bugs, or some boring work approaching, I sometimes ditch it for some time, or else, but then come back again and push it forward again).

At the moment, the core Lua (parser & VM, but not including full standard libraries) seems to WORK very well! ...on x86. On x64 I'm having some bugs as of now. (Will have to compare memory dumps with regular Lua probably, again). I have some slightly more advanced code privately, but for this project I like to release controlled snapshots on important milestones.

If you fancy, any help with any of those projects will be highly appreciated. Please CC me privately if you'd like to access the newer code, although less commented etc.

Cheers,
/Mateusz Czapliński.
 

[Kevin Gillette]

That's a somewhat ironic choice considering that while Lua has an excellent C API, its language commonly makes opposite choices to those which Go would have when readability and cleverness are in conflict.

[Jan]

Hm, what about a Go interpreter that could be easily embedded in a compiled Go program ? 

I found this, http://www.unicorn-enterprises.com/express_go.html, but looks unsupported (not converted to newest version of Go) and not embed-able.

cheers :)

[Lars Seipel]

On Thu, Jul 18, 2013 at 06:18:12AM -0700, Mateusz Czapliński wrote:
> As a (planned) byproduct, I'm also creating:
> https://github.com/akavel/gostdc - a port of C Standard Library to Go
> platform, for others to be able to use it in similar ventures in future.

Hmm, are you aware of APE[1]? It's an Unix compatibility environment for
Plan 9 and it does include an ANSI libc.

It seems that, at least on Plan 9, APE is sufficient to build recent Lua
versions. Some parts of it might be of help to you.

Lars

[1] http://plan9.bell-labs.com/sys/doc/ape.html

[steve donovan]

On Fri, Jul 19, 2013 at 8:01 PM, Jan <pfe...@gmail.com> wrote:

Hm, what about a Go interpreter that could be easily embedded in a compiled Go program ? 

It's a good idea, and there's definitely all the parts hanging around. But it's a big job to get such an interpeter to the reliable state that embedders need.

It's understood that the idea is not to run Go programs 'faster' (Go is already nice & fast to compile) but for plugins - dynamically loading functionality. Bonus points if it supports a REPL.  This does some violence to the original semantics - in a REPL you're always evaluating statements as if they're in the main function. 

 

[Mateusz Czaplinski]

On Sat, Jul 20, 2013 at 6:58 AM, Lars Seipel <lars....@gmail.com> wrote:

On Thu, Jul 18, 2013 at 06:18:12AM -0700, Mateusz Czapliński wrote:
> As a (planned) byproduct, I'm also creating:
> https://github.com/akavel/gostdc - a port of C Standard Library to Go
> platform, for others to be able to use it in similar ventures in future.

Hmm, are you aware of APE[1]? It's an Unix compatibility environment for
Plan 9 and it does include an ANSI libc.

[sorry to all for steering the original thread OT]

Didn't know! Interesting, thanks. Now, I've tried to locate the sources, but I'm having hard time with that: I understand that for headers I should look at:
    http://plan9.bell-labs.com/sources/plan9/sys/include/ape/
    http://plan9.bell-labs.com/sources/plan9/${ARCH}/include/ape/

But where am I to find the .c files? I've found something looking familiar at:
    https://github.com/wangeguo/plan9/blob/master/sys/src/ape/lib/bsd/strdup.c

but that's only one, and what about other stuff, like math, etc?

Hmm, found something more at:
    https://github.com/wangeguo/plan9/tree/master/sys/src/ape/lib/ap

Is this all I should need?

Thanks,

/Mateusz Czapliński.

[alphonse twentythree]

A lisp interpreter implemented in Go... woop de do. 

[Lars Seipel]

On Sat, Jul 20, 2013 at 02:10:46PM +0200, Mateusz Czaplinski wrote:
> But where am I to find the .c files?

The files should be available at (seems down at the moment):
http://plan9.bell-labs.com/sources/plan9/sys/src/ape

They are also contained in the regularly regenerated ISO images. Oh,
and you can always run Plan 9 and mount sources via 9P. ;-)

[Kevin Gillette]

On Saturday, July 20, 2013 1:08:15 AM UTC-6, SteveD wrote:

It's understood that the idea is not to run Go programs 'faster' (Go is already nice & fast to compile) but for plugins - dynamically loading functionality. Bonus points if it supports a REPL.  This does some violence to the original semantics - in a REPL you're always evaluating statements as if they're in the main function.

Especially if such an interpreter, if feasible, is designed such that it exposes an API that any compile-and-gob or compile-and-dynload systems that already exist or may eventually come along could conform to, allowing the "embedders" to write pluggable code into systems that could be swapped out according to their particular needs.