***jonsger1 is now known as jonsger
<dsmith>sneek: later tell R1ck77 The channel is often slow. Just wait a day or two... ***jonsger1 is now known as jonsger
<dsmith>sneek: later tell R1ck77 Use free() <RhodiumToad>wklew: it's easy to show that the reset is evaluated before any shift. <RhodiumToad>my first guess is that the storing of the first forced result of the evaluation of the stream is itself part of the continuation at this point. <RhodiumToad>similar thing happens with delay/force from srfi-45 (can't do it with builtin delay/force because force isn't rewindable) <wklew>RhodiumToad: ahh that complicates things <wklew>I think storing thunks in the stream will be the cleanest solution <wklew>otherwise I'd have to rewrite all the streaming functions to reset each element anyway <wklew>for sure! been spending a lot of time with oleg's papers and such <wklew>I'm trying to translate his ocaml library for probabilistic programming to guile *RhodiumToad also read their stuff on shift/reset when learning about it <RhodiumToad>not to mention the whole business of finding a ~20-year-old bug in their code ***sputny1 is now known as sputny
<RhodiumToad>a system-call trace will probably make it pretty obvious what the problem is. <rlb>RhodiumToad: heh, not (yet) obvious to me, but thanks for the suggestion. ***catonano_ is now known as catonano
<wklew>RhodiumToad: now I'm curious what/where the bug was <RhodiumToad>rlb's bug? I don't know, I haven't see the trace :-) <wklew>no sorry, we were speaking of oleg's code <RhodiumToad>a misreading of the spec which results in corrupted data <RhodiumToad>and I don't think the xml people anticipated that anyone could misread it in that specific wrong way, so there is no test for it in the xml validation suite ***sneek_ is now known as sneek
***apteryx is now known as Guest83291
***apteryx_ is now known as apteryx
***bjoli is now known as manumanumanu
<sneek>Welcome back manumanumanu, you have 1 message! <sneek>manumanumanu, wklew says: cool, that's interesting too! <manumanumanu>So, does anyone know of any newer research into optimizing pattern matchers than Balland 2006? I am finally writing an optimizing extensible pattern matcher, and I think i have most of it nailed down. <manumanumanu>I believe I can leave out a lot of the work their pattern matching optimizer does, since guile already does constant propagation, inlining and let fusion... I suspect it will be a _lot_ more simple to do in guile than in SML <manumanumanu>hmmm. the problem when writing a pattern matcher is that you want a pattern matcher <leoprikler>Instant pattern matcher, just call another pattern matcher ;) <leoprikler>Balland et al. refers to "Optimizing pattern matching compilation by program transformation", right? <mwette>I'm adding an option to Guile's configure.ac, how do I get an associated variable defined in config.h.in? <mwette>leoprikler: Thanks. Found it I think. <manumanumanu>leoprikler: yes! I am not in academia or anything, but to me it seems like the latest and greatest in pattern matching compilation. <leoprikler>Well, to be fair, it's not cited by a great number of other papers, so there have probably been little improvements since. <manumanumanu>I actually found that the common lisp pattern matcher trivia uses it, and that produces excellent output. I haven't been able to make it produce worse-than-hand-tuned for most of my cases. For simple cases like ((a b 2 d e) ...) (a b 3 d e) ...) the code is a lot better than what (ice-9 match) produces. With all the work the guile optimizer does, I doubt we can actually do much better than the suggested <manumanumanu>Balland, since we can just leave all the really hard parts to guile <manumanumanu>On a similar note, does anyone know of any predicate-based generic method library that plays well with modules? (i.e: a method defined in module a should not be visible in module b unless it is explicitly imported) <manumanumanu>It removes the possibility to specialize types, but I suspect it could be a lot simpler (and faster?) than, say, goops if all you want is simple generics that play well with regular records <justin_smith>manumanumanu: I briefly played with the idea of using a lambda closing over a hash table, accepting "message" based dispatch, eg. a message #:extend to add a dispatch target, a message #:invoke to send a dispatchable value to a target, etc. <justin_smith>also explicitly lacking the ability to magically wrap any external or built in function or do meta level mainpulations <justin_smith>but I doubt it's a unique idea and hope somebody else made it and I can just use their lib <manumanumanu>justin_smith: well, did that work well with the module system? Otherwise, I would probably just use chibi's implementation. That is elegant enough. <justin_smith>manumanumanu: I only played with it briefly and don't have a version I'm happy with yet - I'll look at chibi's version <justin_smith>manumanumanu: the difference between my approach and chibi's is that chibi does linear lookup which allows "next method" / arbitrary predicates, and mine was a single dispatch function with a hash - speed vs. inheritance <justin_smith>mine would respect modules, as it generates a function belonging to a single module, just because you extend it doesn't mean it belongs to you <manumanumanu>But if you have a method named banana in module a, extend it in module b, then import module a in module c, which banana is visible in module a? <justin_smith>the method is a lambda belonging to the module that defines it, you can make a special call to add a dispatch key and function for that key, but that doesn't affect its visibility or ownership <justin_smith>the reason it isn't done is not being satisfied with the conventions for calling it, which I want to have first before writing code that relies on it <justin_smith>but I expect the final code to be smaller than the amount I've written about it in this channel so far, I am aiming quite low <manumanumanu>I don't understand, but please ping me if you ever finish it :D