unofficial mirror of bug-guile@gnu.org 
 help / color / mirror / Atom feed
From: David Pirotte <david@altosw.be>
To: Andy Wingo <wingo@pobox.com>
Cc: 19459@debbugs.gnu.org
Subject: bug#19459: #:export does not honor the merge-generics contract
Date: Sun, 26 Jun 2016 23:54:55 -0300	[thread overview]
Message-ID: <20160626235455.7726d721@capac> (raw)
In-Reply-To: <87twgjji1k.fsf@pobox.com>

[-- Attachment #1: Type: text/plain, Size: 2193 bytes --]

Hello Andy,

> >> However... I believe merge-generics is intended to merge duplicate
> >> imported bindings.  It does not provide a copy-on-write version of an
> >> imported generic, if that generic was not duplicated in the imports.
> >> There is no facility in GOOPS to do that, AFAIU.  

> > It is a module bug, not a GOOPS bug, see my 'personal/local' fix: the problem is
> > that once the user uses #:export, guile's module system create a new binding,
> > and it should not ... [hence this confusion as well: as it is: the module must
> > merge its definition with the imported ones, even if it imported only 1
> > generic ... because of a module bug...]  

> I... I just think you're wrong here, sorry :/ That's just not how the
> system works.  If you #:export an identifier in a module, you create a
> fresh local binding, and that binding doesn't implicitly extend an
> imported binding, merge-generics or no.  Merge-generics only operates on
> the import interface of a module.

I don't think so, and I feel sorry too ;/. We disagree, which is different, and
nobody is 'right' or 'wrong' here. [and I know 'how the system works, I described
it that in the original email, I'd like to change that, hence this thread ...]

IMO, this should never fail:

	,use (b)
	make <b>

Your last sentence states that merge-generics only operates on the import interface
of a module: that is the feature I'm referring to to claim the above:

  [ using #:export ]

	t0	the system creates new 'empty' binding
		at some point 'it' knows it is a gf
	ti	it imports (a)

	now the (b) module interface is facing a duplicate gf binding, and according
	to the user settings wrt to this, it has to merge.

Then you tell me 'yep David, internally the system faced an import situation, and
ok, let's merge, _but_ #:export must export a fresh new ... I can buy that, but
do we have the technology do implement this senario? 

I believe, still referring to your last sentence, the above sentence as well and
respecting your position, that we should rather create/have global setting
'export-rexport-imported-gf' [or a better name.], WDYT?

Happy Hacking,
David

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

  reply	other threads:[~2016-06-27  2:54 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-28 18:20 bug#19459: #:export does not honor the merge-generics contract David Pirotte
2016-06-22 20:21 ` Andy Wingo
2016-06-23 19:23   ` David Pirotte
2016-06-23 20:06     ` Andy Wingo
2016-06-23 21:11       ` David Pirotte
2016-06-24  5:02         ` Andy Wingo
2016-06-27  2:54           ` David Pirotte [this message]
2016-06-27  7:47             ` Andy Wingo

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=20160626235455.7726d721@capac \
    --to=david@altosw.be \
    --cc=19459@debbugs.gnu.org \
    --cc=wingo@pobox.com \
    /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).