Unlimited extent closures

I've been doing some thinking about minimal feature sets of a
programming language, and it seems to me that unlimited extent lexical
closures pretty much mandates some kind of automatic storage
management from the runtime.

Well, perhaps not if you provide a closure deletion operation. The
problem with *that*, however, is that closure deletion is not just a
simple free() of the memory; knowledge of the closed object types is
required.

Anybody have any thoughts on this?

david rush

kumoyuki@gmail.com (David Rush) writes:

> I've been doing some thinking about minimal feature sets of a
> programming language, and it seems to me that unlimited extent lexical
> closures pretty much mandates some kind of automatic storage
> management from the runtime.

You failed to describe the most important criterion: do you want
memory management to be sound (every object deleted was safe to
delete)?

Shriram

Shriram Krishnamurthi <sk@cs.brown.edu> writes:
> kumoyuki@gmail.com (David Rush) writes:
> 
>
> You failed to describe the most important criterion: do you want
> memory management to be sound (every object deleted was safe to
> delete)?

Actually, no. Heresy I know, but I'm looking at building a bastard
hybrid of Scheme and C. I'd actually like to leave automatic storage
management out - for the admittedly dodgy reason of interacting nicely
with C programmers who are used to unconstrained use of malloc().

I've been trying to decide which Scheme features I can live
without and automatic storage management is a strong candidate for
exclusion. So far this has led me to the minimal set of Schemish-ness
that I want being:

first-class anonymous closures
full TCO
s-expression syntax and macros

david rush
--
From the start...the flute has been associated with pure (some might
say impure) energy. Its sound releases something naturally untamed, as
if a squirrel were let loose in a church.       -- Seamus Heaney

In article <ckdtjo$hp2$1@pixie.nscp.aoltw.net>, David Rush wrote:
> Shriram Krishnamurthi <sk@cs.brown.edu> writes: 
>
> Actually, no. Heresy I know, but I'm looking at building a bastard
> hybrid of Scheme and C. I'd actually like to leave automatic storage
> management out - for the admittedly dodgy reason of interacting
> nicely with C programmers who are used to unconstrained use of
> malloc().

It might be worthwhile to look at using explicit regions for this.
They make it very cheap and easy to dynamically check whether a
dereference is safe, so you could retain safe, checked memory access
even though it might be unsound.

--
Neel Krishnaswami
neelk@cs.cmu.edu