IRC channel logs
2025-01-22.log
back to list of logs
<whereiseveryone>> The (hoot match) module provides a match form that supports a subset of what Guile’s (ice-9 match) can do. <whereiseveryone>Why was a subset needed or created? Just interested in understanding the its reason for existing. <dthompson>whereiseveryone: because (ice-9 match) is further down the chain in terms of dependencies. we wanted a simple match that we can use in modules closer to the root. <dthompson>for example, (ice-9 match) can destructure records but we wanted a match that could be used before records are usable <dthompson>thanks tsyesika! I was going to post a reminder here but forgot <whereiseveryone>> but we wanted a match that could be used before records are usable <whereiseveryone>Can you give a bit more context on why records are not usable in the context in which they are not usable. I'm not following on why there is the limitation. Thanks <whereiseveryone>By root you mean the root of Guile, spritely, something else? What is a root in this context? I know about roots from music, keys, and tonality, for example :) <dthompson>whereiseveryone: the root of the module graph in hoot <dthompson>to get to a working scheme system, you start with some primitives that you take for granted. this is (hoot primitives), the root of the module graph. <dthompson>from there you build up everything else. in that graph, records are somewhere in the middle <dthompson>(hoot match) exists to give us a simple pattern matcher that can be used early in the boot process <cwebber>and I don't just mean the office hours <tsyesika>spritely office hours are happening now! <dckc>"Weak key hashtables have been reimplemented ... and are now iterable" <- that hurts my brain. being non-iterable is sort of an important feature of weak maps, no? <dckc>in the "Get Hoot 0.6.0!" box, the text is invisible here. black-on-black or something <dckc>I can see it if I select it <dckc>"build instructions, can be found here." <- avoid here links plz. (IOU a pull request maybe) <dckc>missed office hours again. whimper. <dthompson>dckc: re: iterable weakmaps, for better or worse guile has them and goblins uses them so hoot needs them. <dpk>are they still ephemeron tables or only weak-keyed now? <dckc>dthompson, goblins needs them to be enumerable? <dckc>(re-reading) ah. yes. you said so <dckc>non-iterable weakmaps are handy for rights amplification where the can is the weakmap and the can-opener is the key <dthompson>dpk: there's no ephemeron api exposed in js so we just did the best with what WeakRef and FinalizationRegistry allow us to do. there's weak key, weak value, and doubly weak tables. any weak element is wrapped in a weak ref. finalizers help prune dead pairs to help control size. <dthompson>to me a non-iterable hashtable is an attenuation of an iteratable hashtable api in a sufficiently safe runtime <dpk>so it sounds like you changed from ephemeron-keyed tables (which is what a JS weakmap is) to weak-keyed tables. that’s a semantic change and should probably be documented <dpk>also the REPL still doesn’t run on Safari (on iOS, my Mac is still on its way back from repair so i can’t test there). :-( when my Mac gets back, i’ll see what the web inspector says there and if there’s a bug i could file <dthompson>ah, bummer. would be interesting to know what's up with it. <dthompson>dpk: the intention was always to provide what guile provides so no doc change necessary <dthompson>the interface was always weak-key-hashtable-ref, etc.