***spk121_ is now known as spk121
<lloda>it's too bad the way we do (srfi nn) works only on r6rs forms. use-modules, help, all those still require (srfi srfi-nn) <jpoiret>would it be possible to somehow store some info about the location of syntax that is expanded when compiling .go files? When we change some syntax in a file (happens often in Guix with guix records being macros), we have to manually `rm` the dependencies and recompile them. <jpoiret>also, wouldn't that be a necessity when cross-module inlining gets into guile anyway (if that's in the plans/already done/etc)? <jpoiret>iiuc, the expander works at the guile -> tree-il level, right? <civodul>jpoiret: right now there's no dependency tracking mechanism in Guile <sneek>civodul, you have 1 message! <sneek>civodul, apteryx says: re offloading, ah, indeed parsing my ~/.ssh/config is rather the job of guile-ssh, not guile-git. sorry for the thinko <civodul>so yes, we have to recompile manually <jpoiret>yes, and I guess it'd be pretty hard to integrate it into the current setup, right? <civodul>cross-module inlining poses similar issues, and for that and other reasons i think we'll have to disable it in Guix <civodul>i think it would help if modules supported R6RS-style "phases", where you import a module for expansion-time or run-time <jpoiret>at first I was thinking of making a build system that tracks dependencies by hooking into the (use-modules), but I think it'd be way cleaner to have some sort of dependency tracking directly in the compiler <jpoiret>but yes, the question seems pretty hard, finding where and how to organize it <civodul>i think there are discussions and patches at issues.guix.gnu.org <civodul>but i'm reluctant to having an 80% solution hacked around the compiler ***kir0ul5 is now known as kir0ul
***karlosz_ is now known as karlosz