[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#19459: #:export does not honor the merge-generics contract

From: David Pirotte
Subject: bug#19459: #:export does not honor the merge-generics contract
Date: Sun, 26 Jun 2016 23:54:55 -0300

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 
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 
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 
        to the user settings wrt to this, it has to merge.

Then you tell me 'yep David, internally the system faced an import situation, 
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,

Attachment: pgpB0EGTgGzuV.pgp
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]