Alan Manuel Gloria asked: > > How about the cond-style if of Arc? > > (if > > (condition1) > > (dothis1) > > (condition2) > > (dothis2) > > (default))

Sweet-expressions _can_ handle this, in several ways, but I agree that they aren't optimal. The format doesn't help show "hidden" pairings inside a list. Clearly, it'd be possible to add or modify syntax to better handle cases where you'd like multiple lines to be spliced together to permit "hidden" structures inside a list of items. Both Arc and SMT-LIB show cases where you'd like to have spliced pairs (e.g., condition/result or attribute_name/values). But any such mechanism would need to be simple. Allowing "\" at the end of the line to mean "continue line" is at least simple. That wouldn't cover all use cases, though. A problem with the simple "splice line" approach is that it doesn't handle spliced-in pairs where at least one of the pairs is so complex that you'd like to keep using normal indentation processing inside them. But I haven't been able to think of a syntax that neatly handles this case, and is simple enough to be worth the trouble. This message has 3 ideas (below) - maybe someone here can think of something better? Let's start with 2 concrete cases, based on Arc's "if" and SMT-LIB's labelled-parameters (which are quite similar to Common Lisps's, so the latter is hardly an unknown case): (if a (b (xxxxxxx yyyyyyy zzzzzzz) (xxxxxxx yyyyyyy zzzzzzz)) c d (e (xxxxxxx yyyyyyy zzzzzzz) (xxxxxxx yyyyyyy zzzzzzz)) (f (xxxxxxx yyyyyyy zzzzzzz) (xxxxxxx yyyyyyy zzzzzzz)) g h i) (f :parameter1 value-for-1-that-is-really-long :parameter2 (xxxxxxx yyyyyyy zzzzzzz (q r z)) :parameter3 value-for-3-that-is-really-long) First, the "obvious" representation in sweet-expressions is: if a b xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz c d e xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz f xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz g h i f(:parameter1 value-for-1-that-is-really-long :parameter2 xxxxxxx(yyyyyyy zzzzzzz q(r z)) :parameter3 value-for-3-that-is-really-long) Notice that on the "if", the format does not even HINT that there is a pairing, e.g., for g and h. Also, in "parameter2"'s value we can't use indentation any more to express structure... we're back to parens. So we can use (...) to disable indentation processing, but then we completely lose indentation processing inside it. Adding support for "\" to disable indentation processing can help the attributename-value stuff, as long as it's short, but otherwise it doesn't help much in these examples (I CHOSE these examples to thwart this idea, so that's expected): if a b xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz c \ d e xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz f xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz g \ h i f(:parameter1 value-for-1-that-is-really-long \ :parameter2 xxxxxxx(yyyyyyy zzzzzzz q(r z)) \ :parameter3 value-for-3-that-is-really-long) Here are three approaches, all of which are bad :-). APPROACH 1: One approach would be to add some sort of "splicing" operator for lines, when performing indentation processing. There's precedence in Lisp for this, of course; "," typically inserts the value into a list, but ",@" splices it in. So it's understandable that there might need to be some sort of 'splicing' operator. Let's call it "@@", though "splice", "ungroup" (opposite of "group"), or other names are possible. Basically, this operator would cause the line to be spliced into its parent, INSTEAD of becoming a new sublist. If there are children, then presumably they are children of the last-named expression. E.G., perhaps something like this: if @@ a b xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz @@ c d e xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz f xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz @@ g h i f(:parameter1 value-for-1-that-is-really-long @@ :parameter2 xxxxxxx yyyyyyy zzzzzzz q(r z) @@ :parameter3 value-for-3-that-is-really-long) This would mean that: if @@ a b 1 2 3 @@ c 4 5 6 @@ d 7 8 9 @@ e Would become (if a (b 1 2 3) (c 4 5 6) Right now, I think that such a "splicing" operator would be WAY too complicated. But maybe someone can come up with a variant that is simpler to understand (or, convince everyone that it's not so bad). APPROACH 2: Maybe what's needed is an infix "splicing" operator that you place BETWEEN items, saying that these items will be spliced into the larger list enclosing them (instead of creating their own list). You'll need a way to escape this (ugh), but ignoring that problem, let's see how that looks (if "@@" is used with nothing before it, it's ignored): if a @@ b xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz c @@ d e xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz @@ f xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz g @@ h i f :parameter1 value-for-1-that-is-really-long :parameter2 @@ xxxxxxx yyyyyyy zzzzzzz q(r z) :parameter3 @@ value-for-3-that-is-really-long APPROACH 3: A more radical approach would be a different version of sweet-expressions that didn't disable indentation processing when it encounters "(", but DID allow you to add "\" at the end to combine lines (effectively disabling indentation processing for the NEXT line). Such a version would not be backwards-compatible with existing sweet-expressions, which is REALLY unfortunate. That doesn't even seem to help much: if a \ b xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz c \ d e xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz f xxxxxxx yyyyyyy zzzzzzz xxxxxxx yyyyyyy zzzzzzz g \ h i f(:parameter1 value-for-1-that-is-really-long \ :parameter2 xxxxxxx(yyyyyyy zzzzzzz q(r z)) \ :parameter3 value-for-3-that-is-really-long) I think this particular approach is a train wreck trying to happen; it's way too easy to misplace backquotes, and I don't think it helps much. Thoughts? --- 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