IRC channel logs


back to list of logs

***sneek_ is now known as sneek
***Fuuzetsu_ is now known as Fuuzetsu
***heroux_ is now known as heroux
***Fuuzetsu is now known as Guest65493
***Guest65493 is now known as Fuuzetsu
<dsmith>Hey hey
<taylanub>hidy ho
<taylanub>Anyone know why SRFI-26 doesn't support something like (cut + 1 (+ 1 <>)), i.e. having <> inside parenthesized subforms ?
<davexunit>taylanub: was wondering that myself a few days ago
<mark_weaver>taylanub: the reason SRFI-26 doesn't support <> within nested subforms is that, in general, macros cannot intelligently intepret the syntax of embedded subforms. macro expansion has to be done from the outside in.
<mark_weaver>for example, if one of the subforms uses SRFI-26 again, or binds '<>' as a local variable name, or uses some other macro that interprets <> in a different way, the outer 'cut' macro cannot determine that.
<taylanub>Hrm, the SRFI already limits each operand to be a <slot-or-expr>, perhaps the BNF for this nonterminal could be extended to be "<>" | <expr> | (<slot-or-expr> <slot-or-expr>*)
<taylanub>Or rather ...
<taylanub>(this'll take a couple minutes :P)
<taylanub> Something like this should work I think.
<taylanub>Well, the "rest-slot" is problematic there, but I think that can be fixed. (Perhaps it doesn't need to be fixed in BNF.)
<mark_weaver>fwiw, although I used to like SRFI-26, I see now that it's quite a limiting hack, and I don't use it much anymore.
<mark_weaver>another way to express lambda expressions more compactly is simply to rename 'lambda' to something shorter, like λ
<mark_weaver>or use an ascii character if you prefer
<mark_weaver>you can also do things like expanding (λx <body>) to (λ(x) body)
<mark_weaver>I like this better than cut.
<mark_weaver>here's an implementation of those ideas for Guile:
<taylanub>OK, I like that idea too.
<civodul>Hello Guilers!
<sneek>Welcome back civodul, you have 1 message.
<sneek>civodul, dsmith says: Have you been able to use guile-wm with a different $DISPLAY, like :1 ?
<mark_weaver>hi civodul! :)
<civodul>hey mark_weaver
<mark_weaver>I'm working on implementing for guile
<civodul>mark_weaver: ooh, excellent!
<civodul>that's certainly a useful extension
<mark_weaver>I've done everything except for 'write'.
<mark_weaver>the problem there is that the print state structure definition is public, and part of the API.
<civodul>ahah, reminds me of something
<civodul>you've cleaned up the reader options, now you'll have to do the write options ;-)
<mark_weaver>and 'write' needs to be changed to write into a string port that later gets modified before printing it out.
<mark_weaver>hi ijp!
<ijp>hi guys, good xmas?
<civodul>good, good
<mark_weaver>oh, every time I think of this mess of reader and writer options, it makes my head hurt.
<civodul>there was a paper about unified pretty-printer & parser...
<mark_weaver>I implemented 'set-port-read-option!' as part of my R7RS work, which is almost done btw.
<mark_weaver>the last piece is getting 'write' to print the correct syntax for circular data.
<mark_weaver>civodul: unified pretty-printer & parser? I'd be curious to see that paper.
<mark_weaver>civodul: btw, do you have any idea why (not (equal? #vu8(1 2 3) #u8(1 2 3))) in guile ?
<civodul>hmm, no
<mark_weaver>in the bytevector implementation VU8 and U8 are different "element types" for some reason. I'd be curious to know the reason.
<civodul>i don't even have the semantics of all that in mind
<civodul>hmm, i don't remember
<mark_weaver>#u8(1 2 3) is the SRFI-4 and R7RS lexical syntax for bytevector literals. R6RS instead uses #vu8(1 2 3)
<mark_weaver>all of our bytevector library functions return #vu8(...)
<civodul>initially these were disjoint types
<civodul>and i think wingo & i had a long argument as to whether they should remain disjoint
<civodul>something like that
<mark_weaver>interesting, I'd like to see that thread.
<ijp> is another interesting thing on the "unified print/read" front
<dsmith>Aww, civodul left.