error Wrong type to apply: #<syntax-transformer

error Wrong type to apply: #<syntax-transformer

[Damien Mattei]

hi,

i have a main Scheme+ module that exports an overload macro:
(define-module (Scheme+)

  #:use-module (growable-vector)
  #:use-module (ice-9 local-eval)
  #:use-module (ice-9 match)
  #:use-module (srfi srfi-1) ;; any,every
  #:use-module (srfi srfi-69) ;; Basic hash tables
  #:use-module (srfi srfi-31) ;; rec
  #:use-module (srfi srfi-26) ;; cut

  #:export (!*prec set-infix-operators! overload overload-procedure
overload-operator overload-function $nfx$ def $bracket-apply$ <- ← ->
→ <+ ⥆ +> ⥅ declare $> $+>  condx ≠ ** <v v> ⇜ ⇝ repeat % << >> & | )

... code cut ...

(include-from-path "overload.scm")

...

the overloads macros defined in overload.scm like that:

(define-syntax overload

  (syntax-rules ()

    ;; arguments are symbol of function to be overloaded, procedure
that do the overloading, list of predicate to check the arguments
    ((_ funct-symb proc (pred-arg1 ...))
     (overload-procedure funct-symb proc (pred-arg1 ...)))

    ((_ funct-symb proc (pred-arg1 ...) quote-operator)
     (begin
       (overload-operator funct-symb proc (pred-arg1 ...))
       (update-operators))
       )

    ((_ funct-symb proc (pred-arg1 ...) quote-operator quote-n-arity)
     (begin
       (overload-n-arity-operator funct-symb proc (pred-arg1 ...))
       (update-operators)))))

i just show one macro of file


and a program that use the Scheme+ module and overload macro:

