4 ms·

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 s

• 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...