Alpheus Madsen: > I think it's abuse (putting the let on the first line makes it difficult to > see), but I see no reason why it should be forbidden, except in style > guidelines. Indeed, there may even be situations where it's the preferred > idiom...
I do have a style guide up. Hopefully we can say more as we gain experience. > I do have a question, though: > Is "\\" implemented so that it would be possible to do this? > let > ! \\ var1 $ bar x > ! ! var2 $ quux x > ! nitz var1 var2 > > If not, I still think it would be a good idea to extend the > implementation to be able to do this; it makes the block a little more > compact, and a little more readable. I'd also expect that it wouldn't > be too difficult to implement. No. We talked about doing stuff like this, but after long discussion we decided on a defined semantic that means that "\\" is an empty symbol, making that expression exactly the same as: > let > ! var1 $ bar x > ! ! var2 $ quux x > ! nitz var1 var2 which isn't what you want in this specific case. But we did this intentionally. It turns out that there are situations where you want a \\ as an empty symbol, even when stuff follows it on the line. An example is arc if-then-else, where there are *logically* pairs of items, but from a *list* semantic are at the same level. E.G.: if ! condition1() ! \\ action1() ! condition2() ! \\ action2() ! \\ otherwise-action() It's easy to handle let* with an extra line, but there's no easy way to insert a short pseudo-comment character in the front unless we do it this way. The multi-line nature of let* turns out to be not a real problem, for 2 reasons. 1. It turns out that in many "let*s" the variable settings can be put on one line. The "sweeten.sscm" has 305 non-blank, non-comment lines as determined by: grep -v '^$' sweeten.sscm | grep -v '^ *;' | wc -l Of those, 13 lines use let or let*, and only one of those "lets" uses \\. 2. Using the abbreviations as intended is REALLY clear, even though it uses an extra vertical line: let* ! \\ ! ! var1 ... ! ! var2 ... ! do-in-the-let() So the savings for let* aren't significant, the semantics as designed are clear, and are intentionally using that notation for ANOTHER purpose where it's not as easy to use an alternative. It's a good question. I'll update the rationale. --- 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 Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
