On Fri, 10 Apr 2026, Zelphir Kaltstahl <[email protected]> wrote:
> On 4/9/26 20:38, Olivier Dion wrote:
>> I've made a short summary of what was discussed during the BoF. I did
>> not take notes during the vent so I certainly forgot something here:
[...]
>>
>> - Macro-expansions and having a macro-stepper for debugging
>>
[...]
> Geiser in Emacs can somehow already expand Guile macros. Maybe there are
> things there, that could be used, expanded (ha!), or built upon?
AFAIK, Geiser is just a REPL. If you are talking about `,expand', then
that's Guile meta-command for expanding a form. Otherwise, I don't know
what you are referring to.
> What else comes to my mind is the question, how difficult it would be to make
> Guile syntax objects carry source location information like they do in
> Racket
They already do. See syntax-source and syntax-sourcev. Are you talking
about other thing?
> (if I recall correctly). If syntax objects had that, things like implementing
> basic type systems as macros might become feasible. I think that, because I
> think that it might be possible to then store and reference such locations in
> some kind of data structure when macros are expanded, and then output error
> messages when types mismatch, with correct source location. But without even
> being able to access or lookup global source locations, I don't see how one
> could possibly implement something like a type system.
Compile time types mismatch require more than basic expansion with
source tracking. Well .. there are possible hacks [0] .. but you still
need a compiler to do the job .. and yes source location would need to
be propagated down the pipeline which I think is the case already.
It is already possible to do type-checking at runtime like BLUE does for
object definition. By inlining the source-location at the creation
sites, users get a very nice error reporting with exact source-location
of the field that has the wrong type.
Example:
42 (define-blue-class <foo> ()
43 (bar
44 #:init-keyword #:bar
45 #:type string?))
46
47 (foo
48 (bar 1))
$ blue build
Error while loading file blueprint.scm:
&programming-error
origin:
blueprint.scm:48:6:
┌
47│(foo
> 48│ (bar 1))
│ ^
└
irritants:
(#:class
#<<blue-class> <foo> 7f6fc5492380>
#:slot-name
bar
#:slot-type
#<procedure string? (_)>
#:value
1)
message:
Bad VALUE.
So it's already possible to go quite far with current macros in Guile.
> Perhaps much more than source locations is needed for that (what can
> we learn from Racket?), or I am simply wrong about source locations
> being required. I am not an expert for type systems and their
> implementations. And it's also not, that I have a specific need for
> such a type system. It is rather that I am thinking it would get rid
> of a limitation of Guile macros. Anyone feel free to correct me on any
> points here.
I don't know either. But I can certainly read on this if someone has
some papers to provide.
[0]:
https://raw.githubusercontent.com/efficios/libside/refs/heads/master/include/side/static-check.h
Thanks,
Olivier
--
Olivier Dion
