At Mon, 9 Jul 2012 06:20:00 +0800,
Alan Manuel Gloria wrote:
>
> On Mon, Jul 9, 2012 at 3:17 AM, David A. Wheeler <dwhee...@dwheeler.com>
> wrote:
> > I think we need to seriously discuss all the splicing/grouping/etc. stuff.
> > Those decisions will affect everything else, and there are complex
> > trade-offs. One challenge is that practically any character or character
> > pair seems to be already used by someone.
> >
> >
> >> proposal 3:
> >>
> >> 3. . = SPLICE = GROUP, remove SPLICE-at-the-eol rule (this helps
> >> justify removing the SPLICE-at-the-eol: since \ at the eol has an
> >> existing meaning in other languages, we avoid it. Incidentally, "."
> >> has a meaning in general western written languages: it ends sentences.
> >> So we could justify using it to mean "end the expression so far and
> >> start a new expression", which is one interpretation of the
> >> SPLICE-inline rule.)
> > So I don't like the idea of "." as "splice"; I think it's too confusing.
>
> Okay, so what symbol should we use as splice/group? Candidates
I also think that . is not suited to the infix-splitting.
At least in emacs lisp it would be suitable as intenting prefix, though - even
without additional parsing, since (equal (. "a") "a").
So in elisp, we could rewrite this
(if
(cond1)
(exp1)
(cond2)
(exp2)
(exp-else))
to this
(if
(cond1)
(. (exp1))
(cond2)
(. (exp2))
(. (exp-else)))
Which could be rewritten as
if
cond1
.
exp1
cond2
.
exp2
.
exp-else
With . as prefix, this would become
if
cond1
. exp1
cond2
. exp2
. exp-else
Which would be very close to (equal (. t) t)
Alternatively the exact representation could be used:
if
cond1
. (exp1)
cont2
. (exp2)
. (exp-else)
On the other hand, I think that just trying to reduce the number of
lines is not really important. It is always possible to use brackets,
after all, and brackets are not always a bad thing.
As strange as it may sound, I think that this version actually looks
clearer than the one without the brackets…
Direct use of brackets would be this:
A third alternative for doing this indenting would be direct use of brackets:
if
cond1
(
exp1)
cont2
(
exp2)(
exp-else)
But I think this looks rather strange…
For EOL it’s possible to just use the “standard” \, followed
directly by a linebreak (that’s almost universally used for breaking
shell commands, so most people should already be familiar with it).
> >
> >> let
> >> .
> >> a b
> >> c d
> >> e
> >
> > This one doesn't look bad; claiming that "." on a line by itself as a
> > special case seems plausible. I'm still worried that "." is too hard to
> > see, but it *is* plausible as a "group" marker.
>
> Yes, but particular specifications of SPLICE make SPLICE-by-itself act
> in the same manner as a "group" marker like the above - so I'd rather
> merge their meanings to reduce the number of special syntaxes that we
> need to spec out.
>
> In short, SPLICE-by-itself should just "drop out" of the rules for
> SPLICE-inline and SPLICE-at-the-start.
So an elisp code using all of this could look like the following:
let
.
a 1
b 2
if
= a 1
. (message "true")
. (message "false")
The corresponding elisp code would be:
(let
(
(a 1)
(b 2))
(if
(= a 1)
(. (message "true"))
(. (message "false"))))
Without the indenter, it would look like this:
let
.
a 1
b 2
if
= a 1
message "true"
message "false"
That way “. (…)” would be a way to set some functions calls apart from others.
I do not know if this would be valid in other lisps, though.
Guile Scheme would be:
(let
(
(a 1)
(b 2))
(if
(= a 1)
(. (display "true"))
(. (display "false"))))
And this works, too.
So yes, this would be a hack on the language (because it already
allows using . this way), but I somehow like that. It minimizes the
changes from regular lisp and only uses syntax elements which already
have a special meaning in lisp - though not at the point where they
are used.
a . b → construct a cons-cel
a
.
b → create a double bracket
. (b) → pure syntactic sugar to give the code a stronger structure.
As a departure from normal sweet parsing rules, “. (…)”¸ could retain the
indenting rules - different from direct use of brackets. So
if
cond1
. (exp1
subexp)
would correspond to
(if
(cond1)
(. (exp1
(subexp))
))
Which es equivalent to
(if
(cond1)
(exp1
(subexp)))
and
if
cond1
exp1
subexp
-- for comparision again:
if
cond1
. (exp1
subexp)
if
cond1
. exp1
subexp
… I’m not sure if I am blinded by the nice hack represented by . (…).
The form without the brackets could be cleaner, but I can’t really
judge that objectively right now.
let
.
a 1
b 2
if
= a 1
. message "true"
. message "false"
If this is cleaner, the form would be:
a . b → construct a cons-cel
a
.
b → do a double bracket
. b → pure syntactic sugar to give the code a stronger structure.
With this, there would be only six syntax elements:
()"',.
And () could be omitted, so the required syntax elements in sweet expressions
would be
"',.\n
Adding \ for linebreaks would stay consistent with bash.
Or just use . there, too, to join lines, just as it joins cons-cels:
a . b → construct a cons-cel
a
.
b → do a double bracket
a .
b → ignore a linebreak,
. b → pure syntactic sugar to give the code a stronger structure.
What is missing is splitting lines, because that would definitely
conflict with constructing the cons-cel.
So alternate: The adding dot:
a . b → construct a cons-cel
a
.
b → do a double bracket
. b → pure syntactic sugar to give the code a stronger structure.
And the splitting and unbreaking backslash:
a \ b → split a line in two
a \
b → avoid a linebreak.
Though this is somewhat strange, because only removing the linebreak
in the second case gives
a \ b → (a) (b)
while the correct form would be
a b → (a b)
With the dot to avoid a linebreak that would be worse, though, because
a .
b → (a b)
while
a . b → (a . b) == valid syntax! (dangerous as no tool could warn about it)
(though that’s the case for \ as line splitter and unbreaker, too)
Best wishes,
Arne
PS: What I like the most about the . is that it is already used, so it
does not add more syntax overhead.
PPS: Sorry for being a bit chaotic here.
------------------------------------------------------------------------------
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
