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

From: Guenther Schmidt (gue.schmidt at web.de)
Date: Sun Dec 7 09:15:26 EST 2003

Boy have I just been getting wipped on the Lispworks mailing list, I guess I was just asking for trouble. :-(

Guenther

Matthias Felleisen wrote:

>  For list-related administrative tasks:
>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
> 
> 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"
>>>>>>
>>>>
> 
> 




Posted on the users mailing list.