compiled and interpreted functions

Greeting Lispers!

I just need to sort some things out.


1. Let's say I have this function

(defun make-adder (num)
  (lambda (x)
    (+ num x)))

When make-adder is a compiled function, the closure it produces is compiled too. When make-adder isn't a compiled function, the closure also isn't compiled.

Question: is it possible for a compiled function to produce an uncompiled closure function?


2. When I inspect an interpreted function in the gui inspector, I can see the 'code' attribute. Is there a way to access that attribute and change the code of the function to a new code?


3. When I do (disassemble ..) to an interpreted function, I can see the machine code. As I got it, disassemble compiles any interpreted function before showing its output. Is it true?

Best,
 Art



p.s. Is there a difference between this

(defun make-adder (num)
  (lambda (x)
    (+ num x)))

and this

(defun make-adder (num)
  (function (lambda (x)
     (+ num x))))

Re: compiled and interpreted functions

Unable to parse email body. Email id is 10671

Re: compiled and interpreted functions

On Sat, 23 Oct 2010 08:28:23 +0100, Nick Levine <ndl@ravenbrook.com> wrote:

> Not straightforwardly. And of course children what follows is just a
> thought experiment, as we all know that eval is evil.

It is not the first time I come across this statement (that eval in run  
time is evil), however there were never any arguments accompanying it and  
I could not think of my own.

Re: compiled and interpreted functions

On Sat, 23 Oct 2010 19:39:01 +0100, Tim Bradshaw <tfb@cley.com> wrote:

> - by the same token, EVAL makes it pretty hard to ever prove that  
> something is not used, which makes tree-shaking hard;

This one looks like a valid enough reason, however I think Graham used  
this idiom in that form or the other in his early 90s books on Lisp.

The question arises, was the concept of tree-shaking used nowadays for  
stand-alone executive files delivery in wide-spread acknowledgement then?

P.S. I could be wrong about dating these notions altogether, actually.

Re: compiled and interpreted functions

"Yuri Davidovsky" <yury.davidouski2@mail.dcu.ie> writes:

> On Sat, 23 Oct 2010 19:39:01 +0100, Tim Bradshaw <tfb@cley.com> wrote:
>
>> - by the same token, EVAL makes it pretty hard to ever prove that
>> something is not used, which makes tree-shaking hard;
>
> This one looks like a valid enough reason, however I think Graham used
> this idiom in that form or the other in his early 90s books on Lisp.
>
> The question arises, was the concept of tree-shaking used nowadays for
> stand-alone executive files delivery in wide-spread acknowledgement
> then?
>
> P.S. I could be wrong about dating these notions altogether, actually.

It would depend on the application.  

If you're writing an emacs, you want to call EVAL on user provided forms
at run-time.

If you're writing a Notepad, you don't.

If you're writing an MS-Word, you would have to write a Basic-to-Lisp
translator before calling EVAL, or just write a Basic interpreter.


-- 
__Pascal Bourguignon__                     http://www.informatimago.com/

Re: compiled and interpreted functions

On Sat, 23 Oct 2010 20:11:42 +0100, Pascal J. Bourguignon  
<pjb@informatimago.com> wrote:

> If you're writing an emacs, you want to call EVAL on user provided forms
> at run-time.
> If you're writing a Notepad, you don't.
> If you're writing an MS-Word, you would have to write a Basic-to-Lisp
> translator before calling EVAL, or just write a Basic interpreter.

It appears that if one writes anything with a certain level of scripting  
capability it would likely require EVAL of some form and amount.

User script would be converted into Lisp code by macros and then  
evaluated, that would be the easiest solution for custom script support.