[Openmcl-devel] Allocate heap and call C question

[Andrew P. Lentvorski, Jr.]

On Jul 6, 2004, at 6:15 PM, Dan Knapp wrote:

>   I don't have a lot to say on this question, but...
>
>   If the language were to be extended, a more Lisp-like way would be 
> to offer a
> special form which allocates an object outside the Lisp heap... but 
> with a
> lifetime determined lexically, ie, lasting only until the body of the 
> form finishes
> executing.  Behind the scenes, the deallocation would be done by having
> unwind-protect call the appropriate function.
>
>   I don't have an opinion yet on whether that would be a good thing; 
> but it
> would certainly be better than using explicit deallocation.  You could
> implement it yourself, Andrew, fairly easily.

For small allocations, this kind of lexical scoping can be done on the 
stack using rlet and rletZ (or, at a lower level, using %stack-block).

For large allocations on the heap, you probably don't want to do an 
allocate, copy, send to C, copy on return, and deallocate as an 
automatic operation based upon lexical lifetime.  The allocated object 
is likely to persist across C calls, callbacks, etc.  Even some small 
allocations want to persist (ie. pointers to GUI elements don't want to 
be cleaned up).

Basically, the useful analog would be for small allocations on the heap 
vs. small allocations on the stack.  Personally, I don't like the idea 
of giving too much access to the stack, but that is personal religion 
and paranoia speaking rather than solid experience.  However, the small 
stack allocations have been said to be much faster.  *shrug*

That having been said, I will personally probably default to the heap.

However, I will try to reserve full judgment until I have some 
experience with these mechanisms in real use.  Once I can actually put 
together a basic Gtk application, I'll probably have a much better 
perspective.

-a





%stack-block, %vstack-block, with-cstr, rlet, rletZ


I'm leaning toward not, but onl


>
> -- Dan Knapp
>
> _______________________________________________
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
> http://clozure.com/mailman/listinfo/openmcl-devel