unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: David Pirotte <david@altosw.be>
Cc: 20093@debbugs.gnu.org
Subject: bug#20093: master: setting merge-generics duplicate-binding-handler @ expand time raises an error
Date: Thu, 07 Jul 2016 11:54:51 +0200	[thread overview]
Message-ID: <87d1mp7oyc.fsf@pobox.com> (raw)
In-Reply-To: <20160703191007.0e4d2471@capac> (David Pirotte's message of "Sun,  3 Jul 2016 19:10:07 -0300")

On Mon 04 Jul 2016 00:10, David Pirotte <david@altosw.be> writes:

>> But, you say, I only specified the duplicates handler after loading
>> goops!  Well indeed, but if a module didn't specify #:duplicates, its
>> duplicates handling was implicitly dynamically scoped to whatever the
>> current default-duplicates-handlers were.  That seems bogus to me: the
>> module declares its imports and exports and a lack of a declaration of
>> #:duplicates indicates that the module is implicitly specifying the
>> duplicate handlers that are described in the manual.
>
> I disagree with the way you [now' re-] interpret things: if a module has no
> #:duplicates declaration, it is implicitly specifying the duplicate handlers 
> returned by (default-duplicate-binding-handler), _not_ the one from the
> manual.

To clarify.  I believe that the default should be what is in the manual,
and have fixed Guile 2.2 in that regard.  You think it should be the
value of the dynamic parameter.  There are two points at which the
parameter could be captured: when the module is defined, or lazily, when
the first duplicate binding pair is detected.  The latter leads to bugs
of many kinds, like this bug.  So, I assume you are proposing to capture
the value of the dynamic parameter when the module is defined.  This has
two bugs however.

 * Modules are defined two times in general: once when compiling and
   once when loading.  It is too difficult to get the parameter to work
   when compiling; you have to do invoke
   (default-duplicate-binding-handler) at the top of each file you
   compile, at which point you might as well just specify #:duplicates.

 * Global dynamic parameters that affect the substance of a module and
   the shape of its exports are not modular and cannot be set in a
   modular way.  If your module depends on a particular duplicates
   handler, you need to specify that explicitly -- otherwise a user of
   your module might want something different in general, and then your
   code would break.

>> In master I have changed the `default-duplicate-binding-handler' to
>> simply access the handlers for the current module, as that seems to be
>> the correct thing.  Let me know how it goes!  Closing as done but let's
>> follow up :)
>
> This breaks all my code, with no other option but maintaining my own
> boot-9 version: I really wish I can avoid that, could you reconsider? [no, I don't
> want to have to use #:duplicates, since I _always_ [like always always always] want
> my modules to grab my global setting and default].

I feel your pain but I think that the proper solution is to just go
through your modules and add the #:duplicates argument.  It is forward
and backward compatible.

I also feel the need to say that while you are welcome to fork Guile in
any way that you like, I will not look at any bugs from a forked Guile.

Regards,

Andy





  reply	other threads:[~2016-07-07  9:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-12  3:17 bug#20093: master: setting merge-generics duplicate-binding-handler @ expand time raises an error David Pirotte
2016-06-23 16:00 ` Andy Wingo
2016-07-03  4:57   ` David Pirotte
2016-07-03 22:10   ` David Pirotte
2016-07-07  9:54     ` Andy Wingo [this message]
2016-07-03 20:55 ` bug#20093: Fw: " David Pirotte
2016-07-07 10:22   ` Andy Wingo
2016-07-25  2:38     ` David Pirotte
2016-07-25  2:44       ` David Pirotte

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d1mp7oyc.fsf@pobox.com \
    --to=wingo@pobox.com \
    --cc=20093@debbugs.gnu.org \
    --cc=david@altosw.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).