(use-modules (Scheme+)

....

(include "guile/logiki+.scm")

finally logiki+.scm use overload:

(initially overload.scm was included from here and it worked well but
now it is in Scheme+ it gives the error in subject)

;; overload tests

(define (add-pair p1 p2) (cons (+ (car p1) (car p2)) (+ (cdr p1) (cdr p2))))

(overload + add-pair (pair? pair?) 'operator)  ;; line 4818

(define (mult-num-vect k v) (map (λ (x) (* k x)) v))
(overload * mult-num-vect (number? list?) 'operator)

{t <+ {3 * '(1 2 3) + '(4 5 6) + '(7 8 9)}}
(display t) (newline)

when run i have this error:

scheme@(guile-user)> (load "start-λογικι-guile+.scm")
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;;       or pass the --no-auto-compile argument to disable.
;;; compiling /usr/local/share/guile/site/3.0/Scheme+.scm
;;; compiling /usr/local/share/guile/site/3.0/growable-vector.scm
;;; compiled /Users/mattei/.cache/guile/ccache/3.0-LE-8-4.6/usr/local/share/guile/site/3.0/growable-vector.scm.go
;;; compiled /Users/mattei/.cache/guile/ccache/3.0-LE-8-4.6/usr/local/share/guile/site/3.0/Scheme+.scm.go
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: #<syntax-transformer overload>

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
scheme@(guile-user) [1]> ,bt
In ice-9/boot-9.scm:
   2836:4  4 (save-module-excursion _)
  4388:12  3 (_)
In /Users/mattei/Library/CloudStorage/Dropbox/git/library-FunctProg/guile/logiki+.scm:
   4418:0  2 (_)
   4418:0  1 (_)
In ice-9/boot-9.scm:
  1685:16  0 (raise-exception _ #:continuable? _)
scheme@(guile-user) [1]>

i found really poor info on this error:

https://stackoverflow.com/questions/50057773/sicp-practise-3-51-wrong-type-to-apply-syntax-transformer-cons-stream

any idea?

regards,
Damien

Re: error Wrong type to apply: #<syntax-transformer

[Damien Mattei]

i just find the stackoverflow solution was good :

it depends of the place of the macro definition , must be before the use of it

i just move the include overload.scm a few line up and it is ok for compilation:

(include-from-path "overload.scm")

(include-from-path "scheme-infix.scm")

overload.scm must be before some definitions of scheme-infix.scm even
if it is not used here, it is strange, i do not understand all but it
compiles now

On Thu, Aug 3, 2023 at 11:09 AM Damien Mattei <damien.mattei@gmail.com> wrote:
>
> hi,
>
> i have a main Scheme+ module that exports an overload macro:
> (define-module (Scheme+)
>
>   #:use-module (growable-vector)
>   #:use-module (ice-9 local-eval)
>   #:use-module (ice-9 match)
>   #:use-module (srfi srfi-1) ;; any,every
>   #:use-module (srfi srfi-69) ;; Basic hash tables
>   #:use-module (srfi srfi-31) ;; rec
>   #:use-module (srfi srfi-26) ;; cut
>
>   #:export (!*prec set-infix-operators! overload overload-procedure
> overload-operator overload-function $nfx$ def $bracket-apply$ <- ← ->
> → <+ ⥆ +> ⥅ declare $> $+>  condx ≠ ** <v v> ⇜ ⇝ repeat % << >> & | )
>
> ... code cut ...
>
> (include-from-path "overload.scm")
>
> ...
>
> the overloads macros defined in overload.scm like that:
>
> (define-syntax overload
>
>   (syntax-rules ()
>
>     ;; arguments are symbol of function to be overloaded, procedure
> that do the overloading, list of predicate to check the arguments
>     ((_ funct-symb proc (pred-arg1 ...))
>      (overload-procedure funct-symb proc (pred-arg1 ...)))
>
>     ((_ funct-symb proc (pred-arg1 ...) quote-operator)
>      (begin
>        (overload-operator funct-symb proc (pred-arg1 ...))
>        (update-operators))
>        )
>
>     ((_ funct-symb proc (pred-arg1 ...) quote-operator quote-n-arity)
>      (begin
>        (overload-n-arity-operator funct-symb proc (pred-arg1 ...))
>        (update-operators)))))
>
> i just show one macro of file
>
>
> and a program that use the Scheme+ module and overload macro:
>
> (use-modules (Scheme+)
>
> ....
>
> (include "guile/logiki+.scm")
>
> finally logiki+.scm use overload:
>
> (initially overload.scm was included from here and it worked well but
> now it is in Scheme+ it gives the error in subject)
>
> ;; overload tests
>
> (define (add-pair p1 p2) (cons (+ (car p1) (car p2)) (+ (cdr p1) (cdr p2))))
>
> (overload + add-pair (pair? pair?) 'operator)  ;; line 4818
>
> (define (mult-num-vect k v) (map (λ (x) (* k x)) v))
> (overload * mult-num-vect (number? list?) 'operator)
>
> {t <+ {3 * '(1 2 3) + '(4 5 6) + '(7 8 9)}}
> (display t) (newline)
>
> when run i have this error:
>
> scheme@(guile-user)> (load "start-λογικι-guile+.scm")
> ;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
> ;;;       or pass the --no-auto-compile argument to disable.
> ;;; compiling /usr/local/share/guile/site/3.0/Scheme+.scm
> ;;; compiling /usr/local/share/guile/site/3.0/growable-vector.scm
> ;;; compiled /Users/mattei/.cache/guile/ccache/3.0-LE-8-4.6/usr/local/share/guile/site/3.0/growable-vector.scm.go
> ;;; compiled /Users/mattei/.cache/guile/ccache/3.0-LE-8-4.6/usr/local/share/guile/site/3.0/Scheme+.scm.go
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Wrong type to apply: #<syntax-transformer overload>
>
> Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
> scheme@(guile-user) [1]> ,bt
> In ice-9/boot-9.scm:
>    2836:4  4 (save-module-excursion _)
>   4388:12  3 (_)
> In /Users/mattei/Library/CloudStorage/Dropbox/git/library-FunctProg/guile/logiki+.scm:
>    4418:0  2 (_)
>    4418:0  1 (_)
> In ice-9/boot-9.scm:
>   1685:16  0 (raise-exception _ #:continuable? _)
> scheme@(guile-user) [1]>
>
> i found really poor info on this error:
>
> https://stackoverflow.com/questions/50057773/sicp-practise-3-51-wrong-type-to-apply-syntax-transformer-cons-stream
>
> any idea?
>
> regards,
> Damien

Re: error Wrong type to apply: #<syntax-transformer

[Jean Abou Samra]

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

> overload.scm must be before some definitions of scheme-infix.scm even
> if it is not used here, it is strange, i do not understand all but it
> compiles now


A minimal reproducer for your problem is

(define (foo)
  (bar 'quux))
(define-syntax-rule (bar x) x)
(display (foo))



Let's dissect what happens. At macro expansion time (during byte compilation),
first the definition of foo is expanded. bar is unbound, so it's compiled as a
function call. Then comes the definition of bar as a macro, but foo has already
been expanded without it.

At runtime, a macro is bound to a syntax transformer, so the binding for bar
that was unresolved at expand time gets resolved to the toplevel binding that
gets defined for bar, and you get this error because a macro transformer can't
be called as  a function.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: error Wrong type to apply: #<syntax-transformer

[Damien Mattei]

thank you
it is clear now , even if i really never find the macro needed upward
i tested too in racket your example and the messages is simple to understand :

Welcome to DrRacket, version 8.9 [cs].
Language: reader
"../Scheme-PLUS-for-Racket/main/Scheme-PLUS-for-Racket/SRFI/SRFI-105.rkt",
with debugging; memory limit: 8192 MB.
'()
> foo
foo: undefined;
 cannot reference an identifier before its definition
> bar
bar: undefined;
 cannot reference an identifier before its definition
> (define (foo)
  (bar 'quux))
> (define-syntax-rule (bar x) x)
> (display (foo))
. . ../../../../../../../Applications/Racket
v8.9/collects/racket/private/kw.rkt:1263:25: bar: undefined;
 cannot reference an identifier before its definition

On Thu, Aug 3, 2023 at 11:58 AM Jean Abou Samra <jean@abou-samra.fr> wrote:
>
> overload.scm must be before some definitions of scheme-infix.scm even
> if it is not used here, it is strange, i do not understand all but it
> compiles now
>
>
>
> A minimal reproducer for your problem is
>
> (define (foo)
>   (bar 'quux))
> (define-syntax-rule (bar x) x)
> (display (foo))
>
>
> Let's dissect what happens. At macro expansion time (during byte compilation), first the definition of foo is expanded. bar is unbound, so it's compiled as a function call. Then comes the definition of bar as a macro, but foo has already been expanded without it.
>
> At runtime, a macro is bound to a syntax transformer, so the binding for bar that was unresolved at expand time gets resolved to the toplevel binding that gets defined for bar, and you get this error because a macro transformer can't be called as  a function.
>
>

Re: error Wrong type to apply: #<syntax-transformer

[Damien Mattei]

i know what disturb me in this error, it is because the order of
definitions has effect but i always learn (was it right?) that in
scheme the order of definitions should have no effect on the resulting
evaluations.

On Thu, Aug 3, 2023 at 1:01 PM Damien Mattei <damien.mattei@gmail.com> wrote:
>
> thank you
> it is clear now , even if i really never find the macro needed upward
> i tested too in racket your example and the messages is simple to understand :
>
> Welcome to DrRacket, version 8.9 [cs].
> Language: reader
> "../Scheme-PLUS-for-Racket/main/Scheme-PLUS-for-Racket/SRFI/SRFI-105.rkt",
> with debugging; memory limit: 8192 MB.
> '()
> > foo
> foo: undefined;
>  cannot reference an identifier before its definition
> > bar
> bar: undefined;
>  cannot reference an identifier before its definition
> > (define (foo)
>   (bar 'quux))
> > (define-syntax-rule (bar x) x)
> > (display (foo))
> . . ../../../../../../../Applications/Racket
> v8.9/collects/racket/private/kw.rkt:1263:25: bar: undefined;
>  cannot reference an identifier before its definition
>
> On Thu, Aug 3, 2023 at 11:58 AM Jean Abou Samra <jean@abou-samra.fr> wrote:
> >
> > overload.scm must be before some definitions of scheme-infix.scm even
> > if it is not used here, it is strange, i do not understand all but it
> > compiles now
> >
> >
> >
> > A minimal reproducer for your problem is
> >
> > (define (foo)
> >   (bar 'quux))
> > (define-syntax-rule (bar x) x)
> > (display (foo))
> >
> >
> > Let's dissect what happens. At macro expansion time (during byte compilation), first the definition of foo is expanded. bar is unbound, so it's compiled as a function call. Then comes the definition of bar as a macro, but foo has already been expanded without it.
> >
> > At runtime, a macro is bound to a syntax transformer, so the binding for bar that was unresolved at expand time gets resolved to the toplevel binding that gets defined for bar, and you get this error because a macro transformer can't be called as  a function.
> >
> >

Re: error Wrong type to apply: #<syntax-transformer

[Jean Abou Samra]

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

Le vendredi 04 août 2023 à 10:23 +0200, Damien Mattei a écrit :
> i know what disturb me in this error, it is because the order of
> definitions has effect but i always learn (was it right?) that in
> scheme the order of definitions should have no effect on the resulting
> evaluations.


Not really, you cannot do

(define b (1+ a))
(define a 5)

either. You *can* do

(define (b) (1+ a))
(define a 5)

but that's because the definition of b does not use the binding for a, only
capture it in a lambda abstraction. The reason you cannot do

(define b (mac 1))
(define-syntax-rule (mac x) x)

is that the (mac 1) expression used in the binding of b is using the macro (at
expand time), just like in my first example it was using the variable a (at
runtime).





[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: error Wrong type to apply: #<syntax-transformer

[Damien Mattei]

yes :-) i will keep it in mind. It is a bit like a let* i tends to
forget it sometimes.

On Fri, Aug 4, 2023 at 10:31 AM Jean Abou Samra <jean@abou-samra.fr> wrote:
>
> Le vendredi 04 août 2023 à 10:23 +0200, Damien Mattei a écrit :
>
> i know what disturb me in this error, it is because the order of
> definitions has effect but i always learn (was it right?) that in
> scheme the order of definitions should have no effect on the resulting
> evaluations.
>
>
>
> Not really, you cannot do
>
> (define b (1+ a))
> (define a 5)
>
> either. You *can* do
>
> (define (b) (1+ a))
> (define a 5)
>
> but that's because the definition of b does not use the binding for a, only capture it in a lambda abstraction. The reason you cannot do
>
> (define b (mac 1))
> (define-syntax-rule (mac x) x)
>
> is that the (mac 1) expression used in the binding of b is using the macro (at expand time), just like in my first example it was using the variable a (at runtime).
>
>
>

Re: error Wrong type to apply: #<syntax-transformer

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 2594 bytes --]



Op 03-08-2023 om 11:58 schreef Jean Abou Samra:
>> overload.scm must be before some definitions of scheme-infix.scm even
>> if it is not used here, it is strange, i do not understand all but it
>> compiles now
> 
> 
> A minimal reproducer for your problem is
> 
> (define (foo)
>    (bar 'quux))
> (define-syntax-rule (bar x) x)
> (display (foo))
> 
> 
> 
> Let's dissect what happens. At macro expansion time (during byte compilation),
> first the definition of foo is expanded. bar is unbound, so it's compiled as a
> function call. Then comes the definition of bar as a macro, but foo has already
> been expanded without it.
> 
> At runtime, a macro is bound to a syntax transformer, so the binding for bar
> that was unresolved at expand time gets resolved to the toplevel binding that
> gets defined for bar, and you get this error because a macro transformer can't
> be called as  a function.

Also, note that this only applies to top-level definitions (this is 
already referred to by the previous response, but only implicitly and 
perhaps only by accident).  In a lambda/let/define/..., however, you can 
refer to the 'bar' macro before it has been defined:

;; Evaluates to the symbol 'quux'
(let ()
   ;; Note: this 'bar' and 'foo' is only  available inside this 'let'.
   (define (foo)
     (bar 'quux))
   (define-syntax-rule (bar x) x)
   (foo))

As such, this not working on the top-level seems a bug to me -- after 
all, a module definition is conceptually just a big let:

<enable extra reader syntax> (if applicable)
(let ()
   <magic to make imports work>
   (define ...)
   (define-syntax-rule ...) ...
   ;; use a new macro using syntax-local-binding
   ;; to extract the syntax transformer (*).
   <insert stuff in hash tables>)

(*) not sure if that precise approach actually works in this context

> i know what disturb me in this error, it is because the order of
> definitions has effect but i always learn (was it right?) that in
> scheme the order of definitions should have no effect on the resulting
> evaluations.

Barring the caveat mentioned in the previous follow-up response and 
barring any mutation (*), I think I learned this too somewhere (though I 
don't recall where), but Guile Scheme apparently doesn't implement this 
completely (i.e. in case of top-level things).

(*) Example:

(define a 0)
(define (count!)
   (set! a (+ a 1))
   a)
;; Order of 'a' and 'b' is important!
;; I wouldn't rely on Guile doing 'b' before 'c', though.
(define b (count!))
(define c (count!))

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

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

Re: error Wrong type to apply: #<syntax-transformer

[Damien Mattei]

i think when defining procedure in a file or even toplevel, the order
is of no importance , but seems not to be the case for macro if i
remember correctly the examples of the discussion threads last
week,and of course, as you mention it, for defining variables
dependant of each others, the order is important.

On Tue, Aug 8, 2023 at 9:38 PM Maxime Devos <maximedevos@telenet.be> wrote:
>
>
>
> Op 03-08-2023 om 11:58 schreef Jean Abou Samra:
> >> overload.scm must be before some definitions of scheme-infix.scm even
> >> if it is not used here, it is strange, i do not understand all but it
> >> compiles now
> >
> >
> > A minimal reproducer for your problem is
> >
> > (define (foo)
> >    (bar 'quux))
> > (define-syntax-rule (bar x) x)
> > (display (foo))
> >
> >
> >
> > Let's dissect what happens. At macro expansion time (during byte compilation),
> > first the definition of foo is expanded. bar is unbound, so it's compiled as a
> > function call. Then comes the definition of bar as a macro, but foo has already
> > been expanded without it.
> >
> > At runtime, a macro is bound to a syntax transformer, so the binding for bar
> > that was unresolved at expand time gets resolved to the toplevel binding that
> > gets defined for bar, and you get this error because a macro transformer can't
> > be called as  a function.
>
> Also, note that this only applies to top-level definitions (this is
> already referred to by the previous response, but only implicitly and
> perhaps only by accident).  In a lambda/let/define/..., however, you can
> refer to the 'bar' macro before it has been defined:
>
> ;; Evaluates to the symbol 'quux'
> (let ()
>    ;; Note: this 'bar' and 'foo' is only  available inside this 'let'.
>    (define (foo)
>      (bar 'quux))
>    (define-syntax-rule (bar x) x)
>    (foo))
>
> As such, this not working on the top-level seems a bug to me -- after
> all, a module definition is conceptually just a big let:
>
> <enable extra reader syntax> (if applicable)
> (let ()
>    <magic to make imports work>
>    (define ...)
>    (define-syntax-rule ...) ...
>    ;; use a new macro using syntax-local-binding
>    ;; to extract the syntax transformer (*).
>    <insert stuff in hash tables>)
>
> (*) not sure if that precise approach actually works in this context
>
> > i know what disturb me in this error, it is because the order of
> > definitions has effect but i always learn (was it right?) that in
> > scheme the order of definitions should have no effect on the resulting
> > evaluations.
>
> Barring the caveat mentioned in the previous follow-up response and
> barring any mutation (*), I think I learned this too somewhere (though I
> don't recall where), but Guile Scheme apparently doesn't implement this
> completely (i.e. in case of top-level things).
>
> (*) Example:
>
> (define a 0)
> (define (count!)
>    (set! a (+ a 1))
>    a)
> ;; Order of 'a' and 'b' is important!
> ;; I wouldn't rely on Guile doing 'b' before 'c', though.
> (define b (count!))
> (define c (count!))

Re: error Wrong type to apply: #<syntax-transformer

[Jean Abou Samra]

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

Le mardi 08 août 2023 à 21:38 +0200, Maxime Devos a écrit :
> As such, this not working on the top-level seems a bug to me -- after 
> all, a module definition is conceptually just a big let:
> 
> <enable extra reader syntax> (if applicable)
> (let ()
>    <magic to make imports work>
>    (define ...)
>    (define-syntax-rule ...) ...
>    ;; use a new macro using syntax-local-binding
>    ;; to extract the syntax transformer (*).
>    <insert stuff in hash tables>)
> 
> (*) not sure if that precise approach actually works in this context



This is very tempting to believe, and I wish it were true, but it's not true.

At least in Guile, the <insert stuff in hash tables> part doesn't happen
at the end of evaluating the module. Each module variable is created and
inserted while evaluating the define form. Otherwise this would give
an error:

(define a 5)
(define b (module-ref (current-module) 'a))
(display b)

The consequences are not innocent.

A variable is associated to a binding which is a "place" in the terminology
of some other languages, i.e., something you can set!. For toplevel variables,
because you can use module-set!, a module variable is used as the place.

And because module variables are bound to names which are just symbols,
duplicate definitions stomp on each other. Consider this:

(define a 5)
(define (b) a)
(define a 6)
(display (b))

This is valid in Guile and prints 6. The second definition for `a` reuses
the same variable as the first one, effectively acting like a set!.
Contrast this with

(let ()
  (define a 5)
  (define (b) a)
  (define a 6)
  (display (b)))

which raises an error due to the duplicate binding.

As https://okmij.org/ftp/Scheme/macros.html#syntax-rule-dark-corner
puts it, "the top level of Scheme is indeed under-specified and treacherous".

Best,

Jean


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: error Wrong type to apply: #<syntax-transformer

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 3272 bytes --]



Op 09-08-2023 om 01:00 schreef Jean Abou Samra:
> Le mardi 08 août 2023 à 21:38 +0200, Maxime Devos a écrit :
>> As such, this not working on the top-level seems a bug to me -- after
>> all, a module definition is conceptually just a big let:
>>
>> <enable extra reader syntax> (if applicable)
>> (let ()
>>     <magic to make imports work>
>>     (define ...)
>>     (define-syntax-rule ...) ...
>>     ;; use a new macro using syntax-local-binding
>>     ;; to extract the syntax transformer (*).
>>     <insert stuff in hash tables>)
>>
>> (*) not sure if that precise approach actually works in this context
> 
> 
> 
> This is very tempting to believe, and I wish it were true, but it's not true.
> 
> At least in Guile, the <insert stuff in hash tables> part doesn't happen
> at the end of evaluating the module. Each module variable is created and
> inserted while evaluating the define form. Otherwise this would give
> an error:
> 
> (define a 5)
> (define b (module-ref (current-module) 'a))
> (display b)

I don't see a problem here, only a little backwards-incompatibility (I 
mean, you could just ... not do that, and do (define b a) instead).

And furthermore that incompatibility could be resolved by doing the 
<insert stuff> after the corresponding (define ...) instead of at the end:

(define modules (make-hash-table))
(let ((this-module (make-hash-table)))
   (hash-set! modules '(this module) this-module)
   (define (foo)
     (bar 'quux))
   (hash-set! this-module 'foo foo)
   (define foo-via-module-ref (hash-ref this-module 'foo))
   (hash-set! this-module 'foo-via-module-ref foo-via-module-ref)
   (define bar-procedure
     (syntax-rules ()
       ((x) x)))
   (define-syntax-rule (bar x) x)
   ;;(hash-set! this-module 'bar <make a syntax transformer>)
   ;; output: quux
   (display (foo))
   (newline))
;; output: quuxquux
(display ((hash-ref (hash-ref modules '(this module)) 'foo)))
(display ((hash-ref (hash-ref modules '(this module)) 'foo-via-module-ref)))
(newline)

> The consequences are not innocent.
> 
> A variable is associated to a binding which is a "place" in the terminology
> of some other languages, i.e., something you can set!. For toplevel variables,
> because you can use module-set!, a module variable is used as the place.
> 
> And because module variables are bound to names which are just symbols,
> duplicate definitions stomp on each other. Consider this:
> 
> (define a 5)
> (define (b) a)
> (define a 6)
> (display (b))
 > [...]

That problem can be avoided by disallowing duplicate definitions and 
requiring using 'set!' for such things instead.

> This is valid in Guile and prints 6. The second definition for `a` reuses
> the same variable as the first one, effectively acting like a set!.
> Contrast this with
> 
> (let ()
>    (define a 5)
>    (define (b) a)
>    (define a 6)
>    (display (b)))
> 
> which raises an error due to the duplicate binding.
> 
> As https://okmij.org/ftp/Scheme/macros.html#syntax-rule-dark-corner
> puts it, "the top level of Scheme is indeed under-specified and treacherous".

It can be made a bit more specified and less treacherous.

> Best,
> 
> Jean
> 

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

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

Re: error Wrong type to apply: #<syntax-transformer

[Maxime Devos]

[-- Attachment #1.1.1: Type: text/plain, Size: 280 bytes --]

 > [...]

For reloadable modules, references to ‘top-level’ variables need to be 
done via a 'module-ref' equivalent instead of a direct (lexical) 
reference, but I think the compiler or expander could handle that 
without too much trouble (it does so already I think).

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

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

Re: error Wrong type to apply: #<syntax-transformer

[Jean Abou Samra]

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

Le mercredi 09 août 2023 à 11:42 +0200, Maxime Devos a écrit :
> 
> 
> Op 09-08-2023 om 01:00 schreef Jean Abou Samra:
> > Le mardi 08 août 2023 à 21:38 +0200, Maxime Devos a écrit :
> > > As such, this not working on the top-level seems a bug to me -- after
> > > all, a module definition is conceptually just a big let:
> > > 
> > > <enable extra reader syntax> (if applicable)
> > > (let ()
> > >     <magic to make imports work>
> > >     (define ...)
> > >     (define-syntax-rule ...) ...
> > >     ;; use a new macro using syntax-local-binding
> > >     ;; to extract the syntax transformer (*).
> > >     <insert stuff in hash tables>)
> > > 
> > > (*) not sure if that precise approach actually works in this context
> > 
> > 
> > 
> > This is very tempting to believe, and I wish it were true, but it's not
> > true.
> > 
> > At least in Guile, the <insert stuff in hash tables> part doesn't happen
> > at the end of evaluating the module. Each module variable is created and
> > inserted while evaluating the define form. Otherwise this would give
> > an error:
> > 
> > (define a 5)
> > (define b (module-ref (current-module) 'a))
> > (display b)
> 
> I don't see a problem here, only a little backwards-incompatibility (I 
> mean, you could just ... not do that, and do (define b a) instead).



I didn't say that it couldn't be improved, only that it didn't work like you
described in current Guile.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]