4 ms·

I've toyed with this idea a bit (compiling a more familiar language down to Clojure). This project in particular gives some of the benefits of Clojure (JVM, ex

I've toyed with this idea a bit (compiling a more familiar language down to Clojure). This project in particular gives some of the benefits of Clojure (JVM, expressive language, immutability), but I don't see any easy way to add new constructs to the language like macros without modifying the compiler itself. Can you modify the grammar that is fed to Instaparse at runtime? That being said, the current branding and name confused me initially. I was expecting a full Go to Clojure compiler, but it appears that this is mainly a language that has similar syntax to Go which compiles to Clojure, which is still very cool, just different.

stcredzero 12y ago
What do macros have to do with being functional? It might be better for a functional language to have that, but it doesn't have to have such a facility.
- fisher-lebo 12y ago
  Macros have nothing to do with being functional, but macros are one of the major advantages of Clojure, and ideally there would be similar functionality in a language based on it (though not necessary).
eobrain 12y ago
I do not plan to add to Funcgo the ability to easily create macros. Inspired by Go's philosophy, I want to limit the scope of the language to keep it somewhat simple. Funcgo however can use macros, so a sufficiently motivated programmer can write macros in Clojure and use them in Funcgo. Thanks for the feedback on the impression the name and branding gave. I'll try to change the main pages to make clear that Funcgo is not full Go, and is a fairly thin layer on top of Clojure.
- vorg 12y ago
  > a sufficiently motivated programmer can write macros in Clojure and use them in Funcgo The Clojure "syntax" is best for writing macros, whereas the Funcgo syntax is best for writing, and later easily reading, other code. There's nothing wrong with writing code in two languages, one at a higher level up the abstraction stack than the other. I tried putting such a C/C++/Java/C#/JS/Scala/Groovy/Go/etc-like syntax atop Clojure last year (called "Grojure"). After many iterations, I found each iteration became thinner and thinner, and the functionality more and more aligned with Clojure's. I didn't publish my last attempt because it had evolved into a much simpler 3-step application: 1. lex the tokens, which had different syntax to their equivalents in Clojure 2. define the prefix and infix operators, in their precedence hierarchy, including syntax for function calls 3. define the syntax for the statements, which mapped almost directly to macros which did the processing The macro linking all three steps together fed the output from step 3 into step 1 to enable interpolated strings. The operators in effect were defined by an enveloping statement, and could be changed in the syntax. If I'd tried another iteration of Grojure, I would have probably merged that step into the 3rd, and used your incanter/infix macro to process them, reducing it all to two steps. And perhaps some of the lexing of step 1 could have been replaced by the Clojure 1.4 tagged elements. Despite going through all this, I'm still left with a sense of how unnatural it is to read S-expressions whenever I see Clojure or Lisp code, and think the two syntaxes idea (lisp for macros, C/Go for the rest) could be the solution. But there was one possible snag specific to my/your situation I came across. Grojure, like FuncGo, is atop 2 or 3 other languages: * Grojure/FuncGo sits atop... * Clojure, which sits atop... * Java/the JVM, which is written in, and using JNI can call software written in, ... * C and/or C++. I had the idea of only enabling my equivalent of FuncGo to access one layer only below. So one would need to use Clojure to write not only the macros, but also functions to wrap all Java/JVM functionality required at the Grojure/FuncGo layer. I never got around to implementing that because in the end I decided 3 layers was a layer too many. Hope you work your way around this issue.
  - eobrain 12y ago
    Glad to hear someone else has been thinking about this. Interesting idea to use macros to implement the mapping from the Go syntax tree. Presumably, these macros would implement the same kind of logic that my codegen module implements (mapping from the Go syntax tree to Clojure text). https://github.com/eobrain/funcgo/blob/master/src/funcgo/codegen.go https://github.com/eobrain/funcgo/blob/master/src/funcgo/cod...

stcredzero 12y ago

What do macros have to do with being functional? It might be better for a functional language to have that, but it doesn't have to have such a facility.

fisher-lebo 12y ago
Macros have nothing to do with being functional, but macros are one of the major advantages of Clojure, and ideally there would be similar functionality in a language based on it (though not necessary).

eobrain 12y ago

I do not plan to add to Funcgo the ability to easily create macros. Inspired by Go's philosophy, I want to limit the scope of the language to keep it somewhat simple. Funcgo however can use macros, so a sufficiently motivated programmer can write macros in Clojure and use them in Funcgo. Thanks for the feedback on the impression the name and branding gave. I'll try to change the main pages to make clear that Funcgo is not full Go, and is a fairly thin layer on top of Clojure.

vorg 12y ago
> a sufficiently motivated programmer can write macros in Clojure and use them in Funcgo The Clojure "syntax" is best for writing macros, whereas the Funcgo syntax is best for writing, and later easily reading, other code. There's nothing wrong with writing code in two languages, one at a higher level up the abstraction stack than the other. I tried putting such a C/C++/Java/C#/JS/Scala/Groovy/Go/etc-like syntax atop Clojure last year (called "Grojure"). After many iterations, I found each iteration became thinner and thinner, and the functionality more and more aligned with Clojure's. I didn't publish my last attempt because it had evolved into a much simpler 3-step application: 1. lex the tokens, which had different syntax to their equivalents in Clojure 2. define the prefix and infix operators, in their precedence hierarchy, including syntax for function calls 3. define the syntax for the statements, which mapped almost directly to macros which did the processing The macro linking all three steps together fed the output from step 3 into step 1 to enable interpolated strings. The operators in effect were defined by an enveloping statement, and could be changed in the syntax. If I'd tried another iteration of Grojure, I would have probably merged that step into the 3rd, and used your incanter/infix macro to process them, reducing it all to two steps. And perhaps some of the lexing of step 1 could have been replaced by the Clojure 1.4 tagged elements. Despite going through all this, I'm still left with a sense of how unnatural it is to read S-expressions whenever I see Clojure or Lisp code, and think the two syntaxes idea (lisp for macros, C/Go for the rest) could be the solution. But there was one possible snag specific to my/your situation I came across. Grojure, like FuncGo, is atop 2 or 3 other languages: * Grojure/FuncGo sits atop... * Clojure, which sits atop... * Java/the JVM, which is written in, and using JNI can call software written in, ... * C and/or C++. I had the idea of only enabling my equivalent of FuncGo to access one layer only below. So one would need to use Clojure to write not only the macros, but also functions to wrap all Java/JVM functionality required at the Grojure/FuncGo layer. I never got around to implementing that because in the end I decided 3 layers was a layer too many. Hope you work your way around this issue.
- eobrain 12y ago
  Glad to hear someone else has been thinking about this. Interesting idea to use macros to implement the mapping from the Go syntax tree. Presumably, these macros would implement the same kind of logic that my codegen module implements (mapping from the Go syntax tree to Clojure text). https://github.com/eobrain/funcgo/blob/master/src/funcgo/codegen.go https://github.com/eobrain/funcgo/blob/master/src/funcgo/cod...