Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!decwrl!labrea!polya!max
From: max@polya.Stanford.EDU (Max Hailperin)
Newsgroups: comp.arch
Subject: Re: Execute instructions, Bit Blit, Self-modifying code, Programming in Assembler
Summary: Why run-time-generated code is a good closure representation
Message-ID: <3435@polya.Stanford.EDU>
Date: 28 Jul 88 03:03:24 GMT
References: <787@amethyst.ma.arizona.edu> <4235@saturn.ucsc.edu> <681@auvax.UUCP> <26195@oliveb.olivetti.com>
Reply-To: max@polya.Stanford.EDU (Max Hailperin)
Distribution: na
Organization: Stanford University
Lines: 23


David Chase's posting about run-time-generated code for
partial-application for closures may have left some of y'all wondering
why this is a good (= efficient) way to represent closures.  He writes
that it allows fast passing and calling of procedural parameters, but
on the surface it appears that the traditional method of passing both
a code pointer and an environment pointer would be faster.  Thus some
explanation is called for.

The rational for passing a closure as the address of a
(run-time-generated) piece of code is that the compiler can figure out
that most closures don't really need to be closures.  This is because
most procedures use only their own local variables and truly global
variables, but nothing from intermediate levels.  Thus it is desirable
to have procedures that take procedural parameters work whether passed
a closure or a non-closed procedure.  The method Chase describes
allows for this, and thus improves performance in the common case.

So the bottom line is this is a good way to represent closures because
it allows a good representation of closures that don't need to close
over anything.  This is all implicit in Chase's desire to have the
calling sequence for closures and normal procedures be the same, but I
thought I'd make it explicit to help make clear why architectural
support for run-time generated code would be nice.