bug#20093: Fw: bug#20093: master: setting merge-generics duplicate-binding-handler @ expand time raises an error

[David Pirotte]

Hi Andy,

> > This is a big problem for me, so I partially locally reverted that part of
> > the patch, plus, I patch guild so it does this before anything else:

> >     (eval-when (expand load eval)
> >       (use-modules (oop goops))
> >       (default-duplicate-binding-handler
> >         '(merge-generics replace warn-override-core warn last)))  

> It takes work for me to understand and fix reports and I regret to say
> that patching "guild" is too much for me -- I don't have the time to
> work on bugs in patched Guile versions where the patches are significant
> (like this patch) and yet not headed towards mainline (also like this
> patch).

Let's not get lost in 2 diff things here:

1- 

As a consequence of you looking at this bug report, you decided to change the
module system:

> 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 :)  

I did think very carefully to this and our conversation, and I still think it 
as a
big mistake: if a module does not declare #:duplicates, the 'old' way is the 
right
way, calling (default-duplicate-binding-handler).

Yes, it would then be a user error not to properly globally set this at 'all
incantations', compile, load ... if they rely on a diff set then the defaul:

        the fact that users may miss use it does not justify it's been taken 
away:
        they are quite a lot of ways a user can write bugs, as you know, so 
let's
        get rid of set! then :)

IMO, this is an API, the right one, so it should not be changed.

Note that users of 'these modules' (the ones where you'd locally declare
#:duplicates) still have to set this in their repl and in their scripts, not 
doing
so would also be an user error and this 'new' model does not prevent these 
errors.

I have successfully used it for years now: it saves me to have to do it at 
module
level, and since I correctly set it globally: forcing me (and other users of 
this
API) sounds a bit of a brute forcing a certain programing style: since I know 
what
I'm doing, I don't see local declarations being 'better', but just another way 
to do
it. As a mater of fact, I see the global setting better and safer, because I'll 
never
forget...

Please think about this, thanks!

2-

Now, a separate thing is I can't set this in guild anymore. Ok, I read you, but 
guild
is a script, and IMO, there is no reason I can do it in a script of mine and 
not in
guild, this works fine:

;; compile-me script starts here
#! /bin/sh
# -*- mode: scheme; coding: utf-8 -*-
exec guile --no-auto-compile -e main -s $0 "$@"
!#

(eval-when (expand load eval)
  (use-modules (oop goops))
  (default-duplicate-binding-handler
    '(merge-generics replace warn-override-core warn last)))

(use-modules (system base compile)
             (ice-9 match))
 
(define (main args)
        
  (pk (default-duplicate-binding-handler))
  (add-to-load-path (getcwd))
  (match args
    ((cmd file)
     (compile-file file)
     (display (string-append "I compiled you: "
                             file
                             "\n")))))
;; compile-me script ends here

        [ drop this somewhere, chmod a+x 

;; foo.scm starts here
(define-module (a)
  #:use-module (oop goops)
  #:export (<a>
            !width))

(define-class <a> ()
  (width #:accessor !width
         #:init-keyword #:width
         #:init-value 0))
;; foo.scm ends here

        [ drop this aside compile-me

        ./compile-me foo.scm
        2.1.3.59-516f7
        (merge-generics replace warn-override-core warn last)
        I compiled you: foo.scm

A modified version of the guild script to (eval-when ...), then 'guild compile
foo.scm fails as reported in earlier. Note that it does not matter whether the
module uses goops, import more then one and effectively merge generics, it 
simply
fails, as reported in the first email of this thread.

So if you keep this API we are talking about here, and I really think we 
should, I
can write and use my own script to compile my modules. I'd be curious to 
understand
why guild, modified as described above, did work in 2.0.11, 2.0.12, 2.1.2, but 
fails
with 2.1.3, but I also understand if you are not interested.

Cheers,
David

pgpHrqZ3Uz6OL.pgp
Description: OpenPGP digital signature