On 5/27/13, John David Stone <xxxxxx@cs.grinnell.edu> wrote:
>         On the other hand, there is nothing about the \\ and $ symbols that
> represents the corresponding syntactic structures

For $:

  (|  <--- open parenthesis
   |) <--- close parenthesis

foo $ bar nitz
===>
foo (bar nitz) <-- see the open and close parenthesis?

xref: http://www.mail-archive.com/xxxxxx@lists.sourceforge.net/msg00404.html

For \\, what I really wanted was a curving arrow coming from above and
pointing to the right.  I thought that \ would at least do that.

xref: http://www.mail-archive.com/xxxxxx@lists.sourceforge.net/msg00329.html

and I quote:

===BEGIN
1.  The first use case:

let
. \
. . foo bar()

looks like a line pointing to the lower left - which is where the
next, more-indented line is.  Neither ! nor ~ point correctly, so
neither is as visually appealing:

<elided>

2.  The second use case:

:keyword
\ multi item expr

looks kinda like I wanted to draw an arrow like this:

:keyword
|
+--> multi item expr

in order to show the "pairing"

<elided>

3.  The third use case:

arf() \ meow()

In this case, the \ looks almost like a vertical line.

<elided>

4.  The fourth use case:

define quuux()
. 42
\
\
{quux() * quuux()}

Now, it is kinda like a vertical line that points downward, to where
the next sub-expression goes.  Again, ! beats it here:

<elided>

===END

(refer to the xref'ed message for full details - basically this was a
debate on how to spell GROUP/SPLIT.  \ won.  dwheeler made it into \\,
which means it wasn't my fault (^.^;)v).

>, and indeed \\ is used in
> two completely different ways, depending on context.  It even has two
> different names, GROUP and SPLIT, as if to emphasize the impossibility of
> making the same symbol serve as an icon for two unlike syntactic
> operations.

GROUP and SPLIT are made the same because of the following reversible
transformation:

foo
  :keyword \\ expression x ; SPLIT
<====>
foo
  :keyword
  \\ expression x ; GROUP

see?

So you could do:

foo
  :key1 \\ trivial value
  :key2 \\ trivial value
  :key3
  \\ some not-so
       trival value
       and yet another
         trivial value

see?

>
>         Sweet-expressions also undermine the (slight but reliable) iconic
> status of some of Scheme's existing marker symbols (quote, quasiquote, and
> unquote), making them context-dependent.  (For the record: quote is
> somewhat iconic because its form suggests a half-barrier, allowing parsing
> to proceed but blocking evaluation.  Quasiquote and unquote are slightly
> iconic because unquote is an inverted quasiquote character, and its effect
> is to undo the effect of the quasiquote.)  All depend for their iconicity
> on
> their immediate juxtaposition to the form to which they are attached.  This
> attachment is lost in sweet-expressions.

Hmm?  If they are "attached" to some n-expression (as in, not have any
whitespace between the quote and the n-expression, their meaning is
*exactly the same* as in s-expressions.  We only have a divergent
meaning if the quote has whitespace between it and the next
n-expression, and arguably it's not "attached' anymore, there being a
whitespace an' all.