3 ms·

Pidove sounds really awesome. I'm totally going to give that a try!

PaulHoule 4y ago
It has a sibling project which is still half-baked https://github.com/paulhoule/ferocity https://github.com/paulhoule/ferocity which is about developing a lispy DSL in which it is possible to write Java-in-Java to transform it to make syntactic macros. It's kinda crazy https://github.com/paulhoule/ferocity/blob/main/ferocity0/src/test/java/com/ontology2/ferocity/TestUrFierce.java https://github.com/paulhoule/ferocity/blob/main/ferocity0/sr... and somebody might think it combines the worst of Java and Common LISP but I did enough work on it to be sure there were no major barriers. ferocity0 is a bootstrap implementation that it's possible to write a code generator that can generate code to make stubs for the standard library and write ferocity1 in ferocity0 and write ferocity2 in ferocity1 with the full power of code generation to hide the accidental complexity of Java... But other projects got in the way.
- brabel 4y ago
  Looking at your examples, this looks like https://github.com/square/javapoet https://github.com/square/javapoet
  - PaulHoule 4y ago
    Yeah, that’s very similar. Thanks for the link. It’s got the difference though that they are using (mostly) strings to write the method bodies and my approach builds those up with the lispy DSL. The class/method/field definitions are basically the same. (ferocity contains three languages, one of expression trees, one of class definitions, another of compound statements that doesn't exist yet) Mine can also run ‘lispy Java’ in an interpreted mode (as well as writing code that goes through javac) and I discovered the interpreter has a type system which is a little richer than the Java type system, namely I discovered (not invented) ‘quote’ and ‘eval’ so that expressions are a first class data type that can be manipulated…. I have to define some set of operators to make it easy to traverse and work on expressions which would make it easy to metaprogramming, probably taking back some of the verbosity that comes with the lispy java-in-java embedding.

It has a sibling project which is still half-baked https://github.com/paulhoule/ferocity https://github.com/paulhoule/ferocity which is about developing a lispy DSL in which it is possible to write Java-in-Java to transform it to make syntactic macros. It's kinda crazy https://github.com/paulhoule/ferocity/blob/main/ferocity0/src/test/java/com/ontology2/ferocity/TestUrFierce.java https://github.com/paulhoule/ferocity/blob/main/ferocity0/sr... and somebody might think it combines the worst of Java and Common LISP but I did enough work on it to be sure there were no major barriers. ferocity0 is a bootstrap implementation that it's possible to write a code generator that can generate code to make stubs for the standard library and write ferocity1 in ferocity0 and write ferocity2 in ferocity1 with the full power of code generation to hide the accidental complexity of Java... But other projects got in the way.

brabel 4y ago
Looking at your examples, this looks like https://github.com/square/javapoet https://github.com/square/javapoet
- PaulHoule 4y ago
  Yeah, that’s very similar. Thanks for the link. It’s got the difference though that they are using (mostly) strings to write the method bodies and my approach builds those up with the lispy DSL. The class/method/field definitions are basically the same. (ferocity contains three languages, one of expression trees, one of class definitions, another of compound statements that doesn't exist yet) Mine can also run ‘lispy Java’ in an interpreted mode (as well as writing code that goes through javac) and I discovered the interpreter has a type system which is a little richer than the Java type system, namely I discovered (not invented) ‘quote’ and ‘eval’ so that expressions are a first class data type that can be manipulated…. I have to define some set of operators to make it easy to traverse and work on expressions which would make it easy to metaprogramming, probably taking back some of the verbosity that comes with the lispy java-in-java embedding.