@Araq: > import compiler / ast.nim, produce an AST, use renderer.nim to produce source > code or use the rest of Nim's compilation pipeline.
Thank you very much for that, as it would seem to be useful for any language that wanted to use Nim for its back end; it would also be useful if I decided to ignore your advice and try to convert a FP languge's AST to use Nim as a back end ;-)... > But please don't invent yet another FP language. We have enough of these > already and they are all pretty bad. There aren't so many FP languages once one eliminates all of the ones that are dynamically typed, which I refuse to use, and even less of the remaining ones can produce native code. Haskell is the only language that has all of my criteria, but it is GC and saddled with the "everything is lazy" problem in reasoning about use of resources, which even Simon Peyton-Jones has expressed some regrets in deciding to use. Also, Haskell contributors don't place raw performance as high on their list of priorities as I would like, as evidenced in the state of the Native Code Generator (NCG) which has a terrible register allocator; if were not for the optional LLVM back end, the code generated from Haskell would never be at all competitive, and sometimes it seems like the LLVM back end is treated as a nice option but not a must-have. Also, fully optimizing through LLVM isn't easy and sometimes Haskell doesn't quite nail it (again partly because it isn't a priority), unlike languages like Rust where code output through LLVM is the only way. I also see that many potential FP programmers are stymied by the learning cost of entry for Haskell, and see that there exists a need for a simpler FP language something like F# or even simpler in Elm. > Recursions easily introduce performance problems and tail recursions with > lots of accumulator parameters is procedural programming in denial. I haven't run into performance problems using tail call recursions, and find that loops written this way with a smart"ish" compiler gets compiled into about the same native code as generated by an imperative language such as Nim. > And monads don't compose well. ;-) Hmm, I agree with this as I've seen the hoops that FP programmers jump through when managing multiple monads within the same "loop" context, and usually restrict my use of monads to only one at a time to prevent this. My use of monads is usually limited to controlling mutation within a monadic chain, which I can do without the complexities. > And if you don't agree, that's fine, just use Haskell already instead of > wasting a tremendous amount of time into designing and implementing a "more > sophisticated Elm". I already use Haskell when appropriate, but lament the complexity in its use, which isn't really because it's FP but rather a whole ecosystem that has grown up around it in its 35 years of development as and experimental and academic language. I suppose that it wouldn't be too much work to convert Haskell's AST to Nim's, but the expectation of Haskell's GC is deeply ingrained into its code and one still has the problem of always having to deal with laziness/"non-strictness". I know that I would never complete "designing and implementing" a new FP language in my lifetime. I only propose forking Elm, re-enabling a couple of features that are currently turned off, eventually having some form of type classes as an often requested feature (and one the BDFL has been considering for about seven years without rejecting it but also without coming up with an implementation), and converting the AST to Nim instead of JavaScript. The amount of code to change to do with converting the AST is only about 2500 lines, which I think I could handle in a few months. If the project is a success (as in useful to others and garnering some support), I would like to make the language self hosting rather than having the compiler written in Haskell as it currently is, but I know that would likely take me years without the help of some productive contributors. That said, Evan Czaplicki, the BDFL likely wrote the original version in about a year, although the code now includes the utilities of `repl`, `install` (for packages), `init`, `make`, `publish` etc., and a online source compiler/page server `reactor`; however, one would be mostly just translating into a similar (but simpler) FP language, so it might not take that long, although testing would need to be thorough.
