2014-01-11: bug on brackets/bracses: details from a discussion in #guile

bug on brackets/bracses: details from a discussion in #guile

diff --git a/.bugs/details/6749f3abcb9455eac9271efd8265797bce114239.txt b/.bugs/details/6749f3abcb9455eac9271efd8265797bce114239.txt
--- a/.bugs/details/6749f3abcb9455eac9271efd8265797bce114239.txt
+++ b/.bugs/details/6749f3abcb9455eac9271efd8265797bce114239.txt
@@ -29,3 +29,38 @@ Both should simply disable wisp-parsing 
 
 [comments]
 # Comments and updates - leave your name
+Discussion: 
+
+<ArneBab_> does it need to support square brackets?
+<ArneBab_> (foo [bar 5])?
+<mark_weaver> well, R6RS mandates that [] are equivalent to ().
+<mark_weaver> but of course, you are inventing a new syntax, so it's up to you.
+<ArneBab_> then I’ll have to add support for that, I think.
+<mark_weaver> IMO, it would be good to support SRFI-105 curly-infix notation.
+<ArneBab_> wisp is just a preprocessor to regular scheme-code, so pasting any valid scheme in beween should work.
+<mark_weaver> well, specifically, I think you should pass anything between curly braces unchanged.
+<mark_weaver> just as you do with parens, I guess.
+<ArneBab_> yes
+<-- fangism (~davidfang@209.119.54.132) hat das Netzwerk verlassen (Remote host closed the connection)
+<mark_weaver> curly infix can be combined with datum labels too, so you can have #0={...}
+<ArneBab_> that should still work as soon as I have curly braces.
+<mark_weaver> and of course, expressions delimited by curly braces can span multiple lines.
+<ArneBab_> so actually it boils down to treating parens, square brackets and curly braces in the same way (but they can be nested).
+<ArneBab_> almos the same… 
+<ArneBab_> almost
+<ArneBab_> (foo [bar {5 + 6 ] }) ← nasty syntax error?
+<mark_weaver> yes
+<ArneBab_> can you see any cases where this would not be a syntax error?
+<mark_weaver> no
+<ArneBab_> then I could just treat parens, brackets and braces as abstract delimiters and not worry about the difference… 
+<ArneBab_> But I worry that such a simplification could break badly
+<mark_weaver> well, if curly-infix mode is not enabled in the reader (and it's off by default), then '{' and '}' are not delimiters and can be part of unescaped symbols.
+<ArneBab_> ouch… 
+<mark_weaver> but curly-infix mode is turned on automatically if "#!curly-infix" is present in the file.
+--> int3__ (~int3__@175.156.240.23) hat #guile betreten
+<mark_weaver> but I wouldn't worry too much about edge cases like this.  I think it's likely that your reader has a number of other problems with edge cases like this.
+<ArneBab_> I guess that’s true… 
+<mark_weaver> it's not practical to get it exactly right without somehow integrating it into guile's native reader.
+<ArneBab_> (though the version written in wisp is a good deal more versatile than the bootstrap version in python ☺)
+<mark_weaver> you'd have to exactly match the detailed syntax understood by guile's reader, which is a moving target and has some complex nooks and crannies.
+<mark_weaver> for that matter, guile's reader is also extensible.