IRC channel logs


back to list of logs

<nalaginrut>morning guilers~
<kurohin>good morning
<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?
<nalaginrut>kurohin: try scm_c_public_lookup
<mark_weaver>kurohin: it's in the guile manual: API Reference > Modules
<mark_weaver>I guess 'scm_c_use_module' might be what you want.
<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 :)
<kurohin>I live in emacs.
<mark_weaver>kurohin: excellent :)
<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.
<kurohin>ok, will check it out
***banannagram is now known as bananagram
<civodul>Hello Guilers!
<unknown_lamer>grr, match hates uniform vectors
<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
<dsmith-work>Hey hey
<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>same problem with quasiquotation.
<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>mark_weaver: #(...)
<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
<civodul>like (match foo ((cons x y) ...))
<civodul>that would be the ideal thing IMO
<mark_weaver>sounds good to me.
<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>I like that!
<DerGuteMoritz>I can make a special price for a friend!
<mark_weaver>heh :)
<mark_weaver>civodul: what do you think?
<DerGuteMoritz>it seems similar to the $ pattern in Wright's matcher
<DerGuteMoritz>except maybe a bit more generic
<mark_weaver>hmm, or maybe we should just reuse '$'
<mark_weaver>($ array a b c)
<DerGuteMoritz>might be a valid approach ...
<DerGuteMoritz>it could be ambiguous though
<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) ?
<civodul>($ <array> x y z) sounds nice
<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
<civodul>that's what we did for records
<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.
<mark_weaver>well, still, it would be good to talk to him.
<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.
<mark_weaver>(which got rather ugly)
<DerGuteMoritz>mark_weaver: sure, I'm not on the Guile MLs but maybe you can post here when you find a solution!
<DerGuteMoritz>sorry to hear you guys are on bad terms :-(
<mark_weaver>will do
<mark_weaver>hi jemarch!
***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 :-)
<wingo>cool :)
<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? :-)
<wingo>heh, yes :)
<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>heh, ok
<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>yeah, me too
<wingo>makeinfo, rather
<civodul>sorry for not being more available
<wingo>not a prob
<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
<civodul>of course
<mark_weaver>I can spend a bunch of time on it.
<wingo>yay :)
*wingo needs to fix the $ktrunc thing, documenting it is silly
<mark_weaver>sounds good!
<wingo>documentation has a way of forcing changes like that ;)
<wingo>maybe tomorrow
<wingo>it's really a $kreceive -- to receive the results of a call
<wingo>$kreturn sounds a bit wrong
<wingo>maybe $kcall or so
<wingo>names are hard :)
<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
<wingo>that's the problem :)
<civodul>heh, ok
<mark_weaver>truncation should be the result of single-valued continuations being of the type (lambda (x . _) ...)
<wingo>mark_weaver: indeed
<mark_weaver>it should be possible to create continuations that do not truncate.
<wingo>$kcall, i guess
<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