Hi all,
In getting to know the LLVM infrastructure, I'm having a hard time finding
implementation details for closures and continuations.
For closures, I've read comments such as "using a struct" as an
environment to hold references to free variables, linked lists to dictionaries
for various scope levels, and even things like "it's just like virtual
methods". I have a couple of questions regarding codegen, especially in the
context of a Lispy/Haskell-like language with automatic reference counting of
immutable objects allocated on the heap.
What needs to be added to Functions during code generation? Is it a really just
a struct only holding offsets to free variables? Or do symbols need to be looked
up a kind of scope chain at runtime?
Does adding a JIT complicate codegen of closures in terms of symbol lookup in
the bundled environment?
Any recommendations for treating functions with no free variables vs closures?
Does implementing continuations greatly affect implementations of closures? I
assume the stack would need to be heap-allocated explicitly, which might affect
how pointers would be saved in a bundled environment.
Perhaps, as a simple example, what might this look like in terms of IR?
(define addN
(fn [n]
(fn [m]
(+ n m))))
Regards,
David
On Sat, Jun 29, 2013 at 7:51 PM, David Farler <accumulator at icloud.com>wrote:> Hi all, > > In getting to know the LLVM infrastructure, I'm having a hard time finding > implementation details for closures and continuations. > > For closures, I've read comments such as "using a struct" as an > environment to hold references to free variables, linked lists to > dictionaries for various scope levels, and even things like "it's just like > virtual methods". I have a couple of questions regarding codegen, > especially in the context of a Lispy/Haskell-like language with automatic > reference counting of immutable objects allocated on the heap. > > What needs to be added to Functions during code generation? Is it a really > just a struct only holding offsets to free variables? Or do symbols need to > be looked up a kind of scope chain at runtime? > > Does adding a JIT complicate codegen of closures in terms of symbol lookup > in the bundled environment? > > Any recommendations for treating functions with no free variables vs > closures? > > Does implementing continuations greatly affect implementations of > closures? I assume the stack would need to be heap-allocated explicitly, > which might affect how pointers would be saved in a bundled environment. >Please read http://llvm.org/docs/tutorial/index.html . I'm having trouble coming up with answers to most of your questions. If you need completely general continuations, yes, you'll want to explicitly allocate your stack. -Eli -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130629/1581eeab/attachment.html>
> On Jun 29, 2013, at 9:53 PM, Eli Friedman <eli.friedman at gmail.com> wrote: > >> On Sat, Jun 29, 2013 at 7:51 PM, David Farler <accumulator at icloud.com> wrote: >> Hi all, >> >> In getting to know the LLVM infrastructure, I'm having a hard time finding implementation details for closures and continuations. >> >> For closures, I've read comments such as "using a struct" as an environment to hold references to free variables, linked lists to dictionaries for various scope levels, and even things like "it's just like virtual methods". I have a couple of questions regarding codegen, especially in the context of a Lispy/Haskell-like language with automatic reference counting of immutable objects allocated on the heap. >> >> What needs to be added to Functions during code generation? Is it a really just a struct only holding offsets to free variables? Or do symbols need to be looked up a kind of scope chain at runtime? >> >> Does adding a JIT complicate codegen of closures in terms of symbol lookup in the bundled environment? >> >> Any recommendations for treating functions with no free variables vs closures? >> >> Does implementing continuations greatly affect implementations of closures? I assume the stack would need to be heap-allocated explicitly, which might affect how pointers would be saved in a bundled environment. > > Please read http://llvm.org/docs/tutorial/index.html . I'm having trouble coming up with answers to most of your questions. > > If you need completely general continuations, yes, you'll want to explicitly allocate your stack. > > -EliThanks, this is the tutorial I've been reading and it's a great resource. I think I just need to start looking at some languages that already implement this. I can see now that free variable addresses are known at compile time and can be used in the future provided they are allocated on or moved to the heap. Still wondering about how to pack the structs and how eval/JIT affects this; I'll keep looking. Thanks! David -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130629/e1df5ea9/attachment.html>