Re: [Scheme-reports] Are generated toplevel definitions secret?

[Andy Wingo <wingo@x>]

Hello Aaron,

Thanks for your reply.  Re-adding the list.

On Fri 20 May 2011 19:29, "Aaron W. Hsu" <arcfide@x> writes:

> On Fri, 20 May 2011 04:29:49 -0400, Andy Wingo <wingo@x> wrote:
>
>>   But then if you recompile a.scm, to a.so, you would have to generate
>> the
>>   same gensyms, or b.so will fail to link when it is loaded later -- so
>>   the gensyms aren't quite random...
>
> Here is the crux of the matter. You want to be able to recompiled one
> library and have it be ABI compatible with previous compilation
> instances  of the same library.

Yes.

> This is different than separate compilation. Separate compilation does
> not mean that any one library can be recompiled without affecting
> others, it just means that you can recompile them separately and at
> different times.

Hmm; ok.  Let's call what I am interested in "compatible recompilation":
see below.

> More to the point, how does Guile determine that the ABI is not
> compatible?

I think this is an interesting question but not perhaps germane to my
argument.  My example has file A.so, and B.so which has been compiled
against A.so.  If I have not changed A.scm or any of its includes,
loads, or imports (in short: its depedencies), and none of its
dependencies uses procedural macros, then under any definition this
should be form an ABI-compatible A.so -- at least, it's what I want.

>> Back to the future: there is no issue in recognizing introduced
>> bindings.  That's fine.  However when reifying these bindings to some
>> compiled object, you have to give them an identifier (in some general
>> sense), and that identifier needs to be stable to allow separate
>> recompilation.  How does one provide a stable identifier for something
>> that's supposed to be unique?
>
> Your assumption is that they need to be stable in order to allow
> separate compilation. They need to be stable only if you require that
> you can  recompile one library without ever needing to recompile the
> other. In Chez  Scheme, which does not have the top-level hygiene
> problem, this is not the  case. You can recompile files separately and
> independently, but compiling  library B which depends on library A
> requires that you first have a single  compiled instance of A on which B
> can depend. This means that if you  recompile A, and then try to use
> that newly compiled A with an older  instance of B which was linked
> against a different version of A, you will  get an error stating that B
> expects a different compilation instance of A.
>
> I happen to think that this is a reasonable tradeoff; you may disagree.

Thank you for this description, it was useful.

I think that Guile's needs are different here.  I need to be able to
allow distributors to release a new Guile binary package without causing
recompilation of user libraries.  Of course this requires some care in
maintenance, so as to only make compatible changes, but the trivial case
of recompilation of an unchanged source package should produce a
compatible binary package.

Causing B.SO to *rely* on an identifier that is generated anew every
time A.scm is compiled introduces a coupling between compiled files that
is invisible to the user, and is not acceptable in Guile's use case.

Now, I could get around this issue by somehow explicitly specifying the
names to introduce, or the seed for the gensym algorithm; but at that
point you're hacking around a misfeature.

Dunno, in short.

Andy
-- 
http://wingolog.org/

_______________________________________________
Scheme-reports mailing list
Scheme-reports@x
http://lists.scheme-reports.org/cgi-bin/mailman/listinfo/scheme-reports