guile-devel
[Top][All Lists]
Advanced

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

Re: thoughts on top-level and cross-module inlining


From: Ludovic Courtès
Subject: Re: thoughts on top-level and cross-module inlining
Date: Thu, 14 Apr 2016 15:49:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Hello!  :-)

Andy Wingo <address@hidden> skribis:

> So, we have two questions, then: firstly, what semantic change can we
> make to the language to permit top-level and cross-module inlining?
> Secondly, how do we implement it?

As I view it, the first step would be to allow intra-module inlining
(inlining of unassigned private top-level bindings within the module.)
It seems to me that this would have little impact on semantics; there is
still the occasional, but not so rare, uses of @@ to bypass module
boundaries that we want to allow, though.

IMO a guiding principle should be that top-level inlining can always be
disabled.  This “backdoor” as you write is important for many current
uses (Geiser, monkey-patching of third-party modules, etc.)

> On the semantic side, I propose to add a field in modules indicating
> whether the module permits its top-level references to be inlined.

That sounds like a good idea for cross-module inlining!

I wonder if a separate way to annotate candidates to intra-module (but
not necessarily cross-module) inlining would be needed.  Maybe something
like the ‘declare’ forms found in CL and in some Schemes?

> Let us assume that assigned bindings are not available for inlining, but
> that declarative bindings can be inlined.  Then, a program with inlining
> will be the same as a program without inlining if declarative bindings
> are never assigned from outside their compilation unit.  That is what is
> meant by "used conventionally", and I think it reflects standard Guile
> usage, especially where modules are mostly compiled entirely within one
> compilation unit.
>
> (We should make an enhancement to the compiler to emit a warning when a
> declarative binding is used unconventionally.  Perhaps we should emit a
> warning whenever an imported binding is "set!", perhaps with a view
> towards enforcing conventional usage; but I don't know, we always want
> to have a back-door I think to allow Guile hackers to heal broken
> programs while they are running.)

I think we want to preserve the ability to ‘set!’ third-party bindings,
indeed, in those cases where that is considered more important than
inlining.  But I agree that being able to flag such unconventional usage
with compiler warnings would be helpful.

My 2¢,
Ludo’.



reply via email to

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