Re: [racket] Tail recursive module cons

On 29/03/2014 03:54, Yuhao Dong wrote: Using accumulator+reverse won't really improve the runtime at all. Every other benchmark has (unfortunately) shown the opposite. I think that tail recursion doesn't help at all, and introduces conceptual overhead. Racket doesn't use the stack, and conver

Re: [racket] Tail recursive module cons

On Mar 29, 2014, at 8:45 AM, Yuhao Dong wrote: > I think my point still holds that tail recursion in the case I posted > does not improve performance The purpose of transforming a program into tail-call shape is to save space. It does NOT necessarily improve performance. [[ I do not understa

Re: [racket] Tail recursive module cons

Thanks. I probably mixed it up also with the implementation of the compiler targeting C of Chicken Scheme, which basically just converts everything to continuation-passing style. I think my point still holds that tail recursion in the case I posted does not improve performance. At least the timing

Re: [racket] Tail recursive module cons

Yuhao Dong wrote: The thing is, Racket's "stack" is a list of continuations. I don't see how explicitly keeping the "stack" in an accumulator would help. Stack overflow won't be a problem since the "stack" is a list on the heap, and unless memory runs out you wont overflow. I think that tail

Re: [racket] Tail recursive module cons

Some comments: 1) Never run benchmarks inside DrRacket (I suspect this is what you did because the reported times are high) 2) Why do you include the garbage collections in the time measurment? That's probably not what you want to measure (plus the gc should before the calls) 3) The need to call `r

Re: [racket] Tail recursive module cons

Using accumulator+reverse won't really improve the runtime at all. The thing is, Racket's "stack" is a list of continuations. I don't see how explicitly keeping the "stack" in an accumulator would help. Stack overflow won't be a problem since the "stack" is a list on the heap, and unless memory ru

Re: [racket] Tail recursive module cons

Matthias wrote: What does tail-recursion modulo cons mean? Some of my favourite academic paper titles: Friedman and Wise, "CONS should not evaluate its arguments" Baker, "CONS should not CONS its arguments" --PR Racket Users list: http://lists.racket-lang.org/users

Re: [racket] Tail recursive module cons

Basically, avoiding growing the stack when building a list, by compiling this program: (define (list-id l) (if (null? l) l (cons (car l) (list-id (cdr l) into this one: (define (list-id* l acc) (if (null? l) (set-cdr! acc null) (let ([p (cons (car l) #f)]) (set-cdr

Re: [racket] Tail recursive module cons

What does tail-recursion modulo cons mean? On Mar 16, 2014, at 3:38 PM, Sam Tobin-Hochstadt wrote: > On Sun, Mar 16, 2014 at 2:55 PM, Patrick Useldinger > wrote: >> >> >> My questions are: >> >> (1) Is Racket "tail-recursive modulo cons"? If not, is there a reason for >> this? > > Racket

Re: [racket] Tail recursive module cons

On Sun, Mar 16, 2014 at 2:55 PM, Patrick Useldinger wrote: > > > My questions are: > > (1) Is Racket "tail-recursive modulo cons"? If not, is there a reason for > this? Racket is not "tail-recursive modulo cons". > (2) Is the last example "reverse free" or does it use reverse under the > hood?

[racket] Tail recursive module cons

Greetings everybody, Let's assume we want a procedure that doubles every even? number of a list. The recursive way would be something like: (require rackunit) (define parms '(1 2 3 4 5)) (define result '(4 8)) (define (f-recursive lst) (if (null? lst) null (let ((c (car lst)))