> even lowly shr is still in process of being changed to be more in line with 
> other languages (a good thing IMO)

which completely broke 
[cello]([https://github.com/unicredit/cello](https://github.com/unicredit/cello))
 :-(

> the latest memory management model eliminating GC is huge and excellent!

We will have to see, it may very well alienate the already small pool of Nim 
users

> if much simpler languages such as Elm can automatically turn recursive 
> "procs" into loops, surely Nim could too

It is easy to do TCO for self-recursive function. It is essentially not doable 
in general, unless one controls the generated assembly (you have to omit a 
stack frame). This is why Nim relies on GCC and Clang to do it. For comparison, 
Scala is in the same position, since it lives in the JVM, and in fact Scala 
only supports TCO for self-recursive functions

> A cleaner syntax for Algebraic Data Types... this must also be supported in 
> pattern matching

Not ideal, but this is doable with macros, see 
[patty]([https://github.com/andreaferretti/patty](https://github.com/andreaferretti/patty))
 and 
[gara]([https://github.com/alehander42/gara](https://github.com/alehander42/gara))

> currying and the related partial function application

The issue here is not varargs (well, it may be but most functions do not use 
varargs anyway). The thing is that partial application turns any function into 
a closure over the partially applied arguments, with the obvious cost. If you 
really want it, this is again doable with macros, see 
[currying]([https://github.com/t8m8/currying](https://github.com/t8m8/currying))

Reply via email to