Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.compilers > #1972
| From | rpw3@rpw3.org (Rob Warnock) |
|---|---|
| Newsgroups | comp.compilers |
| Subject | Re: Add nested-function support in a language the based on a stack-machine |
| Date | 2018-03-03 16:00 +0000 |
| Organization | Rob Warnock, Consulting Systems Architect |
| Message-ID | <18-03-013@comp.compilers> (permalink) |
| References | <18-02-009@comp.compilers> <18-02-034@comp.compilers> <18-03-002@comp.compilers> <18-03-006@comp.compilers> |
Kaz Kylheku <217-679-0842@kylheku.com> wrote: +--------------- | George Neuner <gneuner2@comcast.net> wrote: | > It certainly is true that closeure conversion is a better solution | > overall because it flattens all non-local accesses to use a single | > indirection ... but it also significantly complicates the compiler, | > and creates a need for handling wide pointers (or equivalent). Many | > useful languages simply don't need that extra complexity. | | How do flat representations handle the fact that different levels | of the lexical environment have different lifetimes? +--------------- I'm not sure if this counts as "closure conversion" or not, but some Common Lisp implementations [such as CMUCL] use flat environments just fine (even in the interpreter). The trick is to do some minimal pre-analysis of the code, to see which closed-over variables are *not* ever mutated or are *not* used in closures which "escape" the original lexical context. All such variables may be copied into a single "flat" vector at closure creation time. All other closed-over variables are converted into "indirect" variables -- such variables are individually heap-allocated, pointed to by "ref" pointers which are also copied into a the same flat environment vector at closure creation time. Then when the closure is called, all of the up-level variables are either *in* the (flat) environment or available via *one* indirection. Because all of the "ref" pointers for a given environment variable in all the (potential) copies point to the same heap location, closures which mutate a shared variable work just fine. And all the rest are either read-only [and thus all the copies are the same] or else mutated and *not* accessed in any interior closure which escapes. This is normally performs better than linked environments or even displays, unless there are a *large* number of nested closures. In the latter case, when each level of closure is created, it will have to copy all of its free variables from its parent's flat environment into its own. [I apologize if I haven't explained this very well.] This approach is not unique to Lisp. Appel discusses it for ML in his "Compiling With Continuations". -Rob ----- Rob Warnock <rpw3@rpw3.org> 627 26th Avenue <http://rpw3.org/> San Mateo, CA 94403
Back to comp.compilers | Previous | Next — Previous in thread | Next in thread | Find similar
Add nested-function support in a language the based on a stack-machine dror.openu@gmail.com - 2018-02-12 11:25 -0800
Re: Add nested-function support in a language the based on a stack-machine dror.openu@gmail.com - 2018-02-12 14:16 -0800
Re: Add nested-function support in a language the based on a stack-machine Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2018-02-13 12:10 +0100
Re: Add nested-function support in a language the based on a stack-machine Louis Krupp <lkrupp@nospam.pssw.com.invalid> - 2018-02-13 00:42 -0700
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <217-679-0842@kylheku.com> - 2018-02-14 00:59 +0000
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-02-13 22:04 -0500
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <217-679-0842@kylheku.com> - 2018-02-14 18:06 +0000
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-02-15 11:41 -0500
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <217-679-0842@kylheku.com> - 2018-02-17 16:13 +0000
Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-02-17 16:39 +0000
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-03-01 13:48 -0500
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <217-679-0842@kylheku.com> - 2018-03-01 19:26 +0000
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <217-679-0842@kylheku.com> - 2018-03-02 00:38 +0000
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-03-02 02:48 -0500
Re: Add nested-function support in a language the based on a stack-machine rpw3@rpw3.org (Rob Warnock) - 2018-03-03 16:00 +0000
Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-02 09:30 +0000
Re: Add nested-function support in a language the based on a stack-machine anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2018-03-05 15:01 +0000
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-03-05 15:51 -0500
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-03-05 14:39 -0500
Re: Add nested-function support in a language the based on a stack-machine John Levine <johnl@taugh.com> - 2018-03-06 04:31 +0000
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <217-679-0842@kylheku.com> - 2018-03-06 18:17 +0000
Re: Add nested-function support in a language the based on a stack-machine Kaz Kylheku <157-073-9834@kylheku.com> - 2018-03-11 03:19 +0000
Re: Add nested-function support in a language the based on a stack-machine Tomasz Kowaltowski <tk@ic.unicamp.br> - 2018-03-06 12:10 -0300
Re: Add nested-function support in a language the based on a stack-machine bartc <bc@freeuk.com> - 2018-03-06 19:02 +0000
Re: Add nested-function support in a language the based on a stack-machine antispam@math.uni.wroc.pl - 2018-04-29 16:29 +0000
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-03-01 13:49 -0500
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-02-13 22:37 -0500
Re: Add nested-function support in a language the based on a stack-machine George Neuner <gneuner2@comcast.net> - 2018-02-13 23:27 -0500
Re: Add nested-function support in a language the based on a stack-machine Shoefoot <shoefoot@gmail.com> - 2018-02-14 12:27 -0800
csiph-web