support other types of brackets, like square brackets.

Title: support other types of brackets, like square brackets.
ID: 6749f3abcb9455eac9271efd8265797bce114239
*Resolved* Owned By: Arne Babenhauserheide 
Filed On: Tuesday, January 07 2014 11:35PM

[details]
Needed: 

- square brackets for RSR6 and 
- curly braces for curly-infix.

Both should simply disable wisp-parsing inside them.

[comments]
Discussion: 

 does it need to support square brackets?
 (foo [bar 5])?
 well, R6RS mandates that [] are equivalent to ().
 but of course, you are inventing a new syntax, so it's up to you.
 then I’ll have to add support for that, I think.
 IMO, it would be good to support SRFI-105 curly-infix notation.
 wisp is just a preprocessor to regular scheme-code, so pasting any valid scheme in beween should work.
 well, specifically, I think you should pass anything between curly braces unchanged.
 just as you do with parens, I guess.
 yes
<-- fangism (~davidfang@209.119.54.132) hat das Netzwerk verlassen (Remote host closed the connection)
 curly infix can be combined with datum labels too, so you can have #0={...}
 that should still work as soon as I have curly braces.
 and of course, expressions delimited by curly braces can span multiple lines.
 so actually it boils down to treating parens, square brackets and curly braces in the same way (but they can be nested).
 almos the same… 
 almost
 (foo [bar {5 + 6 ] }) ← nasty syntax error?
 yes
 can you see any cases where this would not be a syntax error?
 no
 then I could just treat parens, brackets and braces as abstract delimiters and not worry about the difference… 
 But I worry that such a simplification could break badly
 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.
 ouch… 
 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
 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.
 I guess that’s true… 
 it's not practical to get it exactly right without somehow integrating it into guile's native reader.
 (though the version written in wisp is a good deal more versatile than the bootstrap version in python ☺)
 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.
 for that matter, guile's reader is also extensible.

---

- all bugs -