IRC channel logs


back to list of logs

<RavenJoad>haugh: I think use let- prefix when you want a form to behave like a let. Otherwise, a with- prefix is better?
<RavenJoad>I have no idea at all though. I'm just going off the code I have read and the tiny amount I have written.
<haugh>word up, I appreciate your input
<haugh>I shouldn't fixate on this stuff
<RavenJoad>In my inexperienced opinion, use the one that READS better. I think (with-db "db" (query1) (query2) ...) reads better than (let-db "db" (query1) (query2) ...) in this case.
<haugh>yeah currently I have (with-promise p expr . body) expanding to (let-promise ((p expr)) . body)
<haugh>but then again there's with-syntax for example. I need a vacation
<haugh>I don't know the history but if I had to guess I'd say this disctinction arouse in regards to bindings with side effects
<RavenJoad>That would be my guess too.
<apteryx>is it possible to define an srfi library as an r6rs 'library' ?
<apteryx>I'm getting a syntax error when building, coming from the stage0 compiler:
<apteryx>maybe stage0 doesn't know about r6rs library syntax yet?
<apteryx>rnrs library must be compiled by that same stage0... so maybe the prefix has to do with it
<apteryx>(if under rnrs/ install r6rs library syntax or some similar hack[
<apteryx>hm, that works: BOOTSTRAP(stage0) GUILEC rnrs/base.go
<haugh>does your library have a body?
<haugh>I've never used this syntax but my understanding was that you need to put all the code for that library in the tail of that expression, unlike define-module
<apteryx>haugh: ah, found it, the export form must appear before the import form
<apteryx>is this a bug, or a limitation of r6rs lifted in r7rs define-library? seems possible:
<haugh>guix has a bunch of stuff like this too, where syntactic parameters are both named and ordered
<haugh>paramters as in "arguments to a macro", not syntax-parameters
<apteryx>apparently that's how it was in r6rs:
<apteryx>it documents the form with exports appearing before imports
<apteryx>nice improvement in r7rs :-)
<apteryx>are there people working on r7rs define-library?
<apteryx>also, in r6rs' 'library', there can be only a single export and import forms
<haugh>I have r7rs define-library available by default in (guile-user) on 3.0.5
<haugh>you can check it out in ice-9/r7rs-libraries.scm and it has a partitioning system you might adapt for the `library' syntax
<haugh>frankly Guile has enough redundant systems for me without getting into this stuff so I'll just keep generating define-modules statements with my editor
<apteryx>define-library is not documented in guile?
<apteryx>ACTION reads, tries to understand how include vs include-library-declarations differ, and to Guile's own include-from-path
<apteryx>haugh: getting closer, with this:
<apteryx>I may want to revisit how I've adapted srfi-125, 128 and 126 earlier... could have been better perhaps to use define-library to match what upstream used
<apteryx>the problem is that with 'include', as in, the build fails to locate the file, e.g.:
<apteryx>usually that'd work with include-from-path, but define-library doesn't understand that form
<apteryx>(include-from-path is guile-specific)
<euouae>is guile considered mature?
<euouae>and I'm not speaking necessarily of just the language spec, I mean the entire toolchain
<haugh>euouae, Guile is quite mature. _Multiple built-in XML parsers_ mature. Depending on what you're doing with it, your toolchain could look quite different from someone else's. For example I don't integrate with C so I completely ignore the entire autotools system.
<haugh>euouae, if you're trying to understand how most people use Guile today, you should probably investigate Guix.
<euouae>I am into that haugh
<euouae>slowly but certainly
<haugh>I was getting into it with no serious interest in learning Guile and then Guile's depth completely derailed all my plans.
<haugh>I just wanted "less disgusting Nix" and now I write syntax-case every day
<euouae>I'm on that chapter right now
<euouae>The scheme-primer mentions macros briefly but I'm looking into the guile manual now
<euouae>haugh: I entered a lisp game jam and I wrote my game in fennel
<euouae>some others wrote it in guile with guile hoot, using nightly browser features (wasm tc etc)
<euouae>so I was kind of impressed by that sort of thing
<haugh>yes the spritely kids are extremely cool around here
<euouae>fennel is just lua in lisp form so it doesn't actually have heavy features
<haugh>I got the same impression
<euouae>I'm kind of split now
<euouae>fennel (or lua) has a very cool game library called LOVE
<euouae>I'm not sure if guile has something that easy to work with, but guile is definitely the better lisp
<euouae>well anyway. rant over :)
<haugh>I only know it by name but maybe have a look at dthompson/chickadee. Dave is one of the spritely folks involved with hoot
<apteryx>re 'include', the doc (info '(guile) Local Inclusion') says: "path relative to the current directory at compile-time"
<euouae>nice, thank you
<apteryx>*current directory*
<apteryx>but earlier it says: "If FILE-NAME is a relative path, it is searched for relative to the path that contains the file that the ‘include’ form appears in."
<apteryx>seems it'd be preferable if it actually resolved relatively to the file include is used from
<apteryx>hm, Guile uses (dirname filename) according to call-with-include-port
<apteryx>(in psyntax.scm)
<apteryx>ah, my problem is due to %file-port-name-canonicalization which defaults to 'relative
<apteryx>it strips the prefix from the source file being byte compiled
<apteryx>'include' from r7rs 'define-library' is kinda useless with the current behavior of 'include' + the %file-port-name-canonicalization used, at least in a compilation context
<wklew>I also had a lot of trouble getting inclide to behave, ended up having to use a lot of cond-expands and treating guile specially
<wklew>for example, include-library-declarations on a file whoch itself calls include does not seem to be possible in guile
<apteryx>I'm trying to understand if having a current-load-relative-directory fluid set to the original directory of the source in compile-file (then honored by include) would help. that seems to be what racket does
<sneek>apteryx, you have 2 messages!
<sneek>apteryx, podiki says: I didn't realize ungrafting libx11 means rebuilding python and thus basically everything. should I not ungraft on mesa-updates then? or just fold it all into core-updates instead?
<sneek>apteryx, podiki says: that means nghttp2 and curl get rebuilt and should be ungrafted at the same time too. ...which I guess makes it core-updates then. what do you think?
<apteryx>would be nice if sneek had per-channel memory
<old>in theory, if multiple instances of sneeks run, one per-channel, that ought to do it?
<old>The current problem I believe is that there is one sneek for multiple channels
<lilyp>that would work, but it'd also require multiple IRC connections
<lilyp>though perhaps you could wire something with a bouncer in-between
<apteryx>seems it should be relatively simple (TM) to track per-channel?
<apteryx>without having to run one instance per channel
<apteryx>do we have something similar to Racket's split-path?
<old>idk have not look at the code, but I assum that yes
<apteryx>it's to know whether a path is relative or not
<apteryx>ACTION greps guix sources
<old>absolute-file-name? ought do that?
<apteryx>I guess so; split-path seems overkill for the task at hand
<apteryx>some idea I had while looking at fixing 'include' relative file names when using compile-file, which strips the file prefix found in %load-path
<apteryx>perhaps we could canonicalize the syntax-dirname extracted from the syntax in the include macro?
<apteryx>ah, no that's done by fport_canonicalize_filename and it's relative on purpose by default to avoid baking a wrong source file name in the .go
<apteryx>that file name is expected to be found on the load path
<dsmith>sneek, botsnack
<sneek>I've been a process for 19 days
<sneek>This system has been up 31 weeks, 22 hours, 58 minutes
<elevenkb>Hello there, suppose I have a script which should use current-source-directory?
<elevenkb>sorry I meant to say `current-source-directory'.
<elevenkb>Ok, so how does one test such a script in the Guile REPL, given that (current-source-directory) evaluates to #f in the REPL?
<elevenkb>Do I have to substitute a concrete literal value for it, or is there a better alternative?
<sneek>chrislck: Greetings!
<chrislck>sneek: botsnack