Loading files which load macros doesn't work #13

rvs314 commented 2023年11月09日 00:43:41 +01:00 (Migrated from gitlab.com)

I'm having an issue when loading a file into a REPL which itself loads a macro. The macro is loaded into the REPL, but isn't available for definitions in the initial file.

Consider two files:

;; A.scm
(define-syntax first-arg
 (syntax-rules ()
 ((first-arg fst snd) fst)))

;; B.scm
(load "A.scm")
(define (use-first)
 (first-arg 1 2))

If I start a geiser session, then load B.scm through geiser-load-file, the macro first-arg is defined and works correctly from the toplevel, and the procedure use-first is defined, but calling (use-first) gives the exception that first-arg isn't bound. If I use (load "B.scm") from the toplevel directly, everything works.

I'm on GNU/Emacs 30.0.5, Geiser 20231001.1932 and Geiser-Chez 20230707.1334.

If this should be moved to the normal Geiser repo I can do so.

I'm having an issue when loading a file into a REPL which itself `load`s a macro. The macro is loaded into the REPL, but isn't available for definitions in the initial file. Consider two files: ```scheme ;; A.scm (define-syntax first-arg (syntax-rules () ((first-arg fst snd) fst))) ``` ```scheme ;; B.scm (load "A.scm") (define (use-first) (first-arg 1 2)) ``` If I start a geiser session, then load `B.scm` through `geiser-load-file`, the macro `first-arg` is defined and works correctly from the toplevel, and the procedure `use-first` is defined, but calling `(use-first)` gives the exception that `first-arg` isn't bound. If I use `(load "B.scm")` from the toplevel directly, everything works. I'm on GNU/Emacs 30.0.5, Geiser 20231001.1932 and Geiser-Chez 20230707.1334. If this should be moved to the normal Geiser repo I can do so.

rvs314 commented 2023年11月09日 00:45:08 +01:00 (Migrated from gitlab.com)

changed the description

changed the description

rvs314 commented 2023年11月09日 00:45:37 +01:00 (Migrated from gitlab.com)

changed the description

changed the description

rvs314 commented 2023年11月09日 00:55:25 +01:00 (Migrated from gitlab.com)

changed title from Loading files {-doesn't work for compiled code-} to Loading files {+which load macros doesn't work+}

changed title from **Loading files {-doesn't work for compiled code-}** to **Loading files {+which `load` macros doesn't work+}**

rvs314 commented 2025年07月13日 03:31:54 +02:00 (Migrated from gitlab.com)

Sorry for bumping a two-year-old issue, but it's been annoying me again. It seems like the reason this occurs is that what geiser calls loading a file and what chez calls loading a file are different operations. When Chez says load, it means the procedure of the same name, which evaluates each input form in series (therefore loading all necessary macros before each next input form is run). Geiser seems instead to mean "compile the entire file into a scheme object file, then load that". That seems like the right behavior for, say, geiser-compile-file, but not geiser-load-file. Is there a reason this incongruity exists? If not, I'd be happy to send a PR changing it.

Sorry for bumping a two-year-old issue, but it's been annoying me again. It seems like the reason this occurs is that what geiser calls `load`ing a file and what chez calls `load`ing a file are different operations. When Chez says `load`, it means the procedure of the same name, which evaluates each input form in series (therefore loading all necessary macros before each next input form is run). Geiser seems instead to mean "compile the entire file into a scheme object file, then load *that*". That seems like the right behavior for, say, `geiser-compile-file`, but not `geiser-load-file`. Is there a reason this incongruity exists? If not, I'd be happy to send a PR changing it.

jaor commented 2025年07月15日 02:37:50 +02:00 (Migrated from gitlab.com)

i cannot remember of any good reason we did it this way, and, given that
we're retaining the current functionality via geiser-compile-file, we
are in no risk of breaking anything much by doing what seems the right
thing for geiser-load-file. so i think i'd welcome your PR, thanks!

i cannot remember of any good reason we did it this way, and, given that we're retaining the current functionality via `geiser-compile-file`, we are in no risk of breaking anything much by doing what seems the right thing for `geiser-load-file`. so i think i'd welcome your PR, thanks!