>> Why not just myfunction(:option1 f(a), :option2 g(b), :option3 h(c))? >> Or is there an issue with commas? > > Yes, comma means unquote. In addition, comma-whitespace is used in > indentation processing to mean that the inner expression of the > unquote is also processed using indentation processing. So: > > ` foo bar > . nitz quux > . , meow > . . . cat fish > > ==> > > `(foo bar > nitz quux > ,(meow > (cat fish)))
That seems *really* complicated. I didn't see reference to this 'escape hatch' in all my readings. Is this somehow deduced from the three rules, or from the new proposals for v0.3? Have y'all considered just not supporting indentation inside backquote? That was my choice in wart. I reasoned thus: if s-expressions exist to enable macros it's reasonable for macros to make them explicit. Macros can get pretty hairy, so the less magic they involve, the better. The value proposition: familiar syntax in the common case, but drop down to s-expressions when you need macros. If you got rid of backquote support, then commas would be freed up, and I'd just be able to write: myfunction(:option1 f(a), :option2 g(b), :option3 h(c)) And as a result I wouldn't need to mess with backslash as much. I *love* keyword args, I think they're hugely underused. Contortions with backslash will only dampen their uptake. ------------------------------------------------------------------------------ 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
