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:
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))
>(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:
 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

Alternative 2: Use function-prefix notation.  Looks about the same:
if( a b
    c d

Alternative 3: Define a macro so that the pairing of condition
and result is embedded in a list.  Then you can use:
  a b
  c d

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  \

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
Readable-discuss mailing list

Reply via email to