<galex-713>Hey, with native compilation support, would guile be fine to define a language to write a kernel in? <galex-713>I mean, something better than C, but not badly reinventing the wheel like rust ***amz31 is now known as amz3`
<amz3`>davexunit: did you have a look at my csv parser using guile parser combinator? <amz3`>davexunit: I you should add parse-unless in guile parser combinator ***Bobbejaantje is now known as McSlavic
<civodul>is it just a Guile thing that a "transformer" can return something that is not a syntax object? <ijp>maybe other psyntax schemes let you do it for non-symbol constants, but I haven't checked <civodul>r6rs-lib section 12.3 says that a transformer must return a syntax object <civodul>i had assumed that self-evaluating objects were fine <mark_weaver>civodul: the representation for syntax objects includes things like strings, booleans, etc <mark_weaver>civodul: the only kind of syntax object that requires annotation are identifiers <mark_weaver>when the annotations are placed higher up in a tree, those annotations semantically only apply to the identifiers within, but that work is done lazily <mark_weaver>they are pushed down into subtrees incrementally as expansion proceeds <civodul>ah yes, "foo" is a "syntax object", but #'id is a "wrapped syntax object" <civodul>apparently that's the terminology in R6 <ijp>racket makes sure to wrap pairs too, which can give better error messages, but I don't think fundamentally changes anything <mark_weaver>but basically the wrap can be thought of as a set of identifier substitutions to be applied to the datum within <civodul>yeah, i should finally read that paper... <ijp>you can get a decentish understading from dybvig's "Beautiful Code" version <mark_weaver>ijp: ah, thanks for the link. I haven't read that version yet. could be better than the other, dunno. <ijp>I'd like to experiment with a new expander at some point, based on the more recent nominal logic based definitions of hygiene, but it would definitely not be a production thing <ijp>maybe over christmas ... <McSlavic>It has been too long since I last heard your scottish accent. <mark_weaver>ijp: oh, interesting! can you cite any relevant papers for that? <wingo>is that related to flatt's scope sets or is it a different thing? <ijp>wingo: different afaict <wingo>related to .go files, 2.0, and 2.2 <wingo>the context is that based on a patch from janneke i made it so that guile will skip .go files it doesn't understand <wingo>the goal is to allow users to build environments with both guile 2.0 and 2.2 .go files <wingo>and possibly both guile 2.0 and 2.2 or apps using them, not necessarily linked together but available at the same time <wingo>that's a bit slow to actually try to load a file and read it just to see that it's the wrong version <wingo>better to install files to different paths in such a way that you don't have to load a file to know that it's the right version, at least in the normal case <wingo>so as civodul proposed i made it so that GUILE_LOAD_COMPILED_PATH appends the effective version <wingo>so GUILE_LOAD_COMPILED_PATH=foo:bar adds foo/2.2 and bar/2.2 to the load path <wingo>but it's not compatible with projects that build .go files in their source trees :/ <wingo>usually projects use GUILE_LOAD_COMPILED_PATH=/path/to/srcdir <wingo>i had a terrrrrrrrrrrrrrrible "idea" <civodul>not appending /2.2 would work as well, as long as incompatible files are skipped <wingo>which was to append the effective version only if the last directory component is "ccache" :/ <wingo>civodul: yes skipping incompatible files is already implemented <wingo>it's just slower than i would like <wingo>and i don't want to bake that into a release as the "normal path" <janneke>go through GUILE_LOAD_COMPILED_PATH again if you failed to find your .go files and then not append 2.x <civodul>wingo: then again, most of the time, there won't be incompatible files in the search path <wingo>so each LOAD_COMPILED_PATH entry is actually two entries <wingo>one with the effective version and one without <janneke>i'm wondering...about your srcdir case <wingo>yeah that would work well for the uninstalled case <janneke>i think it's fair to assume you want to target only one guile major at one time <wingo>people shouldn't name their modules (2.2 foo) :) <wingo>at least if they build their .go files in their source directories :) <wingo>civodul: that's a good point <janneke>suggesting a symlink in your srcdir 2.2 -> . is also not great <wingo>so many bad decisions that i could make ;) <wingo>civodul: for guix if you install guile and guile-next, do their GUILE_LOAD_PATH values compose? <wingo>so as far as skipping .go files goes. it works. however you can get weird warnings. i.e. "warning: X newer than Y; ... found fresh compiled file at Z", where X actually wasn't a compatible .go file <wingo>i suppose we could introduce a ~~new environment variable~~ :P <wingo>GUILE_COMPILED_PATH, or something similarly confusing, which always appends the version... <civodul>also... i've been meaning to write about auto-compilation <civodul>i'm a bit skeptical in hindsight :-) <janneke>i'm not too thrilled by the idea of another env var...esp. if things break you have to check a lot... <janneke>however, GUILE_COMPILED_PATH+2.x idea would keep the srdir thing working and not break backwards compatibility in general <wingo>civodul: hmm, i am interested but skeptical re: auto-compilation skepticism :)