Kartik Agaram: > > https://sourceforge.net/p/readable/wiki/Solution/ > > "A leading quote, comma, backquote, or comma-at, followed by space or tab, > > is a list with that operator and the following expression." > > > > Of course, if you think that's a bad idea, then let's discuss! This is > > straight from SRFI-49.. > > It's not this rule in particular, but the spec as a whole seems quite complex. > http://www.dwheeler.com/readable/version02.html is quite > long, and it includes this wormhole to the universe of SRFI 49...
The spec is (currently) at: https://sourceforge.net/p/readable/wiki/Solution/ I think you're looking at the wrong file. The version02.html file is obsolete; that's mainly useful if you want to see historically where we came from. > It might be a useful exercise to inline SRFI's rules into v0.3 and > try to organize them to be shorter and simpler. ... > v0.2 tries to be both a tutorial and a spec, and I think > that makes it too intimidating. Lose the motivation, assume that the > reader is already on board by the time (s)he gets to that page, etc., etc. I agree, it's important to separate things out. But I thought they were. The "Solution" page here just gives the spec: https://sourceforge.net/p/readable/wiki/Solution/ The tutorial *is* separate. It does give a recap on the motivation and spec, since people might just jump to it, but I hope it does that adequately: https://sourceforge.net/p/readable/wiki/Tutorial/ Maybe "Solution" is the wrong page name? > GROUP doesn't seem worth the extra complexity required to explain it > to others. If you have a list with a nested list as its first > element.. just add parens. We don't need alternate syntax for every > possible situation. Here, I disagree, GROUP is critically important (unless you have a better alternative!). Clearly, under the current semantic you could just use (...) for a nested list of lists. When the list-of-lists has little internal structure, that's probably a good approach. But since (...) *DISABLES* indentation processing in the current semantic, you lose all indentation support for internal structure if you use (...) to notate a list-of-lists. Yet this kind of construct shows up a lot, e.g., in "let" and "cond". So having a marker (like GROUP) to be able to represent arbitrary groups of groups is very valuable. Now granted, you could change things to support indentation processing inside (...). But that creates *massive* backwards incompatibilities with traditional S-expression syntax. Also, "indentation is disabled by (...)" turns out to be a really simple rule to explain & get used to. --- 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
