@Araq:
> Much effort went into 0.20 to improve the docs.
I think all of us greatly appreciate the work that went into this, and need to
see if the omissions I noted are still there. I already see that many have been
fixed.
> The docs have 'Edit' buttons.
I just noticed those and will start to use them.
> I wish F# had good overloading. :P
Yes, I guess it's a trade-off overloading versus Hindley-Milner. Your
overloading system is beautiful and now that I am used to it, I don't want to
give it up at the cost of a few type annotations which are often a good idea
for documentation purposes anyway. I'm with you on this. And we still have auto
for return value signatures if we want to use it!
> I'm hearing you but Nim is an imperative core plus a macro system. We never
> claimed anything else -- if I wanted Haskell, I know where to find it.
Yes, I know where to find Haskell, too, and I wouldn't want Nim to be like
Haskell either, maybe more like F# (without H-M type inference) with mutability
versus immutability optional just as we already have by choosing to use let or
var bindings...
@bpr:
> Indeed, going 'full functional' would be terrible, and overloading is great.
As I replied to Araq above, I agree with you and don't want "full functional",
only optional functional.
> one thing I wish Nim would take from ML/Haskell/Rust is the algebraic data
> types.
Yes, that is my point 2. Object variants actually are ADT's but just with too
much boilerplate for both declaring them and pattern matching on them. We could
use a library of macros to help, but it would be nice to be a part of the
language. The nice thing is that it would be an add-on that wouldn't break
existing code as in all my suggestions (other than removing varargs if
necessary).
Note that I recognize that we **may** have TCO by the back end compiler, but it
**isn 't guaranteed** and may not be in force in debug modes when optimization
isn't turned on. Thus we can't write tail called functions knowing that they
won't blow the stack for some compiler modes. I would be satisfied with just
guaranteed recursion within the same proc, but I think it may be possible to
extend to the possibility of some cross proc recursion, although it may take
some {.recursive.} pragma notations to do it.
