<kurohin>where am I supposed to look? when I have quiestions like "i wonder if there is a C function I can call that will load module for me?" where is the API documentation? <mark_weaver>kurohin: it's in the guile manual: API Reference > Modules <kurohin>thanks, was looking at headers and they did not include any information about what functions does. <mark_weaver>kurohin: if you view the guile manual within emacs' info mode, you can just type "i scm_c_use_module RET" and it will look it up in the index and bring you right there. <mark_weaver>the standalone info reader probably has something similar if you're allergic to emacs :) <mark_weaver>I should mention that from C you don't normally need to load modules explicitly. You can just use 'scm_c_public_ref' to lookup bindings from an arbitrary module, and it will load the module automatically if needed. ***banannagram is now known as bananagram
<lloda>match doesn't work with arrays of rank > 1 either. And the same is true for quasiquoting, it doesn't work for uniform vectors or arrays of rank > 1. <civodul>it matches only plain R5RS types + records <mark_weaver>unknown_lamer: the problem with matching uniform vectors is that you can't give a pattern like #vu8(a b c) because of course a uniform vector can't hold symbols. <mark_weaver>so there would have to be some other pattern syntax for that. <mark_weaver>lloda, unknown_lamer: if you have a suggested syntax in mind for dealing with this, let us know. <mark_weaver>non-uniform arrays of rank > 1 could be supported, of course. patches welcome. <unknown_lamer>array-FOO works on *all* array like objects in guile, but it would require modifying the upstream match code to use array-FOO instead of vector-FOO <unknown_lamer>I only had to have ugly code in one place, so I'm punting for the time being <lloda>For match I think it would be enough to have the value #vu8(1 2 3) be a match for the pattern #(a b c). <mark_weaver>lloda: the problem with that is that users of match will reasonably assume that if #(a b c) matches, then they can assume it's a standard (non-uniform) vector. <mark_weaver>making #(a b c) now match all kinds of uniform vectors and arrays will violate that assumption. <mark_weaver>the overwhelming majority of code will assume that they can use 'vector-ref' on something that matches #(...) <mark_weaver>maybe we should have a separate 'array-match' macro. <civodul>Racket and most FPLs use the constructor name in patterns <mark_weaver>though I'm not sure if we should modify the standard 'match' macro from (ice-9 match) to do this. what do you think? <mark_weaver>there's a danger that some code uses a constructor name as a identifier to be bound. <mark_weaver>unlikely with most constructor names, but I could easily imagine someone using 'vector' as a variable name. <DerGuteMoritz>how about a new pattern type for matching constructors, e.g. (@ cons a b)? <DerGuteMoritz>not backwards compatible either, but less collision surface at least <mark_weaver>well, I guess it would be ($ <array> a b c) actually. in GOOPS, arrays that aren't vectors have class <array> <mark_weaver>I could go either way on '$' vs '@'. maybe we should move the discussion to guile-devel. wdyt? <civodul>mark_weaver: that would be for a different pattern matcher <civodul>but yeah, definitely an interesting project <civodul>we should see whether Racket's pattern matcher can be ported <mark_weaver>civodul: what do you think of extending the existing pattern matcher to support uniform vectors or arrays, by either using a special 'struct' type name in the '$' syntax, or adding a '@' syntax for constructors like (@ cons a b) ? <mark_weaver>by "special 'struct' type names", I mean special names to match things like uniform vectors and arrays. <civodul>the problem is that we're downstream for (ice-9 match) <civodul>so perhaps it'd be good to discuss it with Alex Shinn <mark_weaver>although it should be noted that we could do this without changing the upstream matcher at all. <mark_weaver>all we'd have to do is give it special variants of the structure accessors <mark_weaver>such that uniform vectors and arrays look like structs to the matcher. <civodul>i think it directly emits struct-ref when matching structs <civodul>so i'm not sure you could really make arrays look like structs <mark_weaver>it could be done, but admittedly it would be a bit of a hack :) <mark_weaver>someone other than me should probably talk to him though. Alex and I are on rather bad terms, because of our fights during the R7RS process. <DerGuteMoritz>mark_weaver: sure, I'm not on the Guile MLs but maybe you can post here when you find a solution! ***fangism is now known as fangism-nomming
***fangism-nomming is now known as fangism
<wingo>civodul: wdyt about a 2.1.0 in a week or so? <wingo>i should be able to get the manual and the NEWS into shape by then <civodul>wingo: if it's good for you, it's good for me :-) <civodul>i don't think i can handle the release process by then, though <wingo>yeah i am ignorant as far as that process goes <civodul>perhaps that's what you were asking for? :-) <civodul>if it's a bit later that should be doable <civodul>OTOH "a bit later" means xmas and all that <wingo>well i'll try to get the hydra all green, maybe that will take a little longer <wingo>will have to poke the coverage build again, dunno what is up with that <wingo>anyway, if the delay gave me time to get local binding names in that wouldn't be terrible <civodul>so you would be OK to delay a bit, that's what you're saying? <wingo>i'll probably be mostly off the net over christmas, fwiw <wingo>man, the new texinfo is slow <civodul>BTW, mark_weaver was also pushing for 2.0.10, which is indeed overdue IMO <wingo>makes sense to me -- NEWS would be a first step, if you or mark_weaver or someone wants to poke that <wingo>i don't have much 2.0 bandwidth *wingo needs to fix the $ktrunc thing, documenting it is silly <wingo>documentation has a way of forcing changes like that ;) <wingo>it's really a $kreceive -- to receive the results of a call <wingo>civodul: the "$ktrunc" thing is that cps shouldn't implicitly truncate multiple-value returns <wingo>truncation should be explicit -- if a rest argument is present but unused, then you have truncation <civodul>so $ktrunc checks at run time whether truncation needs to happen? <wingo>and thus our cps transformation should introduce more instances of explicit truncation, instead of relying on fuzzy implicit behavior <mark_weaver>right. at the low level, there should not be implicit truncation. <wingo>civodul: currently $ktrunc always truncates <mark_weaver>truncation should be the result of single-valued continuations being of the type (lambda (x . _) ...) <mark_weaver>it should be possible to create continuations that do not truncate. <mark_weaver>I'm terrible at picking names. I'll leave it to your best judgment :) <wingo>buf, my best judgment isn't very good ;) <wingo>so lacking a global optimizer, we do simulated annealing i guess :) <mark_weaver>I guess $kreceive sounds about right to me, but my knowledge of the details of our CPS repressentation is a bit rusty now, so maybe that's not quite right, dunno. <civodul>ISTR that samth said that automatic truncation is Evil