Hi Aaron,

Thanks for replying, it reminded me that I had a brain wave.  Re-adding
the list.

To recap:

   (define-syntax define-const
     (syntax-rules ()
       ((_ 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
peruse.

Cheers,

Andy

On Tue 24 May 2011 20:44, "Aaron W. Hsu" <arcfide@sacrideo.us> writes:

> On Sat, 21 May 2011 06:20:28 -0400, Andy Wingo <wingo@pobox.com> 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
> code.
> 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.

--
http://wingolog.org/

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