IRC channel logs
2025-01-07.log
back to list of logs
<daviid>ttz not sure in a (geiser) repl, but you might look and try guild compile -Ohelp <daviid>ttz: transducers are available, see 7.5.47 Transducers <daviid>ttz what is it that you tried using match and didn't work, wrt to easy destructuring? <ttz>match works fine, but it is not a core macro <ttz>having to import it in every single module it is used doesn't push toward functional style imho <ttz>same goes for transducers <daviid>which perfectly ok, i (totally) desagree with your statment that it influences programming style ... but no time nor any wish to argue <daviid>it would be nice to add (ice-9 fibers), not sure why this didn't happen yet <ttz>Let's say that not advertising match as the default destructuring procedure and transducers as the default pipelined-transformation procedure is not making a point toward a "modern" functional style. That's all I was saying. <rlb>fwiw, offhand, I tend to incline against adding things like match/transducers/etc. to the default envt (and maybe much else) -- a "dialect" might make more sense, whether that's some "full" dialect or just a module with a set of exports that's expected to be used without #:select. <rlb>Of course I'm also a fairly big fan of setting a high bar (as clojure does) for breaking backward compat. <rlb>Make new stuff compatible or opt-in. <ttz>aggregation is backward compatible, is it not? <rlb>Not if you already had conflicting bindings in your code. <rlb>Hence the opt-in -- with various potential approches. <ttz>Doesn't a local binding shadow any language defined one? <rlb>(use-modules (guile core 3)) -- kidding (sorta...). <rlb>Of course the bar can't he infinitely high with limited resources. <dsmith>Once something is "in", it's harder to get out for something better. Python has like 3 different url interfaces. <dsmith>One reason why Rust is trying to keep the core small. <dsmith>Goops was an external lib for years, but was eventually added. <dsmith>Is fibers linux-only? Depends on epoll or somthing? <dsmith>Another thing is an external lib can move much faster <daviid>i don't beleive we'll find a better lib then fibers, in the next few decades or so :), and guile already offers linux-only 'things', like posix, so afaic, not a criteria for in or out <dthompson>adding to guile's default environment is a bad idea. there's literally hundreds of bindings in there already. we're kinda stuck with that but we can choose to not make it worse. <dthompson>I'd much rather import things than have stuff just be magically available by default. define-module has a #:pure option that removes the implicit (guile) import. glad that's there, at least. <dthompson>r6rs/r7rs modules did things right with no implicit imports. <daviid>dthompson: i totally agree with you, and keeping the core env minimal is also important for start-up time and what not ... but my point, to share with ttz, was that having to import does not, by zero mean, infuence the programming style of the user, i just wanted to make that point (imo ofc, i respect other's opinions) <dthompson>yeah I think what influences the style more is the documentation. it should be more opinionated about preferring match to manually car/cdring, etc. <Kolev>ACTION copypastas some code. <rlb>(Also feel like an "opinionated" guide to all the stuff we have wouldn't go amiss...) <elpogo>This maybe a stupid question, but is there any chance that the guile VM could be replaced by a wasm/wasi VM in the future? Or is it not technically possible because guile C extensions wouldn't work with wasm/wasi ? <elpogo>I'm aware of hoot mwette. I'm just wondering if the bytecode that guile generates in the .go files could be wasm bytecode <dodoyada>anybody know if I should have to parse url encoding myself when using artanis? seems like it but I don't really expect it <old>elpogo: I would like more an IR bytecode so that one can then translate it to any kind of bytecode <dthompson>one thing I started poking at but haven't gotten anywhere with yet is compiling wasm to guile bytecode <dthompson>I don't know if it would make sense for guile to wasm as its bytecode format but it would be good for guile to have *safe* bytecode like wasm <dthompson>actually, now that I'm thinking about it, it really wouldn't make sense for guile to use wasm as its bytecode. <dthompson>I can think of many reasons why it wouldn't be a good thing to do. <elpogo>dthompson: can you share a couple of reasons? also, is it technically possible for guile bytecode to be lowered further to wasm bytecode, or is wasm/wasi not capable of doing the things that the guile VM is able to do <dthompson>I guess I don't see why you'd want to lower guile bytecode to wasm. makes more sense to lower an IR. hoot lowers cps to wasm <dthompson>there are certain transformations that have to be done for wasm. for example: wasm uses structured control flow, there is no 'jump' instruction. <dthompson>some reasons why guile shouldn't use wasm as its bytecode: <dthompson>1) guile would be giving up control of its vm. it could only do what wasm can do and any improvements for guile's use cases would have to go through the wasm community group and 4 rounds of voting to reach standardization. <dthompson>2) wasm is missing a number of things that guile's vm has, like stack switching for continuations or multi-byte access to (ref (array i8)) instances or variable length function argument lists <dthompson>when wasm is what you have to target, you can deal with all these things, and indeed that's what hoot does, but it wouldn't make sense to give up a vm built for the purpose of running guile. <dthompson>also wasm is a stack machine and guile's vm is a register machine. <elpogo>so will guile VM running .go bytecode always run guile code faster than wasm bytecode compiled by hoot? <dthompson>as of now, the guile vm usually wins but I haven't done extensive benchmarking <dthompson>but sometimes I've seen hoot on v8 go something like 4x faster on certain programs. <elpogo>in a hypothetical world if in the future it turns out that hoot+wasm always runs guile code just as fast or faster than the guile VM, would it make sense to abandon the VM? <dthompson>idk, can't predict the future. by then guile would hopefully have AOT native compilation <elpogo>ok. thanks for sharing dthompson . i hope to ask better questions as i learn more about the guile/hoot compilers. i'm still learning about psyntax right now, so it'll be a while <dthompson>the wasm bytecode format is just optimized for different things <dthompson>like the format needs to be relatively compact to minimize bandwidth usage, etc. <dthompson>which is not really a concern for the guile vm <dthompson>a wasm binary needs to go through a validation pass and then maybe some initial compilation before it can be used (or it can be interpretered directly and then "tier up" later) <dthompson>whereas guile can just load up a .go file, which is an ELF file, page in some stuff, and get running <dthompson>for me, the interesting question is: could guile run wasm files? we already know the answer is "yes" because we have an interpreter, but I'm curious what it looks like to compile wasm to guile bytecode. <elpogo>do you know if it's a goal of the hoot compiler to be bootstrappable? i.e, compile itself to wasm bytecode and have a wasm intperpreter run the compiled compiler <ttz>I don't understand the code of apply in boot-9.scm:61 <ttz>are the arguments really appended in a new list in case more than one argument is passed? why? <lloda>bc the signature of apply is (apply fun arg ... list), but the signature of primitive-apply is only (primitive-apply fun list) <dthompson>that code has a comment above explaining that this the procedure for apply when apply is used as a value <dthompson>the apply primitive has a different implementation <ttz>why can't the second arm simply be ((@@ primitive apply) fun (cons arg1 args))? <ttz>it seems a *new* list is created instead <ttz>Oh so the comment means that if I am evaluating (apply f lst), then a primitive call is performed? But if I do ((λ (apply f lst) (apply apply f lst)) apply f lst) then this function is used? <ArneBab>elpogo: there’s not only raw speed. There’s also memory: V8 can get away with using a lot more memory, because it usually isn’t used for background processes of the OS. wasm should reduce that a bit, but it’s still a different optimization target. <ArneBab>elpogo: also Guile has optimizations for huge numbers that are not a goal of wasm. <elpogo>ttz: "why can't the second arm simply be ((@@ primitive apply) fun (cons arg1 args))" is a good question. In eval.c prepare_boot_closure_env_for_eval, i see that args will be a newly created list, so I don't understand either why it's cons'ing yet another list <elpogo>the spec requires it to be a newly created list -> " The value stored in the binding of the last variable will be a newly allocated list of the actual arguments left over after all the other actual arguments have been matched up against the other formal arguments." <dthompson>ttz: re the second arm of apply: it's because 'args' is a list where the last element is expected to be a list <dthompson>that needs to be transformed into (1 2 3 4 5 6) <dthompson>ArneBab: you're right that wasm has no built-in bigint support. in hoot the host platform provides an implementation. <dthompson>wasm64 will happen eventually, but for the current wasm32 world the fixnum space is 30 bits and then it's bignum time <ttz>dthompson: is this documented somwhere? <ttz>if not, what is the rational behind it? <dthompson>"Scheme Procedure: apply proc arg ... arglst" <dthompson>all good, I would never tell anyone to "rtfm" :) <dthompson>when you use apply you have some number of arguments that you know about, that are fixed, those are "arg ..." in the above signature. then you have some list of additional args that are generated somehow and that's the final "arglst" arg <dthompson>the args you know about ahead of time and those that you don't know until runtime <ttz>yeah, I understand the signature, I just didn't link it with the actual code <ttz>how is case-lambda compiled though? Wouldn't adding a case (fun arg args) good for speed? <dthompson>so, additional cases could be added for specific amounts of fixed args. (fun arg args) would be a special-case for a single fixed arg + an arg list <dthompson>but the (fun arg1 . args) case will always be needed as a fallback for the general case <ttz>yes, i see the map definition has three cases <dthompson>given that most uses of 'apply' are known at compile time and invoke the primitive, I don't see much good in adding additional cases, but you *could* <ttz>You mean when writing (apply f seed args) it can be optimized since the number of arguments is known at compile-time even though there is no matching case? <dthompson>the apply you're looking at isn't even used in that case <ttz>okay, that's what the comment means, I had a doubt <ttz>so indeed this apply must be quite rarely used <dthompson>this type of situation doesn't happen much: (apply apply (list + 1 (list 2 3 4))) <ttz>great, thanks for your answers <elpogo>thanks to you two i just learned that the last argument to apply needs to be a list <ArneBab>I knew about the last element needing to be a list early on, but I only learned much later about the other arguments — and how much is possible with that. <cow_2001>is alex sassmannshausen around here every now and then? <k4r4b3y>Hello. I have been studying the tekuti codebase recently. <k4r4b3y>I am constantly bumping into weird errors and bugs with it. <k4r4b3y>isn't the "GIT_COMMMITTER" (observe the triple-M letters!) a wrong environment variable to pass to the `git' command line tool? <k4r4b3y>moreover, even if you fix the triple-M to its correct spelling, git simply doesn't have the env var, "GIT_COMMITTER". <k4r4b3y>It has, "GIT_COMMITTER_NAME" and "GIT_COMMITTER_EMAIL" <Arsen>perhaps he misremembered.. it is only human to do that <k4r4b3y>but how come he never bumped into any issues with that misspelling? That line didn't have any recent commits since 8 years