IRC channel logs


back to list of logs

<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>héllo :)
***amz31 is now known as amz3`
<galex-713>plop :)
<amz3`>ACTION watching Mr. Robot
<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
<amz3`>I think* you should
<davexunit>amz3`: sure, that sounds good
***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?
<civodul>like a plain string, Boolean, etc.
<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
<civodul>ah ok, thanks mark_weaver
<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
<mark_weaver>in order to really understand psyntax, you need to read the paper cited in its source code: "Syntax Abstraction in Scheme" by Dybvig, Hieb, and Bruggeman. <>
<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
<ijp> (Syntactic Abstraction: The syntax-case expander)
<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>ijp, my old scottish friend
<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?
<ijp> is what I read last year
<wingo>is that related to flatt's scope sets or is it a different thing?
<holomorph>squiggly arrows!
<ijp>wingo: different afaict
<ijp> partially covers how they relate
<wingo>so i ran into a problem
<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
<civodul>very good point
<wingo>so that's where i am now :)
<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" :/
<janneke>ouch :-)
<civodul>that's terrrrrible :-)
<janneke>how about another terrrible idea...
<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
<civodul>it's a transitional thing
<wingo>janneke: not a bad idea
<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) :)
<janneke>haha *lol*
<wingo>at least if they build their .go files in their source directories :)
<janneke>that would be painful
<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?
<civodul>currently no, but they should
<civodul>we could just merge them
<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>with different semantics
<wingo>GUILE_COMPILED_PATH, or something similarly confusing, which always appends the version...
<civodul>what about removing those warnings?
<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 :)
<wingo>but, zzzzzzzzzz
<janneke>night, thanks!