Alan Manuel Gloria:
> Should we be mentioning sweet-expressions at this stage? The
> t-expressions specs are still on the burner.
I think it's okay as a *rationale*. We're not saying what the semantics of
sweet-expressions are, we're just saying that there is a use case where they
are useful.
> I imagine that the (. foo) escape can be put in the t-expressions SRFI.
Yes, but I think it's important to do it this way:
- It greatly simplifies implementing sweet-expressions, or any other system
needing escapes, on top. I can easily envision someone implementing
n-expressions but not t-expressions. If there's an n-expression reader with (.
e), and unread-char, you can *easily* implement sweet-expressions on top.
- It's easy to include with neoteric-expressions, since you're mucking with the
meaning of (...) anyway
- It's harder to argue that (. e) is part of sweet-expressions.
Sweet-expressions are all about indentation processing; once "(" begins, you're
no longer really doing sweet-expressions until its matching ")".
So I think it's important that (. e) be part of *neoteric* expressions.
> The "bracketaccess" rule allows the implementation of functions to access
> items as arrays or other objects. Also, an application might define
> "bracketaccess" using SRFI-17 Generalized set! to support syntax like "(set!
> str[x] #\a)".
Good point. Added.
> Oh, and I hereby put the above text in the public domain so that you can
> remain the sole author ^^
Nuts to that. You've been too much help! I've put you on the author list
anyway. Feel free to remove your name if you'd prefer it that way.
--- David A. Wheeler
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/readable-discuss
