Hello! :-) Andy Wingo <wi...@pobox.com> 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’.
