C closures & lexical scoping

[cr88192]

I'm oriented to object to your suggestions...

are you saying these statements are not concurrent?...

 

[James Kuyper]

often cases, yes.

none the less, people tend to dislike this kind of thing in C land (even as
such, it happens sometimes), albeit it is a very common occurance in most
non-C languages (where there are hidden runtime calls pretty much
everywhere...).

Why do you think people tend to dislike it, and why do you think it's an
uncommon feature of C compilers? Whether it's better to implement a
feature using a function call or by inlining the code that would
otherwise be in such a function is precisely the kind of optimizing
detail that I want the compiler to worry about, not me.

 

[Richard Bos]

A functional programmer will sneer at this feeble attempt at higher-order
programming.

A real programmer will laugh at that feeble attempt to equate "more
abstracted" with "higer order".

Richard

 

[Chris Dollin]

A real programmer will laugh at that feeble attempt to equate "more
abstracted" with "higer order".

So feeble an attempt that it wasn't one. [You did realise that, yes?]

 

[cr88192]

Why do you think people tend to dislike it, and why do you think it's an
uncommon feature of C compilers?

having compilers that produce code unsuitible for OS development is one
reason.
in userspace, there is less reason for concern.

Whether it's better to implement a feature using a function call or by
inlining the code that would otherwise be in such a function is precisely
the kind of optimizing detail that I want the compiler to worry about, not
me.

well, the reason it would involve a function call, is because it would have
to allocate memory for the binding frames (an inherently non-inlining
operation).

worse yet, absent GC, of explicitly freeing function pointers (probably via
a special function), there is no real way to know when exactly these
closures/binding frames are no longer needed, so one will end up with a
memory leak...

 

[jameskuyper]

having compilers that produce code unsuitible for OS development is one
reason.
in userspace, there is less reason for concern.

I've developed code exclusively in user space, so I'm unfamiliar with
the requirements of OS developement. Why would the occurrence of a
function call to implement, for instance, long long multiplication on
a 16-bit platform, render the code unsuitable for such development?

well, the reason it would involve a function call, is because it would have
to allocate memory for the binding frames (an inherently non-inlining
operation).

This isn't my area of expertise, so I'm not quite sure what that
sentence means. However, I suspect that it doesn't mean what you
intended it to mean. It sounds to me like you've reversed cause and
effect; surely the function call is the reason for the binding frames,
not vice-versa? The reason for involving a function call would be to
reduce the code size; the reason for inlining the function call would
be to reduce execution time. Binding frames, as you've described them,
seem very expensive; they would seem, if anything, to be a reason for
not involving a function call.

worse yet, absent GC, of explicitly freeing function pointers (probably via
a special function), there is no real way to know when exactly these
closures/binding frames are no longer needed, so one will end up with a
memory leak...

Again, this isn't my area of current expertise, but back when I did do
assembly language programming, in none of the three languages I
learned did executing a function require allocation of memory in a
fashion that was difficult to deallocate. Memory was allocated as
needed from the stack by the simple expedient of changing the value of
a register, and it was returned to the stack by the simple expedient
of restoring the original value of that register. I'm sure more
complicated schemes are needed on other platforms.

I'm sure that you're talking about something much more complicated
than what I'm thinking of. But is there any reason why "inserting
runtime function calls ... whenever we use certain language features"
has to refer to what you're thinking of, rather than what I'm thinking
of?

 

[Chris Dollin]

cr88192 wrote:

Again, this isn't my area of current expertise, but back when I did do
assembly language programming, in none of the three languages I
learned did executing a function require allocation of memory in a
fashion that was difficult to deallocate. Memory was allocated as
needed from the stack by the simple expedient of changing the value of
a register, and it was returned to the stack by the simple expedient
of restoring the original value of that register. I'm sure more
complicated schemes are needed on other platforms.

I'm sure that you're talking about something much more complicated
than what I'm thinking of. But is there any reason why "inserting
runtime function calls ... whenever we use certain language features"
has to refer to what you're thinking of, rather than what I'm thinking
of?

I believe he's exclusively thinking of support for upward closures
(ie nested functions that access outer locals and are also exported
out of the enclosing function), and he seems to think that constructing
such a closure would /have/ to involve a function call.

It's true that an upward closure claims store that there's no way of
freeing without GC (or some extra run-time functionality, eg a
`freeClosure` function, and the necessary discipline to keep track
of whether a function is or is not a closure, bleach), and it's false
that constructing the closure would /need/ a function call, although
it might be /sensible/ to put sharable construction code into a
library function.

 

[James Kuyper]

(e-mail address removed) wrote: ....

I believe he's exclusively thinking of support for upward closures
(ie nested functions that access outer locals and are also exported
out of the enclosing function), and he seems to think that constructing
such a closure would /have/ to involve a function call.

Sorry, I should have realized the comment about "certain features" was
meant to be a reference to the subject of this thread. I thought that
the discussion had wandered off-subject, and that this was just a
generic gripe about all language features that an implementation might
implemented using function calls. I apologize for wasting people's time
with my misunderstanding.

Discussions that stay on-subject! What will they think of next?

 

[cr88192]

I believe he's exclusively thinking of support for upward closures
(ie nested functions that access outer locals and are also exported
out of the enclosing function), and he seems to think that constructing
such a closure would /have/ to involve a function call.

It's true that an upward closure claims store that there's no way of
freeing without GC (or some extra run-time functionality, eg a
`freeClosure` function, and the necessary discipline to keep track
of whether a function is or is not a closure, bleach), and it's false
that constructing the closure would /need/ a function call, although
it might be /sensible/ to put sharable construction code into a
library function.

yes, I had failed to take something into account here.

an example would be, keeping a linked list of free binding frames, and
directly grabbing frames from this list (issues: making this thread safe,
....).

implicitly though, I had assumed something that would amount to a full
fledged frame-allocator, whose internal details would remain hidden from the
compiler.