Alan Manuel Gloria: > How about the cond-style if of Arc? > (if > (condition1) > (dothis1) > (condition2) > (dothis2) > (default)) > > I somehow suspect that Arc's dropping of extra parens here will be harder > on the swt-expr syntax, or alternatively make it look worse.
I'm sure there are _some_ things that are harder for ANY specific syntax. My goal is probably more like "best reasonable compromise for readability that is still general and homoiconic". Which isn't easy to measure, but oh well. That's why I've been collecting examples, to see if my current proposal "works"... and where it doesn't. The Arc tutorial: http://ycombinator.com/arc/tut.txt discusses this in a note at its end: >[1] Note to Lisp hackers: If you're used to the conventional Lisp >cond operator, this if amounts to the same thing, but with fewer >parentheses. E.g. >(cond (a b) > (c d) > (t e)) >becomes >(if a b > c d > e) >JMC's original cond didn't have implicit progn, so the parens around >each pair of clauses were unnecessary. They became necessary soon >after, however, when cond started to have implicit progn in the >first Lisp implementations.... Sweet-expressions handles traditional "cond" beautifully: cond a b c d t e But you're right, Arc's "if" is tricky. The problem is that Arc has hidden away semantic meaning in a specific operator, if. The 'if' operator works on pairs of operands, followed by the default value. A (reasonable) pretty-printer for Arc would have to have special knowledge about "if" to format it well, specifically because of this unstated additional information.. This is in contrast to "cond", where the pairing of the condition and expression is expressly included in the s-expression itself. Here are some alternatives that work with sweet-expressions: Alternative 1: Just use traditional Lisp syntax. Sweet-expressions are a superset of traditional syntax, so this is a valid s-expression AND a valid sweet-expression: (if a b c d e) Alternative 2: Use function-prefix notation. Looks about the same: if( a b c d e) Alternative 3: Define a macro so that the pairing of condition and result is embedded in a list. Then you can use: if* a b c d e You could argue that the last one is "cheating" (creating macros that work better with the surface syntax). But I think that's okay; other languages devise their operators to be easily used with the surface syntax, after all. And since macros work well with sweet-expressions, there's no need to avoid using them. My goal is to create easily-understood code; if macros + new syntax do that, then great. One possible syntactic addition would be a syntactic marker at the end of a line - or the beginning of the next one - that said "this is a line continuation". For example, several languages allow "\" at the end of the line to mean "continue line". (Where possible, I like to borrow existing constructs... it's easier for developers to learn them if they're familiar from somewhere else.) Adding that to sweet-expressions would allow this: if a b \ c d \ e Such a syntactic addition would eliminate this awkwardness pointed out by Arc's "if" and SMT-LIB's bignum_rd1.smt. Basically, sweet-expressions as currently described presume that while indentation processing happens, every line with an additional indent & more than one expression is its own list. This addition would disable that when necessary. Of course, it's not clear that it's _worth_ it. If it were just the "if" statement above, I'd say "use a macro". But the SMT-LIB example is more compelling; many languages (including Common Lisp!) allow repeated pairs of "atom_used_as_selector value" that aren't in their own lists, e.g.: (myfunc :parameter1 value1 :parameter2 value2) and with this syntax that could become: myfunc \ :parameter1 value1 \ :parameter2 value2 Of course, this would be really easy to misuse or make a mistake with. Accidentally omitting a "\" could be hard to find later. So - any thoughts? Is this worth it? Other suggestions, either with sweet-expressions, or using a completely different syntax? --- David A. Wheeler ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
