Newsgroups: comp.lang.scheme
Path: cantaloupe.srv.cs.cmu.edu!das-news.harvard.edu!news2.near.net!MathWorks.Com!news.duke.edu!news-feed-1.peachnet.edu!emory!swrinde!pipex!uknet!festival!edcogsci!usenet
From: tfb@cogsci.ed.ac.uk (Tim Bradshaw)
Subject: Re: Scheme _in_ Emacs?
In-Reply-To: wgd@zurich.ai.mit.edu's message of 3 Sep 94 20:56:34
Message-ID: <TFB.94Sep5132531@burns.cogsci.ed.ac.uk>
Followup-To: comp.lang.scheme
Sender: usenet@cogsci.ed.ac.uk (C News Software)
Nntp-Posting-Host: burns
Organization: Centre for Cognitive Science, University of Edinburgh
References: <RAMSDELL.94Aug17063434@triad.mitre.org> <TTHORN.94Aug17150829@ceres.daimi>
	<RAMSDELL.94Aug24085039@triad.mitre.org>
	<WGD.94Aug25012615@martigny.ai.mit.edu>
	<TFB.94Aug31020302@oliphant.cogsci.ed.ac.uk>
	<WGD.94Sep3205634@martigny.ai.mit.edu>
Date: Mon, 5 Sep 1994 12:25:30 GMT
Lines: 66

* William G Dubuque wrote:
> (Tim Bradshaw) writes:
>    From: tfb@cogsci.ed.ac.uk (Tim Bradshaw)

>    * William G Dubuque wrote:
>> Could someone clarify just why they think it is impossible to obtain
>> proper tail-recursion in GNU Emacs lisp? Perhaps the concern is about
>> efficiency vs. implementability.

>    I'm not quite sure what you mean by this.  

>    If you mean `is it possible for elisp to be properly tail recursive'
>    the answer is `no' because of dynamic scope, i.e consider

>        (defun foo ()
> 	  (let ((bar 3))
> 	     (scumble)))

>        (defun scumble ()
> 	  ... use bar )

>    (this sort of thing isn't fixed by the CL emulation either of course
>    and it affects other stuff than tail recursion).

> What does the above example have to do with tail recursion?  The
> original poster stated that there is "no way to implement proper tail
> recursive functions" (I've appended the post below).

What I meant was is that there is no way for an implementation of a
language with elisp's semantics (ie dynamic scope) to *optimize* tail
calls in the way that scheme requires.  You can't optimize a tail call
by throwing away the stack frame of the function because the function
you call can legitimately refer to the bindings you have made.  That
was what my example was doing: the tail call to scumble can't be
optimized.  That call could equally well be a recursive call to foo of
course:

    (defun foo (rec)
      (if rec
	  bar
	(let ((bar 3))
	  (foo t))))
            
> I thought the major issue was that without low-level support for tail
> recursive calls, you quickly exhaust stack space (esp. considering
> that iteration occurs tail-recursively).

I think that the v19 byte interpreter does have this -- at least the
comments in the src imply that it could be done, but it can't be done
(in general) for elisp without it being a different language.  It is
worth reading JWZ's comments in byte-optimize.el about this stuff.

>    If you mean `is it possible to implement a tail recursive language in
>    elisp' the answer is obviously `yes' -- just write a byte interpreter
>    in elisp for instance.  This probably isn't something you want to do
>    if you want the resulting language to coexist with existing elisp
>    code.

> Huh? What's wrong with it coexisting?

Well making calls to elisp having elisp make calls to it painlessly, 
implementing bits of emacs in it &c.  Of course you could *do* all
this but it would be terribly slow and painful I expect, which is fine
if you just want a proof it can be done

--tim
