Re: malignant closure remnant

RKRayhawk wrote:
> I have some questions and I encourage discussion, as follows:
>
> 1) Is an active attachment a closure?
>
> 2) Is a reference to an active attachment a closure?


Since both closures and (most) attachments are constants, a reference to
an attachment and the attachment itself are equivalent.


By my personal definition, a closure is a set of name->value bindings
and a piece of code that will be executed with those bindings in effect.
By this definition, an attachment is a closure with a trivial (empty)
set of bindings.


> 3) When productivity software services or email presentation
> services receive a reference to an active attachment is that
> a closure?


By my definition, any piece of mobile code is a closure.
Actually, the definition of closure properly includes all data, since
all data can be seen as a function that will always return that data.
However, to classify something as "being a closure", it should at least
potentially contain arbitrary code.
(I assume that an "active" attachment is an attachment that contains
JavaScript or some other code that may execute Turing-equivalent code,
irrespective of how much of the external environment it is allowed to
alter.)


> Considering the possible application of the term closure to
> an active attachment:
>
> 4) In general, how do we protect that which is outside of a
> closure from what is in it?


Functional languages protect the outside simply by disallowing all
change - the only way to arrive at new values is to construct them. This
is the simplest way, and IMHO the only way where safety and security
(either of outside code in programming, or of outside data in a
messaging context) can be handled in a reasonable manner.


In a messaging context, disallowing all modifications isn't feasible
(there are desirable and undesirable modifications after all).
JavaScript tries to do some sort of "sandboxing", but I know of no
JavaScript interpreter that's not a constant source of security issues
(my experience here is limited though).
Most programming languages don't even address that problem, closures may
do whatever they want. (There are capability-based systems, both
languages and operating systems, that might provide a useful solution
here. I don't know enough about them to comment.)


> 5) Assuming that a closure is capable of leaving behind a remnant.
> In general, how do we protect that which is outside of the closure
> remnant from the closure remnant?


If the remnant is itself a closure, then the problem is the same as before.
(What's you definition of a "closure remnant"?)


> 6) Is it useful to suggest the term malignant closure?
>
> 7) Is the term malignant closure remnant useful?


In an Email (or messaging) context: yes.
In a programming context: yes again. However, since most software
systems are closed (it's impossible for anonymous third parties to
insert code), problems with malignant closures don't become visible;
instead, they manifest as fragility when programs become large.


> 8) Can we extend the vocabulary of the science of garbage collection
> to designate the notion of closure remnant capture and cleanup?


I don't currently see any reason why closure remnants (whatever they
are) should be handled specially during garbage collection. A closure
becomes obsolete as soon as nobody references it anymore, at which point
GC can kick in.
Things get more interesting in distributed garbage collection. AFAIK a
distributed, fault-tolerant, efficient garbage collector is still an
open research question. Handling code differently than data might be a
good heuristic (then again, it might not - I don't really know).


HTH
Jo

Return to the comp.compilers page.
Search the comp.compilers archives again.