If this has macros it gives people "generic" programming in Go at the cost of having to write it all in a lisp dialect. I wouldn't personally mind it but some might :-p

"Macros are supported via Racket's macro system define-syntax, define-syntax-rule and defmacro."

So yes. :-)

As an aside, seeing more bitbucket hosted libraries on HN lately. This is a good thing. I am a fan of the github product, but I am bigger fan of not putting all your eggs in one basket.

I have repo's on github, bitbucket, and gitlab :)

I wish there were actual examples doing some I/O or http server where error handling comes into picture (which IMO the primary thing that messes up the Go code syntactically by repeating the "if err != nil {" block).

So basically the crux of this is 100 lines of a macro[0]. Am I reading this right?

https://bitbucket.org/ktg/lfgo/src/a7f71aec7d29d00100f2d21c2...

The macro is really a bunch of case statements, so they can be interpreted independently.

...and half of those are comments, no? (ie. the ones starting with a ';')

This and Lisp-flavored Erlang make me wonder how far one could take the idea of a Lisp syntax atop some other language. As a half-joke, I wonder if one could make a Lisp-flavored C work; should I fear or be slightly bemused at the idea of a Lisp-flavored COBOL?

Author here. L++ (Lisp-flavored C++) https://bitbucket.org/ktg/l

Amplifying C

https://news.ycombinator.com/item?id=11054089

Does this racket-based transpiler provide a REPL?

I was wondering something similar, can I just use Dr Racket for this? :)

I would say yes since Racket is a Programming Language for making Programming Languages :)

It looks similar to the oden language.

https://github.com/oden-lang/oden

And Gisp.

https://github.com/jcla1/gisp

I am surprised that I didn't think about this till now but Go has simple enough syntax to where Lisp could be translated into Go code, and I wonder why Haxe doesn't translate into Go with that same thought. Go definitely has plenty of libraries at it's disposal standard library wise.

Is the name a pun on LFO (low frequency oscillator)?

More than likely along the same lines as Lisp Flavored Erlang - http://lfe.io

But.. why?

Oh god. They basically just took Go and added unnecessary parenthesis. This is the worst way to make Go LISP-like.

In my opinion, people who complain about Lisp's parentheses are usually the ones that have absolutely no idea about Lisp, nor have they any experience with it. Once you get "into" Lisp, you do not see it as a bunch of parentheses anymore, so focusing on this aspect suggests that the person who does it, does not really have much previous experience with Lisp.

Plus the fact that a decent editor will handle the parentheses for you.

When programming in Lisp, I use Emacs with paredit (for inserting and manipulating parentheses, quotation marks, etc.) and have the default colour for parentheses be very similar to my background colour, so I can focus on the symbols and their indentation instead. The exception is when the cursor is next to an open/close parenthesis, in which case the matching parenthesis is highlighted.

Yeah.

    func(a,b) => (func a b)

    if ( a > b) {  => (if (> a b) something)
      // something
    }

What's the best way to make Go more LISP-like?

Keep the functional semantics and functions, but with the basic Go syntax. If, as others have said, they don't see the parenthesis after using LISP for a while, then why bother adding them into Go in the first place?