@andrea: > We will have to see, it may very well alienate the already small pool of Nim > users (with the new non-GC memory model)
I think that @Araq is right that it won't affect most users as it just works behind the scenes, just like GC. I really like the idea and hope it turns out that way :) > It is easy to do TCO for self-recursive function. It is essentially not > doable in general... There are ways to do it without eliminating the stack frame by making it a connected series of loops - see below... > Not ideal, but this is doable with macros (ADT;s and pattern matching on > them)... Yes, I assumed as much, but again, it would nice to have the ability built-in. > with the obvious (preformance) cost (of closures). If you really want it, > this is again doable with macros, see currying (library) Yes, I had seen the currying library and know the cost; the question would be whether the cost can be eliminated or optimized away when one calls the function as non-curried with all its arguments? This is lower in the priority list, but one can write some slick code using it, and sometimes one doesn't have to eek out the last CPU machine cycle but having elegant code is more the priority. That can apply whenever applying FP principles although it doesn't always cost performance: TCO implemented as loops doesn't but makes the code appear to use immutability as in code safety without apparent side effects; ADT's and pattern matching don't have too cost performance but are an elegant way to express variable data structures as we already have with variant objects, just they are kludgy to use; with the right optimizations, this currying and partial function application would only cost when actually used. I agree with you that losing varargs in order to gain this would hardly be missed as long as an alternate implementation for echo/write/writeLn made these appear to be working with varargs. If syntax changed, no matter how slightly, we would catch some flak for the change. If it were to be done, it would be better before version 1.0. These could be implemented as macros in just turning the arguments into strings by keeping varargs for templates and macros but not for proc or func. @Tristano: > if Nim were to support labels to mark code positions and some kind of GoTo > like statement, maybe tail-recursion could be worked around by them... Nim has labeled blocks and breaks to blocks which is somewhat of a "goto" and could likely be used. @jxy: > You could write a macro that does TCO for self-recursive functions, > essentially turning it into a while loop. Mutually recursive functions are > more difficult to deal with, but is feasible by inlining the procedures and > sprinkling a couple of goto's. Yes, that was what I was thinking, but would like it to be built in so one wouldn't need to add a library.
