From: Robert Klemme <bob.news@...>
Date: 2005-09-29T20:51:44+09:00
Subject: Re: Lisp macros

Bob Hutchison wrote:
> On Sep 29, 2005, at 3:46 AM, Robert Klemme wrote:
> 
>> Well, I think my point focused around the fact whether a language
>> allows
>> for code modification at runtime (regardless of whether you use it
>> or not;
>> I'm rather trying to grasp the nature of the language if you
>> will).  You
>> can do that with Lisp and as far as I understood it's a core
>> feature of
>> the language.  You can't do that with standard C (well, you *can*
>> but that
>> typically involves features not part of the language like shared
>> objects).
> 
> You are right about run-time changes to lisp being an important
> capability. The fun thing is that you don't actually need to eval or
> compile anything inside the program being modified. You have to
> compile for sure, but that can be done outside by the developer then
> loaded into the running image -- no eval happens. There are also very
> interesting things you can do with returning functions from functions
> that don't require eval (this can be a bit astonishing the first time
> you see it, and every now and again after the first time :-) Here is
> a quick example:
> 
> (defun make-a-function (n)
>    (lambda (m) (* n m)))
> 
> is returning a compiled run-time generated function (with no eval,
> not even a hidden one :-)

Yeah, that's right.  Same for Ruby.  No compilation needed for closures.

>> (A funny consequence seems to be that you can view machine code as a
>> dynamic language...)
> 
> Very dynamic. Every now and again when I was working in assembler (a
> while ago now :-)

I remember doing Z80 assember - wow, this was *long* ago!

> we made use of that (in fact, one computer I worked
> on had instructions built into it that explicitly supported changing
> the code). These days machine code as a dynamic language comes up
> every now and again as a 'buffer overrun attack' :-)

LOL - how true!

Thanks for the discussion!

Kind regards

    robert