bug#21944: Error on ordering of define-record-type and define-public in a module is unhelpful - possible improvement?

[Andy Wingo]

On Tue 17 Nov 2015 09:27, Koz Ross <address@hidden> writes:

> I have the following file, called foo.scm:
>
> (define-module (koz foo)
>  #:use-module (srfi srfi-9))
>
> (define-public (make-empty-bar)
>   (make-bar #f))
>
> (define-record-type <bar>
>   (make-bar open)
>   bar?
>   (open bar-open set-bar-open!))

> Would it be possible for the error message in this case to be a bit
> more helpful? Even better, would it be possible to not make this an
> issue when compiling?

It would be possible to make the scope of make-bar be the whole file.
In theory it should work I guess, given this news entry from 2.0.1:

  ** `begin' expands macros in its body before other expressions

  This enables support for programs like the following:

      (begin
        (define even?
          (lambda (x)
            (or (= x 0) (odd? (- x 1)))))
        (define-syntax odd?
          (syntax-rules ()
            ((odd? x) (not (even? x)))))
        (even? 10))

And indeed if I try something at the REPL that uses `begin' I can't
reproduce this sort of error.  Hmmmm.  Maybe this rings a bell with
Mark.

In the mean-time I added a warning:

  address@hidden:~/src/guile$ meta/guile --fresh-auto-compile /tmp/foo.scm
  ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
  ;;;       or pass the --no-auto-compile argument to disable.
  ;;; compiling /tmp/foo.scm
  ;;; /tmp/foo.scm:4:2: warning: macro `make-bar' used before definition
  ;;; compiled 
/home/wingo/src/guile/cache/guile/ccache/2.2-LE-8-3.9/tmp/foo.scm.go
  Backtrace:
             5 (apply-smob/1 #<catch-closure fcac00>)
  In ice-9/boot-9.scm:
      704:2  4 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
  In ice-9/eval.scm:
      608:8  3 (_ #(#(#<directory (guile-user) fd1f30>)))
  In ice-9/boot-9.scm:
     2325:4  2 (save-module-excursion _)
    3829:12  1 (_)
  In unknown file:
             0 (_ #f)

  ERROR: ERROR: Wrong type to apply: #<syntax-transformer make-bar>

OK the error is terrible, but at least the warning tells you why the
later error is terrible.

I haven't been able to backport it to 2.0 yet though.  But maybe the
warning is useless if we can fix the issue.

Andy