IRC channel logs
2025-03-05.log
back to list of logs
<__monty__>rlb: Thanks for the help. I'm not quite there yet but at least I found out about #{ }# and apparently the equivalent | | from R7RS. <__monty__>Seems like I was adding the wrong path to load-path. <__monty__>Next bit I'm stuck on is that it seems dots are not allowed in module names? <mwette>seems like a syntax-case macro to run string->symbol on (define-module/string-path ("foo bar" "baz quuz") might work <__monty__>The #{ }# works fine for the spaces. I've got the MWE working. <__monty__>Now I'm trying a module with a . in the name though and that's not working. <__monty__>The docs for source properties mention Guile moving to read-syntax but I can't figure out how to get the current file path out of that, to replace current-filename. <ArneBab>What do you try to achieve with the file path? <__monty__>ArneBab: I'm not sure how using module-filename would differ from current-filename? <__monty__>Your linked script seems to get the parent directory in Bash, rather than Guile? <__monty__>To be clear, current-filename works for me but the docs say that read-syntax is the better way going forward. I just can't figure out how to get the path to the current file using read-syntax. I'm also not sure that's what the docs really intend though, maybe it's just about current-source-location? <__monty__>Is there any reason use-modules would not allow . in module names? <ArneBab>__monty__: yes, I get the parent directory from bash, because there I have the filename. <ArneBab>⇒ the actual filename the file was called with. <ArneBab>module-filename enables getting the filiename from other modules than the current. <ArneBab>There can be differences between compile-time and runtime <ArneBab>But the most robust way I found is doing it directly in bash and then exec’ing the file with Guile. <rlb>i.e. if you want the dir that's the parent of the script, but I'm not sure that's what you meant. <__monty__>It's the . in a module name that is throwing a spanner in the works. <__monty__>Would program-arguments work in a module that gets imported in the script being run? (I assume current-filename does.) <rlb>Offhand, I doubt it -- i.e. the module's going to be loaded via load-path, and so might be "anywhere" relative to the original script dirname. <rlb>(Sounds like I wasn't addressing what you're trying to do.) <__monty__>rlb: Just tried putting a module in between the two modules, to use current-filename from that module to add to its load-path and it seems to work as expected. <__monty__>Yeah, so current-filename seems more correct to me. The only problem is the docs suggesting read-syntax instead and me not being able to figure out how to get the same path out of that. <__monty__>But what I care more about is whether . can be part of a module name (in combination with spaces). <rlb>It looks like it doesn't work, and from the strace output, I'd *guess* that it's because something is assuming that if there's a ".*" in the path, then it shouldn't tack on the normal extensions like .go/.scm when looking for the source. <rlb>But that's just at guess. <__monty__>Ah, and appending .scm to the module name seems to be allowed. <rlb>Offhand, I'd guess that's a side-effect, i.e. any extension it normally looks for would work. <__monty__>Since Guile expects .scm, maybe it should check whether the suffix is .scm and if not try appending .scm anyway? <__monty__>I think the docs only mention looking for .scm? <rlb>And speculating further, I'd guess it's because module loading is using the same function intended for other things where it *did* want to be clever. <rlb>Because there's no reason if the module name is "foo.bar" it shouldn't be looking for just foo.bar.{known extensions}. <rlb>I suspect .go will work too. <rlb>i.e. guile will prefer a .go file if it finds it first iirc <rlb>Though also, iirc, I think (imo) the current algorithm might be slightly broken (or at least surprising). <rlb>ACTION has intended to pursue it "later". <__monty__>I suspect .go might work after the module has been compiled but before it'll result in the file not being found, no? <rlb>That is, iirc, if guile finds a file in the load path and it fails to compile, guile will try again, and potentially end up using "stale" code that has nothing to do with what was in the first file it tried. <rlb>I think it should just halt on that first failure. <rlb>Because if I have foo/bar/baz.scm and foo/bar first in the load path, I don't *ever* expect it to run code for (foo bar) from some other dir. <rlb>It should either run foo'/bar/baz.* or crash. <__monty__>I understand skipping appending an extension if the argument already has that suffix. But I do think any dots in the name isn't a good heuristic for "does this argument have an extension?" <rlb>Seems like it could introduce security issues, i.e. if you tried to fix a bug by putting the bug-fix first in the path, but the bug-fix code was broken itself somehow -- you'd silently end up running the bad code. <__monty__>Does it ever try to load a file without an extension though? <rlb>(bug fix ended up broken in that it was unreadable (new "bad sector"), or wouldn't compile, etc. <__monty__>Your argument would certainly apply with a couple more dots in the names though. <rlb>I suppose if we do decide we want to change any of that, we'd have to make it opt-in until 3.2. <__monty__>That sounds like a pretty kludgy way to fix things. But I do agree silently skipping over such errors probably does more harm that good "fail fast" and all that. <rlb>Naively, atm I think that guile should never go further than the first directory it finds with a matching "name" in the load path, i.e. if a dir has a suitable .scm or .go file, use the .go if it's newer, or build a new .go and use that, or crash if anything goes wrong, but don't try again elsewhere. <rlb>I wondered if the current behavior might just be an oversight. <__monty__>As a pretty much complete outsider to Guile that sounds sensible to me. <rlb>Dawns on me that I should (have) filed(d) a bug :) <rlb>ACTION will put that on the list <__monty__>I mostly want it to still try appending .scm even if there's a . in the name though. Not trying any module(.scm)+.scm if desired, not sure it's harmful to try but seems reasonable rather than random. <__monty__>Thanks for the help all! Now I can finally use my previous SICP exercises as modules in later exercises without changing my naming scheme : ) <rlb>if your module name is foo.scm, I think it should only look for files foo.scm.scm foo.scm.go, etc. <rlb>the file foo.scm should be irrelevant there <__monty__>Pretty flexible all things considered, Haskell's a lot less flexible when it comes to module names. <rlb>Yeah, stepping back -- in truth, I'd really say "don't do that then", i.e. this is an edge case because "no one uses dots in module names" :) <rlb>But it should still either be invalid or "work right". <__monty__>That's a valid take yeah. Though I could imagine keeping not appending .scm as a backwards compatibility. <__monty__>Yeah, the only reason I've been pursuing this is nothing saying "module names can't have spaces and dots." : > <dsmith>Something that's been lurking in my mind for a while, is that there is only the implicit {name}.go depends on {name}.scm dependency. A single .go might (usually) uses several modules. <dsmith>Any one of which could be newer that the .go file. <dsmith>.go files do not carry a list of dependencies <__monty__>That's a good point too. Something could be just a re-export of another module. There's no way around checking the entire recursive closure I suppose. <lilyp>yeah, that is a real problem when it comes to module abi <lilyp>guix has checks to detect these kinds of breakages in its Make-based build system