g-fu

I find Clojure refreshing, but it has too many agendas for me and Java is just (a) no Go. I tried, I did. And launching the repl felt like watching grass grow on my latest/greatest macbook. And if I'm going to use a Lisp in Go, I definitely prefer one designed around Go to one imported from Java. The Clojure-code I've written, while terse; always feels too far off from what I want to say. I have the same issues with Haskell, too much hoop jumping to take part in someone else's quest for purity. There's plenty I like in there and Rich is a very disciplined thinker. The languages have much in common. g-fu's way of using environments looks a lot like Clojures use of maps if you squint. Transducers are brilliant, it's difficult for me to believe it took this long. Which is why g-fu uses [0] them as the foundation for all sequence transformati

You would have to wrap the call in a g-fu prim [0] for now. As for dynamically loading libraries, the plan is to implement g-fu libraries that call out as plugins. I have yet to dig into reflection to see how much effort an FFI would take. [0] https://github.com/codr7/g-fu/blob/master/v1/src/gfu/abc.go

Author here. It's still a young language and naive implementation focused on correctness, but I'm very happy with how its turning out. I'm especially fond of first class environments and qualified identifiers [0]; which allow composing, overriding and delegating data and behavior in a convenient yet remarkably flexible way. It's clearly a more fundamental mechanism than the usual suspects. Note that this is the opposite of what Python is doing with __dict__ and Lua with tables. Rather than basing the implementation on a general purpose data structure, g-fu exposes the the implementation and allows hooking into it. It reminds me of pcostanza's work on Context Oriented Programming and ContextL [1], but integrated rather than bolted on. [0] https://github.com/codr7/g-fu/tree/master/v1#environments [1] https://github.com/pcostanza/contextl

Macros, interpreters and embedded languages [0]. [0] https://github.com/codr7/g-fu/tree/master/v1

Word. Interpreter, but close enough :) https://github.com/codr7/g-fu/tree/master/v1

Go makes composition less powerful than it could be by slicing structs, which means a lot of hoop jumping to get template methods (where blanks are filled in downstream). I've been playing around with first class environments [0] lately in g-fu [1], which allow convenient and flexible composition of data and behavior using only what was already there. I have a feeling Lua might be playing similar tricks with its tables, but I lack enough experience to judge. [0] https://github.com/codr7/g-fu/blob/master/v1/lib/eos.gf [1] https://github.com/codr7/g-fu

I recently implemented a simple object system [0] using only closures and macros in a Lisp-dialect [1] I'm working on. One thing that struck me is how little it bothers me that objects look like functions from the outside, and that any callable value could be used in their place. It helps that the whole thing is quarantined in a separate library and that objects live in a separate namespace. And that it rests on top of a strongly typed environment. Judging a type system outside of its context based on some arbitrary check list is pretty useless from my experience. [0] https://github.com/codr7/g-fu/blob/master/v1/doc/functional_... [1] https://github.com/codr7/g-fu/tree/master/v1

Embedding Lisp as a scripting language is a nice way to balance performance vs. expressive power from my experience. I recently started working on something similar [0] in Go. [0] https://github.com/codr7/g-fu