Tree-IL Questions

Tree-IL Questions

[Noah Lavine]

Hello again,

I've been working on the compiler issue and I've had to start looking
at processing Tree-IL. As a result, I realized that the Tree-IL
documentation is a bit out-of-date. I would like to fix it, but there
are some things I don't understand.

- It looks like every Tree-IL type has a src slot, correct? But if so,
why doesn't the record-case at module/language/tree-il.scm line 271
(unparse-tree-il) match those src slots? Especially since the big
match statement in peval (line 682) does match them (unless it matches
no entries in the record)?

- On a related note, why do most of the Tree-IL record type not appear
in the define-type statement in tree-il.scm line 133, and is that
connected with the borrow-core-vtables macro that I don't understand
at all? :-)

- Is it guaranteed that the exp slot in a <const> record will always
be a Scheme value, or can it be a Tree-IL expression?

Thanks,
Noah

Re: Tree-IL Questions

[Andy Wingo]

On Thu 17 Nov 2011 00:46, Noah Lavine <noah.b.lavine@gmail.com> writes:

> - It looks like every Tree-IL type has a src slot, correct?

Yes

> why doesn't the record-case at module/language/tree-il.scm line 271
> (unparse-tree-il) match those src slots?

Record-case parses slots by name, not by position.

> Especially since the big
> match statement in peval (line 682) does match them (unless it matches
> no entries in the record)?

Match destructures by position, not by name.

> - On a related note, why do most of the Tree-IL record type not appear
> in the define-type statement in tree-il.scm line 133, and is that
> connected with the borrow-core-vtables macro that I don't understand
> at all? :-)

Yes.

> - Is it guaranteed that the exp slot in a <const> record will always
> be a Scheme value, or can it be a Tree-IL expression?

It will be a value that can be written using `write' and read using
`read'.

Where are the docs not up-to-date?  In stable-2.0 they should be current.

Andy
-- 
http://wingolog.org/

Re: Tree-IL Questions

[Noah Lavine]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

Hello,

> Record-case parses slots by name, not by position.
....
> Match destructures by position, not by name.

Oh, interesting.

>> - On a related note, why do most of the Tree-IL record type not appear
>> in the define-type statement in tree-il.scm line 133, and is that
>> connected with the borrow-core-vtables macro that I don't understand
>> at all? :-)
>
> Yes.

Then I have a new goal: understand that. :-)

> Where are the docs not up-to-date?  In stable-2.0 they should be current.

That may be the issue, because I am using the latest git head. There
were only very small issues, but I thought I should fix them anyway.
Specifically,
 - some records weren't listed with a 'src' slot
 - the first two slots for <letrec> were out of order
 - it documented <sequence> instead of the newer <seq>, which has a
slightly different structure

The attached patch fixes all of these, I think.

Have a good day,
Noah

