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: 20093@debbugs.gnu.org
Subject: bug#20093: Fw: bug#20093: master: setting merge-generics duplicate-binding-handler @ expand time raises an error
Date: Sun, 24 Jul 2016 23:38:48 -0300	[thread overview]
Message-ID: <20160724233848.04c33f5e@capac> (raw)
In-Reply-To: <87oa69694l.fsf@pobox.com>

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

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

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

  reply	other threads:[~2016-07-25  2:38 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
2016-07-03 20:55 ` bug#20093: Fw: " David Pirotte
2016-07-07 10:22   ` Andy Wingo
2016-07-25  2:38     ` David Pirotte [this message]
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=20160724233848.04c33f5e@capac \
    --to=david@altosw.be \
    --cc=20093@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).