Re: Birds of a feather

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=
=20
> 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=20
> 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 implemen=
ting=20
> basic type systems as macros might become feasible. I think that, because=
 I=20
> think that it might be possible to then store and reference such location=
s in=20
> some kind of data structure when macros are expanded, and then output err=
or=20
> messages when types mismatch, with correct source location. But without e=
ven=20
> being able to access or lookup global source locations, I don't see how o=
ne=20
> 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:
          =E2=94=8C
        47=E2=94=82(foo
    >   48=E2=94=82 (bar 1))
          =E2=94=82      ^
          =E2=94=94
   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/i=
nclude/side/static-check.h

Thanks,
Olivier
--=20
Olivier Dion