On 4/9/26 20:38, Olivier Dion wrote:
Thanks to everyone! I think that it was a good first BoF session. Like
mentioned, I was thinking of making a new one in about 3 months. I
think this make sense given the synchronization overhead of multiple
time-zone but also the speed at which Guile is developed. In the
meantime, discussions continue on Codeberg, IRC and the mailing lists!
Also I think that the Jitsi call worked well enough for all. I talked
at the beginning of finding an alternative where we could move around
rooms, but really I don't think that's necessary for now.
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:
- The usage of the meta-commands ,expand and ,optimize
- The usage of the meta-command ,option and an example of its usage
with ,option optimization-level N
- Missing examples for REPL meta-commands in the documentation
- Discussions about the upcoming utf-8 merge
- Bumping of minimal version of bdwgc
- Potential change in releasing numbering semantic (Y vs Z releases)
- Missing bits for compiling modules in a reproducible way
- Macro-expansions and having a macro-stepper for debugging
- Tricks for debugging macros by quoting every cases in it
- Better backtrace à la BLUE with possibly a new API for it
- Problem with using @@ with optimized .go files
- Adding compiler hints such as `do-not-inline'
- Finding a path to make a Guile project self-contained as a single
binary
Also, at the peak of the event, we were 21 I think. On Easter Monday!
Overall, I think that around different 30 peoples joined in total.
Thanks,
Olivier
Hi Olivier!
The macro expansions and macro stepper sounds like something that should exist,
considering, that one can do fancy stuff using macros. I only have one input
there: Geiser in Emacs can somehow already expand Guile macros. Maybe there are
things there, that could be used, expanded (ha!), or built upon?
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
(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.
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.
Best regards,
Zelphir
--
repositories: https://codeberg.org/ZelphirKaltstahl
