On Sun, Jul 1, 2012 at 2:24 AM, Arne Babenhauserheide <arne_...@web.de>wrote:
> > Do be aware that the \ splice thing is not yet officially part of
> > sweet-expressions; dwheeler made a draft of the splice rules but hasn't
> > made a 0.3 sweet-expressions spec including it.
>
> Do you mean the one here?
> - http://www.dwheeler.com/readable/sweet-expressions.html
>
> > - If it's the last character of the line (other than 0 or more
> > spaces/tabs), then the newline is considered a space, and the next
> > line's indentation is irrelevant. This continues the line. (Note
> > that comments cannot follow, because that would be confusing.)
>
> This sounds quite interesting, because it is a standard known to many
> people (from bash and python :) ).
>
> > - If it's between items on a line, it's interpreted as a line break to
> > the same indentation level.
>
> This sounds quite, though. It gives \ doublemeaning. And not being
> able to add comments behing the \ looks rather like trying to avoid
> making the ambiguity introduced by the inline \.
>
> I’m already not completely happy about using . for groups (because it
> introduces additional rules - but it already is a special syntax
> element, so it does not hurt too much).
>
> But at least in elisp, the following is valid syntax:
>
> (defun \ ()
> (message "\\"))
> (\ )
>
> This is not, though:
> (\).
>
> So I am pretty certain, that (defun \ () ()) just defines " " to be a
> function… though I’m not sure about that.
> (insert (stringp '(\ \ ))) complains that it is nil…
>
The reasoning is that symbols whose starting character is space are rarely
used enough (and are of otherwise dubious use) that we don't really mind
losing that particular meaning of "\ " (backslash space).
>
> Notes on that:
>
> http://ftp.gnu.org/old-gnu/Manuals/elisp-manual-21-2.8/html_node/elisp_22.html
>
> > - Otherwise, if it's at the beginning of a line (after 0+
> > spaces/tabs), it's ignored - but the first non-whitespace
> > character's indentation level is used.
>
> It allows making structure with whitespace which is not interpreted by
> the parser. And I think that makes it ambigous.
>
> > For now I think we should investigate the following alternatives:
> >
> > 1. \ = GROUP = SPLICE, remove SPLICE-at-the-eol rule.
> >
> > 2. . = GROUP, \ = SPLICE
> > 2.1. remove SPLICE-at-the-eol rule.
> > 2.2. don't remove SPLICE-at-the-eol rule.
>
> or:
> 2.3 remove SPLICE inline rule
>
>
That may be NG. The reason for the SPLICE-at-the-start and SPLICE-inline
rules is to support the following Arc syntax, and CL keywords:
(if
(cond1)
(exp1)
(cond2)
(exp2)
(exp-else))
(foo
:foo-stuff (exp1)
:bar-stuff (exp2))
By the SPLICE-at-the-start and SPLICE-inline rules, we can express it as:
if
..(cond1)
..\ (exp1)
..(cond2)
..\ (exp2)
..\ (exp-else)
foo
..:foo-stuff \ (exp1)
..:bar-stuff \ (exp2)
In addition, the SPLICE-at-the-start and SPLICE-inline rules work well as
transformations of each other:
if
..(cond1) \ (exp1)
..(cond2) \ (exp2)
..\ (exp-else)
foo
..:foo-stuff
..\ (exp1)
..:bar-stuff
..\ (exp2)
So I think removing SPLICE-inline is less useful than removing
SPLICE-at-the-eol.
We could propose using a different character, but which character do we
expect to be used rarely?
(my original proposal was just the SPLICE-at-the-start, and used the symbol
->, but dwheeler felt that -> would be commonly used in current code. He
also pointed out that just SPLICE-at-the-start would make code too long
vertically, especially if the keyworded expression was short, and so added
SPLICE-inline)
Sincerely,
AmkG
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
