Dynamic function generation, HOW?

I am very facinated by the fact that lisp can generate functions on the
fly.  But what facinates me even more is where is this chunk of code in
the form of a new function allocated? on the heap, or on the stack, ...
There is something I am missing here.  Can someone please explain me
how this works?

+---------------
| I am very facinated by the fact that lisp can generate functions on the
| fly.  But what facinates me even more is where is this chunk of code in
| the form of a new function allocated? on the heap, or on the stack, ...
+---------------

On the heap.

Or rather, in one of the heaps, depending on how your specific
implementation's GC works. That is, there might be a heap for
code that is different for the heap used for conses, say.
Or code might go into a (sub)heap that uses mark-and-sweep GC
instead of 2-space-copying, to avoid the need for code
relocation at GC time. That sort of thing.


-Rob

-----
Rob Warnock			< XXXX@XXXXX.COM >
627 26th Avenue			<URL: http://www.**--****.com/ ;
San Mateo, CA 94403		(650)572-2607

Thanks Rob.  That makes sense.  I am usually uncomfortable when
programming in lisp because I cannot tell what the code is going to
look like at run-time.  Any suggestions for a book that explains the
compilation / interpretation of lisp code and the lisp runtime ?

sanket.

In article < XXXX@XXXXX.COM >,




Although you *can* generate code on the fly in Lisp, it's not a very 
common thing to do.

The Lisp runtime accomplishes it basically by having a built-in compiler 
and dynamic linker.

-- 
Barry Margolin,  XXXX@XXXXX.COM 
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***

+---------------
| I am usually uncomfortable when programming in lisp because I
| cannot tell what the code is going to look like at run-time.
+---------------

Are you "uncomfortable when programming in C or C++ because you
cannot tell what the code is going to look like at run-time"?
If not, then why are you uncomfortable when programming in Lisp?

If so, then what do you do about it in C or C++? Answer: Probably
the same thing people do in Lisp, that is, write a small test case
and see what it compiles into:

    > (defun +/2-arg/fast (a b)
	(declare (fixnum a b)
		 (optimize (speed 3) (safety 0)))
	(the fixnum (+ a b)))

    +/2-ARG/FAST
    > (compile *)
    ; Compiling LAMBDA (A B): 
    ; Compiling Top-Level Form: 

    +/2-ARG/FAST
    NIL
    NIL
    > (disassemble *)
    4850A288:  .ENTRY +/2-ARG/FAST(a b) ; (FUNCTION (FIXNUM FIXNUM) FIXNUM)
	  A0:  POP   DWORD PTR [EBP-8]
	  A3:  LEA   ESP, [EBP-32]
	  A6:  ADD   EDX, EDI           ; No-arg-parsing entry point
	  A8:  MOV   ECX, [EBP-8]
	  AB:  MOV   EAX, [EBP-4]
	  AE:  ADD   ECX, 2
	  B1:  MOV   ESP, EBP
	  B3:  MOV   EBP, EAX
	  B5:  JMP   ECX
	  B7:  NOP
    > 


-Rob

-----
Rob Warnock			< XXXX@XXXXX.COM >
627 26th Avenue			<URL: http://www.**--****.com/ ;
San Mateo, CA 94403		(650)572-2607

When programming in C/C++, atleast I have a conceptual idea about how
function calls and stacks and heap etc. work.

Its just that I would like to know how things like passing and
returning functions as data, returning multiple values etc happen at
the low level.

But thanks for (disassemble *).  I didn't know about it.  will
definitely use it from now on.

sanket.

You might find L.i.S.P. interesting:
 http://www.**--****.com/ 





-- 
Lars Rune Nstdal
 http://www.**--****.com/ 

 XXXX@XXXXX.COM  writes:


How many programming languages do you know that provide their own one
page long interpreter?  What better conceptual idea can you get than
reading the source of EVAL?

Read SICP!
 http://www.**--****.com/ 
(cf Chapter 4)

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

ADVISORY: There is an extremely small but nonzero chance that,
through a process known as "tunneling," this product may
spontaneously disappear from its present location and reappear at
any random place in the universe, including your neighbor's
domicile. The manufacturer will not be responsible for any damages
or inconveniences that may result.

Thanks! Thats exactly what I was looking for.

sanket.

Pascal Bourguignon < XXXX@XXXXX.COM > writes:


You can also watch video lessons:

 http://www.**--****.com/ 

 XXXX@XXXXX.COM  writes:


I think this is the wrong approach.  What you need to do is understand
the conceptual model of what the lisp semantics imply.  In essence you
need to understand the virtual machine that lisp and its {*filter*}tics
provide.  Understanding the implementation details is generally
unnecessary and often counter-productive, especially since the actual
implementation can vary depending on the lisp vendor and even the
underlying architecture.

For example, the way to understand cons cells and lists is at the level
of the box-and-pointer diagrams, not in terms of the layout of a cons
cell in memory.  The latter can be done in one of several ways, and
depending on OS and hardware, has not always been done the same way.
Sometimes an entire cons cell fits into a single machine word, sometimes
it takes two such words.  Sometimes the type information is encoded in
the lower order bits, other times not.  But knowing that doesn't help
you understand the important notions of structure sharing and other list
properties the way the box-and-pointer view does.

So, to answer the original question:  It doesn't matter where lisp
allocates the function code's storage.  All you need to know is that the
code is sufficiently persistent that it can be used when in-scope and
accessible.  It may be on the heap, it may be on the stack (given
appropriate declarations), it may be in some other data structure.


-- 
Thomas A. Russ,  USC/Information Sciences Institute

Thank you all for the informative replies!

I will try to concentrate more on the conceptual model of lisp, and not
the low level details.

And will definitely check out (time) and (disassemble) to understand
performance of my code.

One question though:  I have heard that lisp code can be compiled into
a stand-alone x86 executable.  But how does the GC work then?  In C# or
Java for example, code is compiled to the language of the underlying
runtime (bytecodes).  And the runtime takes care of GC.  So does a lisp
stand-alone executable need any run-time, or does it have GC code
built-in?


...off to becoming a lisp fan.

sanket.

 XXXX@XXXXX.COM  writes:


You are still worrying about low level stuff.  It just happens!



Now, the short answer is that yes, there's a run-time library, like in
C or any other programming language (but possibly barebones
assembler).


A slightly longer answer would be that there are broadly two kinds of
garbage collectors: precise garbage collectors and conservative
garbage collectors.

Conservatives garbage collectors scan the memory and whatever bit
pattern that looks like a pointer is considered to be a pointer to
some live memory block.  These GC don't need to know anything about
the program or the type of the data, but some memory might not be
collected just because there's some random bit pattern in the memory
that looks like a pointer to it.  See for example BoehmGC. 

Precise garbage collectors on the other hand need to know the type of
the data to be able to locate precisely the pointers.  This can be
done statically or dynamically, both with the help of the compiler.
Dynamically, the type of the data is recorded along with the data: we
have type tags.

For the long answer, read the sources of various implementations.


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

CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.

In article < XXXX@XXXXX.COM >,




Of course it needs a run-time library.  Forget about GC, where do you 
think all the built-in functions like OPEN, MEMBER, etc. live?

The CONS function is also in the runtime library (just as malloc() is in 
the C runtime library), and GC is just part of the implementation of 
that function (as well as other object allocators like MAKE-ARRAY, 
MAKE-INSTANCE, etc.).

-- 
Barry Margolin,  XXXX@XXXXX.COM 
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***