4 ms·

I find it amusing that this first program in Go is for parsing an Lisp-style S-Expression, given that this has nothing to do with Go's syntax.

thwarted 10y ago
Most programs do something other than parse the syntax of the language they are written in. A programming language really only needs to be self-hosting once, and that may be an early program, but it seems unlikely it is the very first.
- rev_null 10y ago
  Yes, but most programming languages are around for a few years before someone tries to use them to implement another language.
  - coldtea 10y ago
    Toy s-expression parsers are on an equal footing with "Hello World" regarding their complexity. It's not like they tried to implement some full Lisp/Scheme.
wtbob 10y ago
One of my backlog-projects is an implementation of Common Lisp in Go, which can be easily used to provide an embedded scripting language for Go programs (and, eventually, an excuse to write 'Go' code which is actually Lisp). It's one of those crazy ideas I'll probably never get to, but it sure would be fun.
- frou_dh 10y ago
  I have ~that. Of course it's not Common Lisp though (so, Hubris Lisp?). Notably you have to statically register the Go functions you want to be callable from the Lisp side, because otherwise they might not even be present in the compiled binary (and even if they were, I don't think Go will help you find an arbitrary function by name at runtime). I've used it much more as a normal 'shebang' shell scripting language (even ""webapps"" via CGI) than an embedded one so far... mainly through lack of ideas that call for such a thing.
  - coldtea 10y ago
    >and even if they were, I don't think Go will help you find an arbitrary function by name at runtime You'd be surprised: https://golang.org/pkg/reflect/#Value.MethodByName https://golang.org/pkg/reflect/#Value.MethodByName
    - frou_dh 10y ago
      That's about methods and not functions ;) Yes indeed, if you are partying in the context of a specific value, you can use that reflection. My language is not "OO"-aware though. Maybe after I give the embedded mode more real world use then that aspect will be unavoidable.
      - coldtea 10y ago
        A, yes. In that case you could expose all the functions you want in advance, in some map that's accessible by (string) name.
        frou_dh 10y ago
        // Static err = rootEnv.DefineForeignProcedure("sprintf", fmt.Sprintf) # Runtime (let x 2 (sprintf "%d cubed is %d" x (pow x 3))) => "2 cubed is 8"
        coldtea 10y ago
        Yep, that's what I was talking about.

thwarted 10y ago

Most programs do something other than parse the syntax of the language they are written in. A programming language really only needs to be self-hosting once, and that may be an early program, but it seems unlikely it is the very first.

rev_null 10y ago
Yes, but most programming languages are around for a few years before someone tries to use them to implement another language.
- coldtea 10y ago
  Toy s-expression parsers are on an equal footing with "Hello World" regarding their complexity. It's not like they tried to implement some full Lisp/Scheme.

wtbob 10y ago

One of my backlog-projects is an implementation of Common Lisp in Go, which can be easily used to provide an embedded scripting language for Go programs (and, eventually, an excuse to write 'Go' code which is actually Lisp). It's one of those crazy ideas I'll probably never get to, but it sure would be fun.

frou_dh 10y ago
I have ~that. Of course it's not Common Lisp though (so, Hubris Lisp?). Notably you have to statically register the Go functions you want to be callable from the Lisp side, because otherwise they might not even be present in the compiled binary (and even if they were, I don't think Go will help you find an arbitrary function by name at runtime). I've used it much more as a normal 'shebang' shell scripting language (even ""webapps"" via CGI) than an embedded one so far... mainly through lack of ideas that call for such a thing.
- coldtea 10y ago
  >and even if they were, I don't think Go will help you find an arbitrary function by name at runtime You'd be surprised: https://golang.org/pkg/reflect/#Value.MethodByName https://golang.org/pkg/reflect/#Value.MethodByName
  - frou_dh 10y ago
    That's about methods and not functions ;) Yes indeed, if you are partying in the context of a specific value, you can use that reflection. My language is not "OO"-aware though. Maybe after I give the embedded mode more real world use then that aspect will be unavoidable.
    - coldtea 10y ago
      A, yes. In that case you could expose all the functions you want in advance, in some map that's accessible by (string) name.
      - frou_dh 10y ago
        // Static err = rootEnv.DefineForeignProcedure("sprintf", fmt.Sprintf) # Runtime (let x 2 (sprintf "%d cubed is %d" x (pow x 3))) => "2 cubed is 8"
        coldtea 10y ago
        Yep, that's what I was talking about.