[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] Are generated toplevel definitions secret?
Thanks for replying, it reminded me that I had a brain wave. Re-adding
((_ name val)
(define t val)
(define-syntax name (syntax-rules () ((_) t))))))
Guile currently does not make the generated toplevel definition "t" have
a fresh name. It would be nice if it could but it can't be a really
random name -- it needs to be predicatable.
Well why not have the name of "t" be "t" plus some string which depends
only on the incoming form -- like its hash value. (Or the outgoing
form; the considerations are different but similar.)
That way you do preserve the "compatible recompilation" aspect, trading
off true secrecy, but hey. Oh well.
I leave the rest of your fine and interesting mail for list folk to
On Tue 24 May 2011 20:44, "Aaron W. Hsu" <arcfide@x> writes:
> On Sat, 21 May 2011 06:20:28 -0400, Andy Wingo <wingo@x> wrote:
>> 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.
> Okay, that's an interesting and worthwhile goal. I wonder if it wouldn't
> still be possible to do this while not providing the same guarantees to
> users who produce code that would break this compatibility.
> For me, the major problem in thinking that one can maintain ABI
> compatibility in the presence of procedural macros is that, in general,
> you can't. Even code that has absolutely no source changes can
> potentially change from expansion to expansion. Moreover, this does not
> even take into account how the compiler might interact with compiled
> Taking your example, where you want to be able to release an ABI
> compatible binary package for Guile without requiring user's to
> recompile their own user libraries, I'll shift this over to Chez, since
> I know more about how Chez works. This simply wouldn't be possible to
> do in something like Chez Scheme, even if it did allow leaks at the top
> level. When you compile, for example, and R6RS top-level program, Chez
> takes advantage of having a total picture of the code to be compiled
> and can inline it's own code from the core (chezscheme) library into
> the user's code at optimization levels greater than, say, zero or
> one. If another release of Chez Scheme comes out, ABI compatibility now
> means much more than just making sure that all the names match. It also
> means that all the source code that may have been inlined, must now
> also remain unchanged or observationally equivalent at the very
> least. These sorts of problems crop up all over the place, and it is
> difficult to actually achieve ABI compatibility in the presence of
> these problems, so Chez does not even try.
> I would be interested in knowing what tradeoffs Guile makes in order to
> guarantee the ability to have ABI compatibility between compiles, given
> that in the general case this cannot be guaranteed even if the source
> code never changes.
> Aaron W. Hsu
> Programming is just another word for the lost art of thinking.
Scheme-reports mailing list