[plt-scheme] Re: HTDP: So you thought us empty? and empty

Systems that implement proper tco (and call/cc) know how to deal with 
deep stacks
such as the one for my-make-list. (An overflow is just a "simple 
minded" callcc and
off you go on a new stack.) If n=200 won't break Xanalys, n=20000 will. 
(I bet that
there are CL's with tco now.) -- Mattthias


On Saturday, December 6, 2003, at 08:21 PM, Felix Klock's PLT scheme 
proxy wrote:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
> As much as I'd love to jump in and congratulate Guenther as well, I 
> think its important to point out that the recursive call in the code 
> he wrote is not tail-recursive.
>
> For comparison purposes, here is some CL that I believe *is* 
> tail-recursive.  Guenther: you should see if you can get the below 
> working in your CL distribution (I don't have one handy to test it 
> on).  If this version works without any need to increase the 
> stack-size, then you really can't blame the folks at Xanalys (well, 
> except that maybe they shouldn't impose a fixed limit on the stack 
> size for their runtime).
>
> (defun my-make-list (n)
>    (my-make-list-accum n nil))
>
> (defun my-make-list-accum (n accum)
>   (cond
>     ((< n 1) accum)
>     (t (my-make-list (- n 1) (cons nil accum)))))
>
> -Felix
>
>>> (defun my-make-list (n)
>>> (cond
>>>  ((< n 1) nil)
>>>  (t (cons nil (my-make-list (- n 1))))))
>
>
> On Dec 6, 2003, at 8:13 PM, Matthias Felleisen wrote:
>
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>> Good for you. Good programmers stand up for their rights, and one of 
>> them is tail-recursion. It's the only way to match your program's 
>> structure to the structure of the data. Everything else is buggy over 
>> the long run. -- Matthias
>>
>>
>> On Saturday, December 6, 2003, at 08:02 PM, Guenther Schmidt wrote:
>>
>>>  For list-related administrative tasks:
>>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>
>>> Dear Matthias,
>>>
>>> apologies for *firing* this off.
>>>
>>> I'm switching back and forth between PLT Scheme and Lispworks (CL) 
>>> and just to make it up to you I'll show you what I just *fired* at 
>>> Xanalys five minutes before:
>>>
>>>
>>> Hi,
>>>
>>> I heard that one of the differences between Scheme and CL is that 
>>> Scheme is "proper tail recursive" and CL isn't. Until today I'm not 
>>> 100% what that could mean but I think I'm seeing an effect of it 
>>> here.
>>>
>>> (defun my-make-list (n)
>>> (cond
>>>  ((< n 1) nil)
>>>  (t (cons nil (my-make-list (- n 1))))))
>>>
>>> If I run this on Lispworks with let's say merely n=200 I get a stack 
>>> overflow, if I run it in Scheme with +100000 I just have to wait a 
>>> little, but no stack overflow.
>>>
>>> What I really do like about CL and Scheme is the excessive use of 
>>> recursion, and the parenthesis too.
>>> Does this mean I need to switch back to iteration when dealing with 
>>> lists of over 200 elements in CL?
>>> Setting the *stack-size* to a higher level?
>>>
>>> If so ............. STUFF THAT!!!
>>>
>>> Guenther
>>>
>>>
>>>
>>> Matthias Felleisen wrote:
>>>
>>>>  For list-related administrative tasks:
>>>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>> Use Pretty Big for now. -- Matthias
>>>> On Saturday, December 6, 2003, at 07:20 PM, Guenther Schmidt wrote:
>>>>>  For list-related administrative tasks:
>>>>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>>>>
>>>>> ..... in HTDP.
>>>>>
>>>>> But as soon as one switches to MrED it turns out that's not even 
>>>>> part of the standard.
>>>>>
>>>>> What exactly was the point of teaching us empty? and empty ?
>>>>>
>>>>> I mean I'm sure that I will find a function that is the equivalent 
>>>>> of the above because there just has to be, but what was the point?
>>>>>
>>>>> Best regards
>>>>>
>>>>> Guenther
>>>>>
>>>>> BTW I figure it is "null"
>>>>>
>>>