IRC channel logs
2024-09-02.log
back to list of logs
<old>so arei does not support buffer compilation right now? <old>hm it can eval whole buffer <old>will have to explore it more <robin>hm let-values-checked *should* be let*-values-checked, both forms could be useful. limited to the equivalent of CL's SATISFIES type, not a potentially extensible type system. verbose names. but i like it overall <robin>(if i had a nickel for every time in the past week i'd seen a let*-like form misnamed as a let variant, i'd have two nickels) <robin>(and i still haven't quite decided whether CL's type system being usable for both ensuring correctness and enhancing optimization is a feature or a bug...) <mange>I'm not convinced CL's type system is very useful for ensuring correctness. Not being able to provide the type for list items, or hash table elements, makes it pretty hard to model anything higher level. I find it deeply frustrating to work with for anything except performance optimisation. <mange>I've tried a few times to write type-directed macros in CL (using the MOP to drive things from class definitions) and my conclusion is that you basically have to write types where CL throws away information, and then you have to parse the types by yourself. <mange>Like, for example, (deftype list-of (item-type) 'list). Then you can match types like (list-of string), but any CL-level assertion won't assert the item types. <daviid>the best system 'out there' is the declare cl protocol, so much better <robin>mange, yeah, that's fair, i don't think i've used it much beyond the odd performance hint, and it definitely has glaring omissions like LIST-OF <robin>...leaving SATISFIES for anything complicated <robin>i do like the DECLARE syntax :) <mange>Anything higher order is rubbish. In principle you can specify an element type in an array, but in practice the element type gets generalised to its storage class, or something, so all objects appear the same. You get minimal actual checking out of it. <mange>Also, satisfies has to be a statically known function, so you can't even do things like (deftype list-of (item-type) `(and list (satisfies (lambda (i) (typep? i ',item-type))))). Some CLs allow it, but the standard doesn't (and SBCL doesn't). <mange>The only thing I like about CL's type system is the DECLARE syntax. :) <mange>Which is frustrating, because I quite like a lot of the rest of CL. <mange>Ha, "typep?". I think I'm confused. <robin>i do love the condition system (has scheme come close to catching up there yet?) and CLOS, neither of which are very closely-connected to the type system <robin>(and the actual declaration syntax...my only real complaint is that things like function-type declarations are rather clunky) <robin>mange, hm, so would you say low-level declarations (concerning arrays etc.) aren't actually that useful with modern compilers? i sort of assumed they must have been useful in the past for "fortran-level" performance, but compilers have come a long way since the maclisp days... <mange>No, I think they are very useful for optimisation purposes. Modern compilers are able to infer a lot from a few declarations, and generate quite fast code. What I'm complaining about is that CL's types are geared towards that, whereas I want types for correctness, and for "type directed" metaprogramming. <robin>oic, yeah, that makes sense, and i didn't realize SATISFIES was so limited either <dpk>could it be there’s a small memory leak in libguile/posix.c? do_spawn appears to add posix_spawn file actions but never calls posix_spawn_file_actions_destroy to free them again (?) <dpk>i’m still new to posix_spawn (studying examples i know of) so maybe the destroy function isn’t actually needed, though <dpk>cc jpoiret who wrote that function ⬏ <dpk>yep, on Mac OS i can cause slowly but continually increasing memory usage by calling (waitpid (spawn ...)) in a loop from the REPL (whereas if i call e.g. cons in a loop, the garbage collector keeps the memory usage constant) <tohoyn>is it legal to have two variables with same name but different gensym in a single Tree-IL let expression? <nckx>weary-traveler: Only good friends. <old>is there a process for adding final srfi to guile? <old>I would like to have srfi-247 syntatic-monad. Is it just a matter of adding the reference implementation and tests? <apteryx>old: I've just sent patches in the past proposing to add them. I was very careful in crediting authors and complying with licenses. <apteryx>old: but the patches haven't generated much interest, based on the lack of review/merge in 9 months <apteryx>the script is not perfect, but with some (a bit painful, I must confess) debugging to fix anything missing/fix cycles, you might save some time. <old>Although a bit sad that there is no news on merging these .. <dpk>old: out of curiosity, what are you using syntactic monads for? <dpk>bear in mind many SRFIs are portable and you can just vendor the sample implementations into your project source tree <daviid>rlb: do you know if/where i could check if libffi, on debian testing, has been configured using the --disable-exec-static-tramp flag? <daviid>rlb: sorry to bother you, i can ask in #debian-next as well ofc <daviid>rlb: nvm, i got an answer in #debian-next <old>dpk: Right. I have not used it yet. But the other day I was writting some parser that needed to propagated states at various level. This quickly become cumbersome and difficult to refactor if the order of states or new ones are been added <old>dpk: I was thinking about something that could just propagated states without having to use parameters. Kind of like the *this* pointer in C++ that is implicit in class method <old>turns out, srfi-247 does just that in a nice way <old>see how most procedures require `elf' and `*-bias' arguments. Although they could all be passed as a single srfi-9 struct, I find the syntatic monad approch way more clean