Re: [Gcl-devel] Re: SLIME

[Eric Merritt]

--- Camm Maguire <address@hidden> wrote:
> Greetings, and thanks for the reference!
> 
> 1) These are not part of the ANSI standard, correct?

 True,  they were reject from the standard.

> 2) That being said, I think the public doamin
> implementation cited
> will likely compile as is under ansi gcl.  Perhaps
> we could distribute
> as a module like the tk interface?

 It doesn't compile out of the box, but it probably
wouldn't take an experienced lisper long to get it up
and running under ansi gcl. 

 As for distributing it, I have no idea if the fsf
considers public domain compatable with the gpl/lgpl.
If they don't have a problem with it then distributing
it would not be a problem either.

> 3) Any progress on the sibling call front?  

 Not yet unfortunatly. All my 'easy' roughts of
finding solutions to this type of thing (searching the
'net, various mailing lists etc) haven't turned up
anything. The only thing I can think of doing now is
to get a good test case and ask the gcc list.

> I think
> I remember reading
> somewhere that gcc can optionally output a file
> listing the sibcall
> optimizations it performed.  Cannot find it right
> now.  Might be of
> interest in adding a compiler note like the current
> one regarding
> simple tail recursion call optimization.

  That output option gives me another avenue of attack
that might be helpfull. I will look around and see if
I can figure out how and where to do that.

 As for the compile message, thats probably a really
good idea. The sibcall optimizations change the
behavior of the program slightly and its a good idea
to inform the coder of that change. 

> Separately, I'm wondering if there is anything
> particularly functional
> about lisp arising from its design alone, which I
> consider to be
> primarily defined by the 'code is data' feature.

  I don't really think of lisp as fighting directly
into any of the 'standard' paradigms. In my mind lisp
is more of a meta-langauge then anything else.
Changing  lisp/gcl to fit closly into a specific
paradigm is probably not a good idea. As it currently
is lisp allows me to build whatever paradigm I need to
fit my problem domain.

 That said, I dont consider tail call optimization to
be the domain of functional languages. True, most
functional languages implement it and most
imperative/object oriented langauges do not, but that
doesn't mean its functional in nature. As far as I am
concerned tail call optimization is just a usefull
optimization that compilers can and should implement.

>  I
> know that acl2
> goes to great lengths to be functional, and I wonder
> if this is
> connected with their original decision to write in
> lisp.  In other
> words, how valuable is sibling call optimization in
> a lisp system?

 It depends on how much people make use of tail calls
and mutual recursion. It also depends on how much
people would make use of tail calls if they didn't
have the possibility of stack usage exceptions. 

  There are many problems that recursion just works
exceedingly well for. Not that these things can't be
done with iteration, but recursion just makes for a
more readable and elegant solution. 

 So I guess the answer is this, tail call optmization
is usefull and desirably. However, you can do with out
it. So if it can be implemented in a reasonable amount
of time with a resonable set of resources its worth
doing otherwise it may be best to put it on hold until
more resources are available.


        
                
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover