IRC channel logs

2014-01-24.log

back to list of logs

<nalaginrut>morning guilers~
<nalaginrut>I'm writing my filter scripts for procmail, but I realized I need a email-module to handle the mail, of course it's guile scripts
<adhoc>procmail FTW
<adhoc>although these days getting your email to your server is a little harder =/
<nalaginrut>for gmail account, it's useless I think
<nalaginrut>but I have other accounts
<adhoc>as gmail "improves" its become less useful.
<adhoc>they finally stopped supporting various browers i use
***linas_ is now known as linas
<zRecursive>noon
<mark_weaver>midnight!
<zacts>hello
<civodul>Hello Guilers!
<mark_weaver>Hi civodul!
<nalaginrut>heya
<mark_weaver>I'm porting SRFI-64 to Guile.
<nalaginrut>IIRC there is one?
<civodul>hey mark_weaver
<civodul>excellent!
<mark_weaver>it passes most of the test suite at this point, just a few stubborn bugs.
<mark_weaver>nalaginrut: huh?
<civodul>oh you're starting anew?
<civodul>there are copies in Guix and other projects, and nalaginrut had started something too
<mark_weaver>no, I'm fixing the reference implementation to work with guile-2.
<nalaginrut>mark_weaver: https://gitorious.org/srfi-64-port/srfi-64-guile/source/a576303318d98bb1cb5491147642fd4c4dc2a761:
<mark_weaver>it actually had several bugs. lots of cond-expands in there, and some of the cases are just broken, including some of the 'else' cases.
<nalaginrut>no, it's not mine
<nalaginrut>ah
<civodul>mark_weaver: it would be ideal if the reference implementation could be kept intact and just 'include'd
*nalaginrut never test it
<civodul>but you seem to imply that it's not viable, right?
<mark_weaver>right
<mark_weaver>I did include it, and that was my initial hope, but it's just broken.
<mark_weaver>nalaginrut: thanks for the pointer.
<nalaginrut>hah~I'm glad you have reviewed it ;-P
<mark_weaver>well, looks like he got past the bug I'm currently struggling with.
<mark_weaver>also, even if it was possible, there would be missing functionality.
<nalaginrut>it's better if you're willing to do it
<nalaginrut>I believe your TODO is near overflow like mine
*nalaginrut still has many issue to solve today..
<mark_weaver>hmm, I cloned that repo, and the actual ported srfi-64 code is missing.
<nalaginrut>your code is lost?
<mark_weaver>no, my code is not lost. sunjoong's srfi-64 code is not actually in there.
<mark_weaver>there's a nice version of the test-suite that's been ported to guile's (test-suite lib).
<mark_weaver>and there's a stub srfi-64.scm that includes the actual implementation in srfi/srfi-64/srfi-64-port.scm, but that latter file is not in the repo.
<mark_weaver>there's just an empty srfi/srfi-64 directory.
<nalaginrut>hmm...
<mark_weaver>maybe he forgot "git add" ?
<nalaginrut>dunno
<nalaginrut>BTW, do you use Guile for procmail?
<mark_weaver>oh, looks like it's in a git submodule.
<mark_weaver>no, I don't. I use exim's built-in mail filtering stuff mostly, combined with some shell scripts that call spamassassin and clamav.
<mark_weaver>I set all of this up before I got interested in Guile.
<nalaginrut>well, so I can't borrow your Guile email parser then ;-/
<nalaginrut>I'd write it myself, seems Artanis needs it too...
<ft>I thought the GNU mailutils had guile bindings
<ft>But I might be mistaken.
<mark_weaver>okay, I got sunjoong's srfi-64 code now.
<nalaginrut>ft: any opened repo ? ;-)
<nalaginrut>oh, I thought you write it
<nalaginrut>mark_weaver: I think 1+ is not standard primitive, right?
<mark_weaver>no, it's not.
<mark_weaver>even the lexical syntax is not a legal symbol in portable scheme.
<ft>nalaginrut: http://git.savannah.gnu.org/cgit/mailutils.git
<mark_weaver>ah, it seems sunjoong started with a newer version of the reference implementation than I did, for starters.f
<ft>nalaginrut: I'm pretty sure it's bindings to the C parts of mailutils rather than an email parser in pure scheme.
<mark_weaver>I took the one referenced from srfi.schemers.org, but I guess there's a newer one with some bugs fixed.
<mark_weaver>well, I'll have to put this hack down for now. time for sleep.
<nalaginrut>alright, maybe write it in pure Scheme is better
<taylanub>IMO (+ 1 x) looks nicer than (1+ x), is standard, and is optimized in Guile to the latter anyway.
<mark_weaver>taylanub++
<mark_weaver>and don't even get me started on '1-'. terrible, confusing name.
<mark_weaver>sussman called it '-1+', which at least makes sense.
<taylanub>Indeed. On the other hand (- (something slightly long) 1) isn't very nice, and (+ -1 x) also kind of weird IMO, so one is left wishing for better there, though it's just one of those minor annoyances really.
<mark_weaver>#!curly-infix {(something slightly long) - 1}
<taylanub>I guess one can always just define `decr' or so if they find themselves needing that often.
<taylanub>Ah, that too :)
<mark_weaver>there's also (+ x -1)
<mark_weaver>but yeah, I still don't actually use curly-infix in my code.
<mark_weaver>even though I think it would look nice in some places.
<b4283>mark_weaver: nice, didn't know about the #! notation
<mark_weaver>you only have to put it somewhere at the top of the file, not immediately before an expression.
<mark_weaver>it enables the curly-infix notation in the reader for the rest of that file.
<mark_weaver>it's SRFI-105, btw, which has been in the last two releases of Guile.
<b4283>cool, it's on the manual 7.5.37
<b4283>oh, i see, it introduced the originally unused curly-braces to indicate infix orders
<b4283>(#!curly-infix { (x) lambda (+ 1 x) } 2) ;; hehehe
<mark_weaver>abuse!
<mark_weaver>:)
<mark_weaver>anyway.. must sleep. happy hacking!
*mark_weaver --> zzz
<b4283>good night
<b4283>actually the usage kinda make sense if you look at "lambda" as a operator
<b4283>which links left hand side, the argument names, with the right hand side, the body
<civodul>ft: Mailutils has Guile bindings indeed
<lloda>i have a package with 324 uses of '(1- ' and 271 uses of '(1+
<lloda>). Now I feel bad.
<civodul>why feel bad?
<civodul>because it decrements more than it increments? :-)
<nalaginrut>hmm
<taylanub>civodul: We talked about the (partly subjective) disadvantages of 1+ and 1- above.
<lloda>I agree that the names are awful, but the functions are useful.
<civodul>oh right, i had overlooked it
<civodul>the names are useful when used as an argument to higher-order functions
<civodul>(map 1+ lst) rather than (map (cut + 1 <>) lst)
<civodul>but yeah, the fact that they violate R5 syntax rules sucks
<nalaginrut>well, I like 1+
*nalaginrut flee..
<lloda>I'd be up for inc & dec, or even ++ and --
<taylanub>In mathematics it's the "successor" function and not "increment" but I guess that doesn't abbreviate well and has no obvious counterpart like decrement.
<lloda>predecessor
<lloda>also bad abbrv, of course
<taylanub>I'd be for inc/dec, but maybe "dec" (and "inc" too?) has potential of naming other things too so expecting them in Scheme base wouldn't be right. ++ and -- are something from the C world and would be out-of-place IMO (not to mention differing semantics). I guess it's best to expect people to define these themselves after all.
<taylanub>Really good topic for bikeshedding. :P
<taylanub>lloda: BTW see the ML for Mark's proposal of using ^ for quick lambdas, e.g. (^x (+ x 1))
<taylanub>More general than cut, and up to three args or so it's not even longer or less readable: (^xyz ...) is (lambda (x y z) ...). You can define arbitrarily long ones like e.g. (define-syntax ^abcdefgh short-lambda), and it won't ever be longer than `cut' in total because for every <> (two chars) you have one char in the arg list and one char in the body. :P But I guess it gets messy.
<lloda>looks useful, b/c I use cut a lot.
<lloda>shorter still would be something like J tacit definitions, or Forth, where you don't even name the arguments.
<lloda>(not even name, meaning not even a placeholder)
<lloda>the option of having <1>, <2>, etc has its appeal b/c you save the declaration...
<cky>lloda: I also implemented a Clojure-style reader macro so you can write ##(foo %1 bar %2 baz %&) (and it nests, too), just for more variety of options: https://gist.github.com/cky/8500450
<cky>so that's pretty close to having <1>, <2>, etc.
***Guest71489 is now known as aburgess
<cky>(%& is analogous to <...> in cut)
<cky>although in the reader macro you can put it anywhere, not just at the end.
<civodul>oh, fun
<cky>civodul: Yes, I had a lot of fun writing it. :-)
<cky>(Its correct operation depends on internal definitions having letrec* semantics, so it's not R5RS-compliant. ;-) But it seems to be the case for Guile, since it works when I tested it.)
<cky>Thankfully R6RS and R7RS specifies letrec* semantics for internal definitions.
<lloda>cky: do you have an example of using this with nesting?
<taylanub>lloda: (map ##(compose ##(+ 1 %1) %1) some-procedures) I presume
<taylanub>Which means I guess that the inner one can't use the args of the outer one, though.
<taylanub>I'd say that would be quite an abuse anyway .. I'm personally fond of the ^ variants, retaining names for arguments alleviates all sorts of problems and short names aren't worse than %n or <n> or so IMO, and cases where you have more than three args should be exceedingly rare.
<lloda>taylanub: would that be (map (^p (^x (+ 1 (p x)))) some-procedures) ? it's a good example then
<taylanub>No need to take out `compose'; it would be (map (^p (compose (^x +1 x) p)) some-procedures). This is 1 character longer than the ## variant BTW. :P
<lloda>well you *need* compose for the ##() right? since you can't use p inside. That's the comparison.
<lloda>b/c I think it's good to have both approaches available.
<taylanub>Oh, indeed, I didn't even realize. :P
***`micro is now known as Guest56559
<lloda>shouldn't pk be transparent to values? wdyt? it's for debugging after all.
<civodul>in what sense?
<civodul>the semantics is to return its last argument
<civodul>and by definition, there's only one last argument, so one return value, no? :-)
<lloda>well the idea of pk is that you look in the middle of the program, right? but don't affect it.
<lloda>but if you put pk in (pk (values 3 4)), you won't get (values 3 4) on the other side.
<lloda>semantics etc. I agree, it's just that pk isn't useful there...
<civodul>but one never writes literally (pk (values x y))
<lloda>(pk (some-function-that-returns-multiple-values ...))
<lloda>or rather
<lloda>(multiple-value-taker (pk (multiple-value-giver ...)))
<lloda>right, that wouldn't work.
<lloda>what I had is (receive (...) (multiple-value-giver ...) ...)
<lloda>that's where I tried pk.
***mario-go` is now known as mario-goulart
<dsmith-work>Happy Friday, Guilers!!
<taylanub>Happy Friday!
<taylanub>I suppose `pk' could made to be syntax (if it isn't already) so it can handle MV returns.
<taylanub> http://sprunge.us/aWBA maybe ?
<lloda>needs to end with (apply values values_) or
<lloda>a test: (receive (a b) (values 3 4) (vector a b))
<lloda>vs: (receive (a b) (pk (values 3 4)) (vector a b))
<taylanub>Oh, silly me
<taylanub>Yeah, the superfluous `apply' calls aren't optimized out but they won't hurt during debugging: http://sprunge.us/USUX
*taylanub checks how current pk is defined ..
<lloda>looks good, thanks
<lloda>yeah for debugging it's not a problem
<taylanub>Didn't manage to replace the `peek' in boot-9 with that one, missing `call-with-values' or something there I guess.
<Sleep_Walker>sorry for this stupid question, but how can I have expresion returning boolean false? (#f), ('#f) doesn't work for me...
<lloda>just #f
<lloda>don't apply it
<Sleep_Walker>aha
<Sleep_Walker>yes, thanks
<mark_weaver>parentheses in scheme are not for grouping. each pair of parens implies a procedure call (or macro use).
<mark_weaver>x is different than (x) which is different than ((x))
<Sleep_Walker>yes
<Sleep_Walker>and how would be array with single element - boolean false?
<lloda>#(#f)
<lloda>or #0(#f) ;p
<mark_weaver>lists, vectors, and arrays are all different things.
<mark_weaver>if you mean a list, then '(#f) is an immutable literal list with one element: #f
<mark_weaver>if you want to freshly allocate a mutable list, then (list #f)
<Sleep_Walker>right
<mark_weaver>for vectors, '#(#f) is immutable, (vector #f) is mutable.
<Sleep_Walker>thanks :)
<lloda>in Guile, all vectors are also arrays, though
<mark_weaver>(although we don't currently enforce the immutability of most literals in guile 2.0)
<mark_weaver>right, arrays are a higher-level concept
<mark_weaver>I guess I should mention that the "'" at the beginning is not really part of the data, but rather part of the expression that means that what follows should be interpreted as literal data, and not as an expression.
<mark_weaver>so for example, a literal list of three singleton lists, each containing #f, would be written '((#f) (#f) (#f)), not '('(#f) '(#f) '(#f))
<mark_weaver>you could put the "'" in front of any literal data, such as '1 or '#f, but for convenience some types of data, such a numbers and booleans, are "self-quoting".
<mark_weaver>but this is probably too much information :)
<Sleep_Walker>mark_weaver: with "'" it makes more sense to me, thanks