***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
<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>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>you can also do things like expanding (λx <body>) to (λ(x) body) <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>the problem there is that the print state structure definition is public, and part of the API. <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>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 ? <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 <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>and i think wingo & i had a long argument as to whether they should remain disjoint