[-- Attachment #2: 0001-Update-Tree-IL-Documentation.patch --]
[-- Type: application/octet-stream, Size: 5091 bytes --]

From 1c8ca1590bfbc544387f614a26a689ba37e48073 Mon Sep 17 00:00:00 2001
From: Noah Lavine <nlavine@haverford.edu>
Date: Thu, 17 Nov 2011 09:39:19 -0800
Subject: [PATCH] Update Tree-IL Documentation

* doc/ref/compiler.texi: add 'src' objects to all Tree-IL records
* doc/ref/compiler.texi: switch from '<sequence>' to '<seq>'
* doc/ref/compiler.texi: change order of <letrec> members
---
 doc/ref/compiler.texi |   23 +++++++++++++----------
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/doc/ref/compiler.texi b/doc/ref/compiler.texi
index 3d6dbf3..ffd8aea 100644
--- a/doc/ref/compiler.texi
+++ b/doc/ref/compiler.texi
@@ -397,9 +397,12 @@ analyze than @code{<call>}.
 As part of the compilation process, instances of @code{(call (primitive
 @var{name}) . @var{args})} are transformed into primcalls.
 @end deftp
-@deftp {Scheme Variable} <sequence> src exps
+@deftp {Scheme Variable} <seq> src head rest
 @deftpx {External Representation} (begin . @var{exps})
-Like Scheme's @code{begin}.
+Has the same semantics as Scheme's @code{begin}, but stores expressions
+in the same way as a Scheme list. @var{head} will be a Tree-IL
+expression, and @var{rest} will either be another @code{<seq>} record or
+an expression, which will be the last expression in the sequence.
 @end deftp
 @deftp {Scheme Variable} <lambda> src meta body
 @deftpx {External Representation} (lambda @var{meta} @var{body})
@@ -409,7 +412,7 @@ procedure. @var{body} is a single Tree-IL expression of type
 an alternate clause, this makes Tree-IL's @code{<lambda>} have the
 expressiveness of Scheme's @code{case-lambda}.
 @end deftp
-@deftp {Scheme Variable} <lambda-case> req opt rest kw inits gensyms body alternate
+@deftp {Scheme Variable} <lambda-case> src req opt rest kw inits gensyms body alternate
 @deftpx {External Representation} @
   (lambda-case ((@var{req} @var{opt} @var{rest} @var{kw} @var{inits} @var{gensyms})@
                 @var{body})@
@@ -449,13 +452,13 @@ original binding names, @var{gensyms} are gensyms corresponding to the
 @var{names}, and @var{vals} are Tree-IL expressions for the values.
 @var{exp} is a single Tree-IL expression.
 @end deftp
-@deftp {Scheme Variable} <letrec> in-order? src names gensyms vals exp
+@deftp {Scheme Variable} <letrec> src in-order? names gensyms vals exp
 @deftpx {External Representation} (letrec @var{names} @var{gensyms} @var{vals} @var{exp})
 @deftpx {External Representation} (letrec* @var{names} @var{gensyms} @var{vals} @var{exp})
 A version of @code{<let>} that creates recursive bindings, like
 Scheme's @code{letrec}, or @code{letrec*} if @var{in-order?} is true.
 @end deftp
-@deftp {Scheme Variable} <dynlet> fluids vals body
+@deftp {Scheme Variable} <dynlet> src fluids vals body
 @deftpx {External Representation} (dynlet @var{fluids} @var{vals} @var{body})
 Dynamic binding; the equivalent of Scheme's @code{with-fluids}.
 @var{fluids} should be a list of Tree-IL expressions that will
@@ -463,17 +466,17 @@ evaluate to fluids, and @var{vals} a corresponding list of expressions
 to bind to the fluids during the dynamic extent of the evaluation of
 @var{body}.
 @end deftp
-@deftp {Scheme Variable} <dynref> fluid
+@deftp {Scheme Variable} <dynref> src fluid
 @deftpx {External Representation} (dynref @var{fluid})
 A dynamic variable reference. @var{fluid} should be a Tree-IL
 expression evaluating to a fluid.
 @end deftp
-@deftp {Scheme Variable} <dynset> fluid exp
+@deftp {Scheme Variable} <dynset> src fluid exp
 @deftpx {External Representation} (dynset @var{fluid} @var{exp})
 A dynamic variable set. @var{fluid}, a Tree-IL expression evaluating
 to a fluid, will be set to the result of evaluating @var{exp}.
 @end deftp
-@deftp {Scheme Variable} <dynwind> winder pre body post unwinder
+@deftp {Scheme Variable} <dynwind> src winder pre body post unwinder
 @deftpx {External Representation} (dynwind @var{winder} @var{pre} @var{body} @var{post} @var{unwinder})
 A @code{dynamic-wind}. @var{winder} and @var{unwinder} should both
 evaluate to thunks.  Ensure that the winder and the unwinder are called
@@ -483,7 +486,7 @@ bodies of @var{winder} and @var{unwinder} for the case of normal control
 flow, compiling the expressions in @var{pre} and @var{post},
 respectively.
 @end deftp
-@deftp {Scheme Variable} <prompt> tag body handler
+@deftp {Scheme Variable} <prompt> src tag body handler
 @deftpx {External Representation} (prompt @var{tag} @var{body} @var{handler})
 A dynamic prompt. Instates a prompt named @var{tag}, an expression,
 during the dynamic extent of the execution of @var{body}, also an
@@ -494,7 +497,7 @@ or keyword arguments, and no alternate. The first argument to the
 of the values passed to the abort. @xref{Prompts}, for more
 information.
 @end deftp
-@deftp {Scheme Variable} <abort> tag args tail
+@deftp {Scheme Variable} <abort> src tag args tail
 @deftpx {External Representation} (abort @var{tag} @var{args} @var{tail})
 An abort to the nearest prompt with the name @var{tag}, an expression.
 @var{args} should be a list of expressions to pass to the prompt's
-- 
1.7.6

Re: Tree-IL Questions

[Andy Wingo]

On Thu 17 Nov 2011 18:44, Noah Lavine <noah.b.lavine@gmail.com> writes:

>>> - On a related note, why do most of the Tree-IL record type not appear
>>> in the define-type statement in tree-il.scm line 133, and is that
>>> connected with the borrow-core-vtables macro that I don't understand
>>> at all? :-)
>>
>> Yes.
>
> Then I have a new goal: understand that. :-)

The deal is that macroexpansion produces tree-il.  The usual
macroexpander is provided by psyntax.  But before psyntax is loaded,
when the first bits of Scheme are seen, there is a boot expander written
in C that produces tree-il, with support for a subset of Scheme.  This
is in expand.[ch].

Obviously it can't load scheme in order to get the vtable for <seq>, for
example, so it defines some core subset of tree-il in C.

Then when tree-il loads, it grabs that core subset and re-exports it.

Does that help?

Thre is similar but more limited code in psyntax.scm, right at the top.

Regards,

Andy
-- 
http://wingolog.org/

Re: Tree-IL Questions

[Noah Lavine]

>> Then I have a new goal: understand that. :-)
>
> The deal is that macroexpansion produces tree-il.  The usual
> macroexpander is provided by psyntax.  But before psyntax is loaded,
> when the first bits of Scheme are seen, there is a boot expander written
> in C that produces tree-il, with support for a subset of Scheme.  This
> is in expand.[ch].
>
> Obviously it can't load scheme in order to get the vtable for <seq>, for
> example, so it defines some core subset of tree-il in C.
>
> Then when tree-il loads, it grabs that core subset and re-exports it.
>
> Does that help?

Yes, and thank you very much for the explanation!