Comment on SRFI-110 and Comparison to Genyris xyzzy Bill Birch (22 May 2013 15:03 UTC)
Re: Comment on SRFI-110 and Comparison to Genyris xyzzy David A. Wheeler (23 May 2013 13:39 UTC)
sweet-expressions are not homoiconic John David Stone (23 May 2013 16:08 UTC)
Re: sweet-expressions are not homoiconic John Cowan (23 May 2013 16:19 UTC)
Re: sweet-expressions are not homoiconic John David Stone (23 May 2013 16:32 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 03:55 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 03:12 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 15:34 UTC)
Re: sweet-expressions are not homoiconic John Cowan (24 May 2013 20:02 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 20:09 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 21:35 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (24 May 2013 22:40 UTC)
Re: sweet-expressions are not homoiconic John David Stone (24 May 2013 23:13 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 03:43 UTC)
Re: sweet-expressions are not homoiconic John Cowan (25 May 2013 03:20 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 04:17 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 04:27 UTC)
Re: sweet-expressions are not homoiconic John Cowan (25 May 2013 04:55 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (25 May 2013 18:14 UTC)
Re: sweet-expressions are not homoiconic John David Stone (26 May 2013 23:26 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 00:29 UTC)
Re: sweet-expressions are not homoiconic John David Stone (27 May 2013 15:51 UTC)
Re: sweet-expressions are not homoiconic Alan Manuel Gloria (28 May 2013 04:28 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (28 May 2013 18:34 UTC)
Re: sweet-expressions are not homoiconic Beni Cherniavsky-Paskin (26 May 2013 20:40 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (26 May 2013 22:43 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 00:00 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 03:32 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 04:44 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 05:50 UTC)
Re: sweet-expressions are not homoiconic Alan Manuel Gloria (27 May 2013 06:34 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 15:14 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 13:55 UTC)
Re: sweet-expressions are not homoiconic Alexey Radul (27 May 2013 16:27 UTC)
Re: sweet-expressions are not homoiconic John Cowan (27 May 2013 15:55 UTC)
RE: sweet-expressions are not homoiconic Jos Koot (27 May 2013 04:57 UTC)
Re: sweet-expressions are not homoiconic David A. Wheeler (27 May 2013 13:37 UTC)
Re: sweet-expressions are not homoiconic John Cowan (27 May 2013 15:50 UTC)

Re: sweet-expressions are not homoiconic Alan Manuel Gloria 28 May 2013 04:28 UTC

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.