<ijp>that isn't one of nils holm's is it? <DeeEff>daviid: is there an html pack of the updated version Sketchy-Scheme? <ijp>I recall he went in a huff some years back over a german law, and stopped maintaing his stuff <daviid>DeeEff: i don't know, but as an intro for no programmer, the html version i mentionned here is fine <DeeEff>as a funny aside, I searched for the book through my university library, and one of the results to come up was "Men and masculinities in South India" <ijp>the structure and interpretation of indian societies <ijp>weird, I'm trying to experiment with cps terms at the repl, and when I write function foo in (guile-user) it fails to give the correct answer on pattern matches, but if I write it in (language cps) (through ,m) it works fine <ijp>ah, I see the problem, PEBCAK <ijp>I have a binding for $ which is obviously not free-identifier=? to the one match uses ***petercom1and is now known as petercommand
<lloda>why do assoc and assoc-ref take their arguments in different orders? this is mad :-/ <nalaginrut>lloda: that's my question too...but it's impossible to change it now... <saul>Is there a Guile implementation of SRFI-115? (or similar) <nalaginrut>saul: for now, you have to use irregex, I do so in my project <nalaginrut>civodul: is anyone working on srfi-115 for Guile? ;-) <taylanub>lloda: nalaginrut: assoc-ref is in the -ref family which take their arguments in the order 'collection, key/index', whereas assoc descends from older Lisps and has (I think) always taken arguments of the order 'key, alist' <taylanub>also looks like assoc-ref isn't in SRFI-1 <nalaginrut>another potential portable issue, although trivial <dje42>civodul: question: Do you know much about guile 2.2's "finalizer thread" ? <civodul>dje42: i know the principle, that it's a thread that runs the finalizers :-) <nalaginrut>considering Artanis uses irregex heavily, it's reasonable for me to think about it... <dje42>Heh. My question is whether one is able to disable it, or more generally <dje42>whether guile will provide a "no internal threads" mode. <dje42>*I* don't want it, but some in gdb-land do. <nalaginrut>I think you're requesting a (disable-threads) on the fly <civodul>dje42: i think eli was concerned about what *users* may do with threads, no about what Guile/libgc do internally <dje42>I think the concern is threads in general. <civodul>and i think that requiring users to configure libgc + guile --without-threads is unreasonable <dje42>Though one can disable libgc threads with GC_MARKERS [IIUC]. <civodul>i think the way forward is to document the fact that threads in gdb user code are not supported <civodul>and then make sure that, if there are threads for internal use, they don't mess up with gdb <civodul>which i think you've achieved already, no? <taylanub>late correction: yesterday I mentioned the "Ritchie hack"; apparently the correct name is "Thompson hack". I seem to have replicated a mistake someone made on the ML <dje42>I kinda don't want to be in the position of having said that when power users know what they're doing and will happily use threads anyway. <civodul>dje42: the only way to completely forbid threads would be by requiring (provided? 'threads) => #f at configure time, but we don't want that <civodul>so AFAICS, the only thing we can do is to say "don't do that" <civodul>i mean, it's probably similar with Python, isn't it? <dje42>The python docs are too silent on the matter. <dje42>All it says is it's hard to make file descriptors close-on-exec in a thread safe manner. <lloda>(string->number "-0.8 ") -> #f <lloda>isn't that a bit too strict?! <taylanub>lloda: wouldn't say so .. you could use `read' for that. <civodul>if -0.8 were a number, we would know <civodul>oh, i hadn't noticed the trailing whitespace <civodul>lloda: per "(r5rs) Lexical structure", this is correct *dsmith-work is in *way* too early <ijp>waxysubs`: I added tail patterns enough for srfi 64, but I see the r6rs also has <ijp>(<pattern> ... <pattern> <ellipsis> <pattern> ... . <pattern>), and AFAICT that's ambiguous in general <ijp>and where it isn't, I suspect you need to backtrack <waxysubs`>ijp: I think it's not actually ambiguous, because if you look carefully at the description of that pattern type in R6RS-lib, it says that the final tail pattern must match the "nth and final cdr", i.e. the final cdr must not itself be a pair. <waxysubs`>i.e. the nth cdr must not be a pair, is what I mean. <waxysubs`>so you know exactly how many list items must be matched by the part after <ellipsis>. <waxysubs`>(note that for the other pattern type involving a tail pattern, with no <ellipsis>, it merely says "the nth cdr", as opposed to "the nth and final cdr") <ijp>I see, then this is my own mistake <ijp>this also removes the backtracking objection <ijp>waxysubs`: good news, all I had to do was 1) get rid of the listp check 2) change length to safe-length, and 3) change the tail-pattern-p predicate <davexunit>hey guilers, trying to brainstorm how to write a macro. <davexunit>I want to identify expressions that are a particular type of object. <davexunit>and then wrap that expression in another form when the matched expression is substituted with something else. <davexunit>so if I had (+ 1 foo), and foo was the special object, the result would be something like (lambda (foo) (+ 1 foo)) <davexunit>I'm explaining this horribly. need to get things straight in my own head before I talk more. <civodul>maybe it's something that cannot be done at macro-expansion time <civodul>because there's insufficient info on whether 'foo' is the special object <davexunit>I guess I can just introduce a quote/unquote thing instead <davexunit>but it would still be hard to identify a subexpression as quoted and then expand the parent expression <civodul>maybe you need to come up with a reduced case