> There's no need to completely dismiss sweet-expressions just because > you see SPLIT winning and dislike the consensus of the symbol being > used.
No, that isn't what I said. I articulated doubts that sweetexprs could be relevant, not because it doesn't do what I want, but because the space of wants is much larger than I realized. I'll investigate ENLIST further. But I'm skeptical that the answer is an additional syntax character. The problem is _not_ some lack of functionality. The problem, IMO, is that y'all are trying to do too much. You're trying to satisfy too many different camps of users, and you're over-constraining the problem for yourselves. Paradoxically, this might be easier as an actual language. A simple one, one that maps 1-1 to CL, scheme, etc. Don't just insert parens and move them around, mandate a specific syntax for if, let, etc. that is conducive to indent-sensitivity. Then port the translator to emit CL, scheme, all the dialects you want. Has this doing-too-much critique come up before? http://sourceforge.net/p/readable/wiki/Retort is just about indent-sensitivity in principle, not in the details. --- >> I understand now why we need to introduce GROUP, SPLIT, etc. But >> they're as alien to lisp noobs as parens and prefix. So why bother >> with sweetexprs? Parens/infix + GROUP/SPLIT seems strictly more >> cognitive load than just parens/infix. > > I agree. Drop the parens! (^^)v But you can't drop the parens, because you have to convert to them, you need them for macros. And because you care about compatibility. I think programming in a lisp requires awareness of the parens even if you could never see or type them. Do y'all agree? ------------------------------------------------------------------------------ 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
