IRC channel logs
2023-01-31.log
back to list of logs
<mwette>I think in base 1 you only have 0: (0 + 0) + 0 = 0 + (0 + 0), 0 + 0 = 0 + 0, 0*(0 + 0) = 0*0 + 0*0, 0*0 = 0 <mfiano>CL's unwind-protect is what we use for this. It guarantees that the cleanup form will be run once, after all computation of the continuation, and always, regardless of how it exits. <mfiano>This is an implementation of that in portable Scheme. <mfiano>It would be nicer if it were implemented with Guile's delimited continuations, if any brave soul wants to fix that :) <mfiano>Well maybe not. I guess you really only need dynamic-wind for this. <old>so the ok? and error are there to prevent double cleanup? <old>In other words, it's preventing entering the dynamic-wind twice <mfiano>I haven't fully understood it all yet. But the author's history in the second link makes sense. <mfiano>And also makes sense why I was misled by Kent for a long time. <mfiano>The (error) should be an impossible case anyway. There is no path to it. <mfiano>The ok? is to know when the computation is finished I think. <mfiano>I am not sure. I have to read more about Scheme dynamic bindings. <mfiano>I don't want to answer incorrectly due to the CL taint in my brain still. <mfiano>And, I used the "bad word". Oops. <mfiano>I mean, the long term effects of CL semantics in my memory :) <cow_2001>some exercises in sicp are rather mathy. i suck at math. <old>the (error) is executed if for example you restart the computation <old>That is you catch the exception but decide to not unwind the stack and restart the computation <old>cow_2001: Practice makes improvement :-) <mfiano>I just had a chance to try the different variations of that unwind-protect macro. The unwind.sch file behaves exactly as I would expect it to behave in a conforming CL implementation. I'm now happy I can write safe code that uses external resources. <mfiano>And with that, I'm off for the night o/ <mfiano>By the way, this operator was the only missing prerequisite to implement the CL condition system as a library. That would make for an interesting integration bridge module for goops, if one wanted advanced control flow. Maybe some other time :) <civodul>ACTION has been compiling Guile on emulated RISC-V for ~10h <dadinn>quick question about (ice-9 regex): I am trying to use non-capturing groups to parse version strings: "([0-9]+)(?:\\.([0-9]+))?(?:\\.([0-9]+))?(?:-(.*))?" <dadinn>I am getting an error when trying to parse "5.10.0-32-amd64" <dadinn>it seems non-capturing groups are not supported? <dadinn>I am not sure, but I think I've been recommended to use PEG instead... am I correct that non-capturing groups are not supported with regex? <dadinn>I've actually thought it's easier to just use regex "([0-9]+)(\\.[0-9]+)?(\\.[0-9]+)?(-.*)?", and truncate the dots/hyphens from the 2nd, 3rd, 4th matched groups. <dadinn>but might bite the bullet, and get into this PEG parsing! :D <old>I want it to be transparent for users <antipode>That only works if the user imports 'parallel' though. It's not completely transparent. <antipode>I think we need to rename Guile's 'dynamic-wind' to 'primitive-dynamic-wind', and let 'dynamic-wind' use some '%dynamic-wind-implementation' parameter or such, to be 100% transparent. <ArneBab>rendar: guile *is* a Schepe interpreter and JIT-compiler. <dsmith-work>dadinn: Yeah, Guile uses the system C library for regexps. They are not PCRE. <mfiano>That is actually very nice. This Sitarum character I never heard of before yesterday keeps on showing up all of a sudden with high quality portable Scheme code implementations. <mfiano>I am such a newbie, but they must be popular <drakonis>he wrote teach yourself scheme in fixnum days <drakonis>that and an embedding of prolog-style logic programming in lisp <mfiano>I am on their site now. I had recently only heard of them from the link from yesterday that was the answer to two weeks of me scouring the nety <mfiano>Without unwind-protect, you can't really write safe code, and Scheme/Guile doesn't have it builtin <mfiano>Safe as in correctly handling external resources <mfiano>Not as a dedicated operator. You have to roll your own with dynamic-wind, or I heard it's also possible to do it in Guile or (eventually) r7rs-large with _delimited_ continuations. <mfiano>The implementation is so simple though, that I'm considering proposing its addition as a patch on bug-guile <mfiano>I tested this and it behaves exactly as you would expect a conforming CL implementation to <mfiano>I think I'll write a blog post about all this history I discovered and where it leads me in Guile (if patch is accepted or I have to use my own utility macro in every project etc) <mfiano>And I just want to make one thing clear now though <mfiano>THis is not a "I want to bring CL with me" problem. This construct, whatever it be called, is important in any language. It is required to implement a Java-style try/finally block for example. If you want to guarantee some cleanup form be evaluated, regardless of how something exited (error or success), you use this for safely doing so. <drakonis>it'd be silly to see it as that when there's always room to improve things <drakonis>that said, i don't think anyone would say no to that <mfiano>Unfortunate mostly because Kent's article is total FUD and has been the source of my knowledge for a long time. Kent fell for the joke they provoked him with. <mfiano>I mean, he designed the condition system. <mfiano>By the way, unwind-protect is the only thing you need to start implementing the entire CL condition system as a library. <mfiano>Guile has everything else already <drakonis>having the whole thing on guile would be truly amazing. <drakonis>then proceeding to use it to reimplement emacs would be even more amazing lol <mfiano>let's not go from seed to solving world hunger <drakonis>it is all too easy to joke about it and then get excited about the whole idea <drakonis>i have a particular use case for the condition system on guile though <drakonis>because i'm very very tired of yaml munging <lilyp>So, I understand that the semantics of unwind-protect are useful and all, but why settle for a particular one when implementing one with the exact semantics you need isn't too hard? <mfiano>Having a general purpose one that works when you need it is also good imo <lilyp>If it's for instance required for CL conditions, you could very well include those five lines at the top and export or not export the syntax based on what the requirements for the bigger system are <mfiano>lilyp: That form is useful on its own in a lot of isolated places in everyday code. Including that macro in every project is not such a big deal, and neither is custom tailoring one for the project, but it also can be avoided with the simple general solution included as either a single form guile module, or included in the implementation itself. <mfiano>I hope that makes sense. Additionally, the "how do i ensure a cleanup form is evaluated" question was raised by dadinn last week, and by me a couple months ago. It took me a week to find the solution after I was reminded of it. If Guile users are asking for a way to do this, it seems only natural to either include such 5 lines in Guile, or maybe just the inclusion of guile-foo, where foo is <mfiano>something more schemey than unwind-protect, is all we need to point new users to. <mfiano>guile-foo in guix or something i mean <lilyp>"If Guile users are asking" is sadly not a great benchmark here, because Guile users are often also asking for things that are already mentioned in the manual ;) <mfiano>I am not ready to make my argument yet in any case. It's just important to me that I be able to write safe code that handles resources easily, and be able to point people to guile idioms. Without guile endorsement or widespread use/documentation, I might as well just tell them to write it themselves, which is quite dissuading to a newbie <lilyp>Now I'm not arguing that some version of unwind-protect couldn't be shipped as part of (ice-9 exceptions), GOOPS or even just our emacs language, but rather saying that it makes sense to try and understand the Scheme primitives already included on top of which these features can be built. <mfiano>lilyp: I fully agree with that last statement <lilyp>I think for many, the call-with-port we currently have – even if it doesn't close-port on the exceptional case – is probably enough. <mfiano>It's hard to say what people would use without an alternative <mfiano>But yeah, I'm not arguing at all about higher order constructs like the call-with-port procs <mfiano>I think those are useful to most people as is <mfiano>or stuff that could be implemented differently with u-p <mfiano>Nah, I just want to give guile users a solution to the more strict case, so they can build their own of these higher constructs, without requiring them to write the low level control flow here themselves. <mfiano>But, I will shut up now, because I am not yet of the Guile hivemind :) <chrislck>is there anything in guile's gc that can call a destructor before cleaning up? <chrislck>(define (f x) (let ((obj (make-object))) ... #true [*]) where [*] would call (destructor-object obj) before returning #true <mfiano>Sounds like you are asking about finalizers, but I can't be sure. <mfiano>If that is the case, read 5.5.4 of the manual, particularly the part about trying to avoid them. I fully agree with this... <chrislck>mfiano: hmm... or guardians. is there some code I can read to learn how to use? <oenone>just wanted to have a look at the Guile homepage... is gnu.org down?