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
