guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: peval update


From: Andy Wingo
Subject: Re: peval update
Date: Wed, 04 Jan 2012 15:50:03 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux)

Hi Ludo :)

On Sat 01 Oct 2011 16:45, address@hidden (Ludovic Courtès) writes:

> (As you can see I’m lagging behind and notice guile-commits before
> guile-devel.  :-))

As you can see I'm lagging behind 2012 and am answering mails from 2011
:)

> It also removes the main reason for not having peval inline module-local
> top-level bindings (the previous approach was way too aggressive.)  Have
> you thought about it?

Yes.  Of course we would need some guarantees about binding mutability:
if N toplevel definitions are compiled together in one module, and M of
those bindings are never set!, then those M definitions should be fair
game for inlining.

We would also need some more visibility regarding modules.  For example,
in the following code:

  (define x 10)
  (foo!)
  (define y x)

We don't know that the toplevel-ref of `x' in the definition of `y'
refers to the `x' defined above, because `(foo!)' could have changed the
current module.  The syntax expander knows these things, but not all of
that knowledge is residualized in the tree-il.

Perhaps we need to add fields to toplevel-{ref,define,set!} for the
module that was current at expansion time.  Perhaps this could lead to
coalescing toplevel-{ref,define,set!} and module-{ref,set!} into one
triumvarate of toplevel binding tree-il forms.

Andy
-- 
http://wingolog.org/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]