I've been trying to keep up with the activity that's been going on this
past month; but since I've been busy doing other things as well, I think I
failed. Even so, I've tried to review everything, and so I'd like to share
some thoughts.
First, I'm not sure what the status of "\" is; or how it currently fits in
with the proposed GROUP, SLICE, etc semantics. (I don't fully understand
those semantics, but I suspect that they'll be cleared up in the 0.3
Spec...if I understand correctly, though, these are the names of how "\"
has been proposed to be used.)
On the one hand, I like using "\" as a way to end a line; using it to
separate two lists seems kindof reasonable. I'm not sure if using it as a
replacement for "group" will fix things.
On the other hand, using "\" in this overloaded way can potentially be
confusing. Since the different contexts are mostly orthogonal to each
other, this isn't likely to be too much of a problem...except that the
biggest clash will be in the fact that "\" is also Common Lisp's Escape
Character. Indeed, it is because of this that I couldn't see how to
comandeer Haskell's use of "\" as lambda. As much as I like it, I'd more
likely use Paul Graham's "fn" instead. (Like "group", I think "lambda" is
an over-handed keyword for an important, simple concept.)
Which gives me an idea that would further overload "\": If it isn't too
complicated, we can define \(...etc...) to be lambda! (I have the sneaky
suspicion that Common Lisp will make this too complicated, though...)
About a week ago, as I was thinking about the GROUP issue, I had the idea
to use an ellipses in the following manner:
let
... x 10
y 12
{x + y}
This would be equivalent to (and compatible with)
let
...
x 10
y 12
{x + y}
That is, the ellipses designates a group; if anything follows the ellipses
on the same line, it's considered a list in and of itself; any sublist
contained in the ellipses would be "appended" to the original ellipses.
This would be simpler to implement than the other idea I proposed, which
was to have a series of ellipses, like so:
let
... x 10
... y 12
{x + y}
The reason this is a concern with me, is that one of the reasons I consider
GROUP to be "heavy-handed" (besides being a long name) was that it
introduced an extra line that I consider unnecessary.
Of course, this semantic would work just as well with GROUP, or ".", or
even "\", or perhaps even something like "::", as it would for ellipses;
I'm just partial to using ellipses myself.
Second, one of the thoughts I've been having lately, is a concern about the
attempt to be compatible with as many Lisps as possible. While I think
this is a useful concern--indeed, it allows sweet-expressions to be tested
in a variety of environments--it can also hamper a good idea, if not used
cautiously. For example, if using "\" in its various contexts is a good
idea, the fact that Common Lisp hampers it by using "\" as an escape
character shouldn't result in its complete rejection. (It may, however, be
one of several valid reasons to eventually reject the character for
something different.)
This concern goes both ways: Arc, if I understand correctly, uses "\" to
separate two lists on a line. If this is a good idea (and I tend to think
it is), then it should be kept; if it becomes clear that it's awkward,
though, the concept should be rejected, with a special exception being made
for Arc for compatibility reasons.
Indeed, since no two Lisp variants are strictly compatible with each other,
trying to come up with a sweet-expression spec that's fully compatible
between every variant may even be impossible!
Third, I'm not sure I like the idea of using "." for indentation. While it
helps to clarify the structure, it can also clutter the visual presentation
of the source code. I like the fact that word processors allows for ways
to toggle visual whitespace (certainly Kate, and probably Vi and Emacs);
and sometimes I'll do a formal search and replace between " " and "--|"
and back, when I need a better handle on the structure...but those are
editing functions, and I'm not sure if it would be a good idea to have
these things formally in the source code.
So, these are some of my thoughts concerning these proposals. I hope they
prove to be useful!
On Sun, Jul 15, 2012 at 7:42 PM, David A. Wheeler <dwhee...@dwheeler.com>wrote:
> Alan Manuel Gloria:
> > Actually, I think I very much prefer the "\".
>
> I think your visual argument is sound. I particularly appreciate that you
> divided up the issue into different use cases, that makes it much easier to
> follow.
>
> BUT. What concerns me is that "\" is already taken by Common Lisp, and I
> recall that some other Lisps have done the same. Per the Common Lisp
> hyperspec spec:
> http://www.lispworks.com/documentation/HyperSpec/Body/02_b.htm
> A "\" followed by space would begin a symbol whose name begins with space,
> by definition.
>
> Yes, we could say that "\"+space loses its usual meaning while doing
> indentation processing, if your Lisp normally uses \. And someone who
> wants that meaning could use (. symbol-\ -with-space). And you'd be right
> that the need for such symbols is rare.
>
> The real worry I have is, if we do that, would we create a barrier for
> adoption? This would create an immediate pause - and perhaps rejection -
> by anyone who uses "\" for a symbol escape. That includes any Common Lisp
> implementation, and any other systems which have adopted that notation.
> Nobody likes complicated rule interactions.
>
> --- David A. Wheeler
>
>
> ------------------------------------------------------------------------------
> 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
>
------------------------------------------------------------------------------
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
