Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
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.comwrote:
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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
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.comwrote:
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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Alan Manuel Gloria almkg...@gmail.com Actually, I think I very much prefer the \. How about \\ for SPLIT/GROUP? Or use \\ for SPLIT, and something else (say ) for GROUP? I *think* that using \\ would resolve my concerns about slashification, and I know you like the look of the \ character for many use cases. We really don't *need* to have single-character symbols for either GROUP or SPLIT. Even with Scheme's one-char lookahead, you can easily read in the whole symbol before making that decision (our current implementation does). I think it's important that it be non-alphabetic, for clarity (all other abbreviations are punctuation), but there's no implementation reason either have to be single characters. Heck, Lisps already support multi-character abbreviations like ,@. --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Okay, here are a couple of complex examples for group et al.:
define-syntax list-of
syntax-rules (is in)
; base case
\
. list-of x
. \ list x
; handle (var in x) clause
\
. list-of x
. var in expr
. clauses \ ...
. \ concatenate
. . map
. . lambda (var)
. . list-of x
. . clauses \ ...
. . expr
; handle (var is x) clause
\
. list-of x
. var is expr
. clauses \ ...
. \ let ((var expr))
. . list-of x
. . clauses \ ...
; handle (pred? x) clause
\
. list-of x
. pred?(args ...)
. clauses \ ...
. \ if pred?(args ...)
. .list-of x
. . clauses \ ...
. .'()
define xforce(promise)
let ((content unbox(promise)))
case car(content)
(eager)
cdr(content)
(lazy)
let*
\
promise* cdr(content)()
content unbox(promise)
if not{ car(content) eqv? 'eager }
begin
set-car! content car(unbox(promise*))
set-cdr! content cdr(unbox(promise*))
set-box! promise* content
xforce(promise)
--
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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
define-syntax list-of syntax-rules (is in) ; base case \ . list-of x . \ list x ; handle (var in x) clause \ . list-of x . var in expr . clauses \ ... . \ concatenate . . map . . lambda (var) . . list-of x . . clauses \ ... . . expr ; handle (var is x) clause \ . list-of x . var is expr . clauses \ ... . \ let ((var expr)) . . list-of x . . clauses \ ... ; handle (pred? x) clause \ . list-of x . pred?(args ...) . clauses \ ... . \ if pred?(args ...) . .list-of x . . clauses \ ... . .'() As a first experiment, let's see if I can easily recreate what this translates to: (define-syntax list-of (syntax-rules (is in) ((list-of x) (list x)) ((list-of x (var in expr) clauses ...) (concatenate (map (lambda (var) (list-of x clauses ...)) expr))) ((list-of x (var is expr) clauses ...) (let ((var expr)) (list-of x clauses ...))) ((list-of x (pred? args ...) (clauses ...)) (if (pred? args ...) (list-of x (clauses ...)) '() Observations: a) If this is right, why do we need the period-backslash construct, say in the base case? Wouldn't just indentation (two periods) suffice? b) Should we really have to insert a backslash in empty lines? Wart just applies the enter-enter rule at the repl, not in batch mode. Did y'all consider that? c) Are the periods for indentation optional? It's confusing/distracting to mix spaces with periods in the same code. d) I notice that avoiding parens is *much* more compact. It lets me see the global structure at a glance. Let me see if I can reconstruct that property by bringing back some parens: define-syntax list-of syntax-rules (is in) \ list-of x list x \ list-of x (var in expr) clauses ... concatenate map (lambda (var) (list-of x clauses ...)) expr \ list-of x (var is expr) clauses ... let ((var expr)) list-of x clauses ... \ list-of x pred?(args ...) (clauses ...) if pred?(args ...) list-of x (clauses ...) '() Ok, I see why you need GROUP support :) It's because common lisp and scheme use more parens than arc. I also found myself missing arc's syntax for compose, so that I could say: concatenate:map (lambda (var) (list-of x clauses ...)) expr Is this translation correct? I'm not sure which proposal this maps to. Is it subsumed by one of the suggestions? -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: define-syntax list-of syntax-rules (is in) ; base case \ . list-of x . \ list x ; handle (var in x) clause \ . list-of x . var in expr . clauses \ ... . \ concatenate . . map . . lambda (var) . . list-of x . . clauses \ ... . . expr ; handle (var is x) clause \ . list-of x . var is expr . clauses \ ... . \ let ((var expr)) . . list-of x . . clauses \ ... ; handle (pred? x) clause \ . list-of x . pred?(args ...) . clauses \ ... . \ if pred?(args ...) . .list-of x . . clauses \ ... . .'() As a first experiment, let's see if I can easily recreate what this translates to: (define-syntax list-of (syntax-rules (is in) ((list-of x) (list x)) ((list-of x (var in expr) clauses ...) (concatenate (map (lambda (var) (list-of x clauses ...)) expr))) ((list-of x (var is expr) clauses ...) (let ((var expr)) (list-of x clauses ...))) ((list-of x (pred? args ...) (clauses ...)) (if (pred? args ...) (list-of x (clauses ...)) '() Observations: a) If this is right, why do we need the period-backslash construct, say in the base case? Wouldn't just indentation (two periods) suffice? \ . list-of x . \ list x === ( (list-of x) (list x)) --- \ . list-of x . . list x === ( (list-of x list x)) b) Should we really have to insert a backslash in empty lines? Wart just applies the enter-enter rule at the repl, not in batch mode. Did y'all consider that? The use case is when you edit some file, but aren't 100% sure of the correctness of your edits. So you copy-paste the file's contents into the REPL. If the REPL supports ENTER-ENTER but the file has empty lines, you're going to have to insert backslashes or empty comment lines to your file anyway. So using the same rule in the file and in the REPL gives this advantage. c) Are the periods for indentation optional? It's confusing/distracting to mix spaces with periods in the same code. Yes. I find it easier for telling me whether I'm looking at syntax-rules pattern code or generated code - one . is pattern code, 2 . is generated code . It's useful in really long cond expressions: align a . at the condition's indentation, so that adding a new clause somewhere is easy - just press space until your cursor reaches the . d) I notice that avoiding parens is *much* more compact. It lets me see the global structure at a glance. Let me see if I can reconstruct that property by bringing back some parens: define-syntax list-of syntax-rules (is in) \ list-of x list x Incorrect. This yields: \ list-of x list x ( list-of x list x) This is a consequence of only wanting one symbol for GROUP and SPLICE. Here's a more parenthes-y version that is correct: define-syntax list-of syntax-rules (is in) (list-of x) list x (list-of x (var in expr) clauses ...) ...blah blah blah... \ list-of x (var in expr) clauses ... concatenate map (lambda (var) (list-of x clauses ...)) expr \ list-of x (var is expr) clauses ... let ((var expr)) list-of x clauses ... \ list-of x pred?(args ...) (clauses ...) if pred?(args ...) list-of x (clauses ...) '() Ok, I see why you need GROUP support :) It's because common lisp and scheme use more parens than arc. I also found myself missing arc's syntax for compose, so that I could say: concatenate:map (lambda (var) (list-of x clauses ...)) expr Is this translation correct? I'm not sure which proposal this maps to. Is it subsumed by one of the suggestions? Your proposal looks more like GRIT, which despite its name is a combination of what I call ENLIST and SPLIT. --- disgression on GROUP and ENLIST The problem lies in the original SRFI-49 from which we got I-expressions. It said The GROUP symbol is used to allow lists whose first element is also a list David Wheeler (and no doubt many others) thought it meant The GROUP symbol is used to FORCE a list to have the first element be a list. So they assumed that: group a b c d was the same as: group a b c d But it wasn't. You see, group ALLOWS the first element to be a list. It doesn't FORCE the first element to be a list. So: group a b c d === ( a b c d) But people were expecting: ( (a b) (c d)) I renamed this more intuitive interpretation of group as ENLIST to prevent confusion with the original GROUP meaning (i.e. GROUP-as-in-SRFI-49, which doesn't force listing). I called it ENLIST because it forcibly conscripts the rest of the line as a sublist. Dwheeler persists in calling the
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
b) Should we really have to insert a backslash in empty lines? The use case is when you .. you copy-paste a file's contents into the REPL. a) In practice top-level forms tend to be separated by lines anyway in files. b) A smart repl could notice when a line is at the same indent as the previous expression, and eval the previous form. It might print things in the wrong place, something like this: + 1 2 . 7 3 7 Here I've colored* what the computer prints grey to distinguish from what the programmer types in. So the '+ 1 2' is evaluated after he's already started typing the next expression (7). I think this is ok. c) If you paste in several forms into the repl at once, you might need to type in an extra Enter like in the example above (the empty line just above 7). I think that's acceptable as well. What do people think? * - With apologies to those who don't see html formatting in their email. Please speak up if there's someone like that. I try to avoid html emails -- until there's a genuine need for extra formatting. -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
\ . list-of x . . list x === ( (list-of x list x)) Would: \ . list-of x . list x be correct? -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: \ . list-of x . . list x === ( (list-of x list x)) Would: \ . list-of x . list x be correct? . is just whitespace. So: list-of x list x === (list-of x (list x)) list-of x . list x (list-of x (list x)) ; i.e. the same thing. To say I'm indenting this line for my own purposes, but I want you, indentation-processor, to act as if it's indented *over there*, you use SPLIT to mark where you want the indentation-processor to act: list-of x \ list x (list-of x) ( list x) -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: You see, group ALLOWS the first element to be a list. It doesn't FORCE the first element to be a list. So: group a b c d === ( a b c d) Clarification: Should this be (a b (c d))? Ah, yes, that's right. group a b c d === (a b (c d)) -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
. is just whitespace. Ah, of course :/ I'm having trouble holding that in my head. Getting rid of periods, I'm still having trouble understanding why the second line isn't wrapped in parens in: \ a b c Shouldn't this be ((a (b c)))? -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: b) Should we really have to insert a backslash in empty lines? The use case is when you .. you copy-paste a file's contents into the REPL. a) In practice top-level forms tend to be separated by lines anyway in files. Let me clarify: you're editing a function in the file. You're not 100% sure it's correct. The function is a long one, so you put some blank lines between parts of the function to organize it. The function is a single top-level form. You copy-paste the function (not the whole file!!) into the REPL so that you can experiment with it. BOOM! your REPL gets confused by the empty lines inside your function, which it thought was ENTER-ENTER. You are then forced to re-edit the function to insert \ into empty lines to prevent the REPL from confusion. So: using the same reader at REPL and at file is useful for this use case. b) A smart repl could notice when a line is at the same indent as the previous expression, and eval the previous form. It might print things in the wrong place, something like this: + 1 2 . 7 3 7 Here I've colored* what the computer prints grey to distinguish from what the programmer types in. So the '+ 1 2' is evaluated after he's already started typing the next expression (7). I think this is ok. Dwheeler specifically didn't like this IIRC ^^ Let's see what he says. c) If you paste in several forms into the repl at once, you might need to type in an extra Enter like in the example above (the empty line just above 7). I think that's acceptable as well. What do people think? * - With apologies to those who don't see html formatting in their email. Please speak up if there's someone like that. I try to avoid html emails -- until there's a genuine need for extra formatting. -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/19/12, Kartik Agaram a...@akkartik.com wrote: . is just whitespace. Ah, of course :/ I'm having trouble holding that in my head. Getting rid of periods, I'm still having trouble understanding why the second line isn't wrapped in parens in: \ a b c Shouldn't this be ((a (b c)))? Yes it is. But what you were asking was this: \ list-of x list x And it's wrong, because it's parsed as: ( (list-of x (list x))) Because what we wanted was: ( (list-of x) (list x)) That's why we have SPLIT: \ list-of x \ list x Which does that for you magically. -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Careful, I think there's some missing indentation in these examples, and since we've discussed several alternatives it can get confusing. Let's talk about group as it's currently defined. In that case: group a b . c d = (a b (c d)) But the other example given is actually two separate lists, since they are at the same indentation level: group a b c d = (a b) (c d) --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
- Start Original Message - Sent: Wed, 18 Jul 2012 19:28:34 -0700 From: Kartik Agaram a...@akkartik.com To: Alan Manuel Gloria almkg...@gmail.com Subject: Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group b) Should we really have to insert a backslash in empty lines? The use case is when you .. you copy-paste a file's contents into the REPL. a) In practice top-level forms tend to be separated by lines anyway in files. b) A smart repl could notice when a line is at the same indent as the previous expression, and eval the previous form. It might print things in the wrong place, something like this: + 1 2 . 7 3 7 Here I've colored* what the computer prints grey to distinguish from what the programmer types in. So the '+ 1 2' is evaluated after he's already started typing the next expression (7). I think this is ok. The current parser *does* detect when two lines are at the top level and accept it. In fact, it used to be that blank lines were ignored. I *HATED* it. That kind of interaction is absurdly confusing; nobody expects to type in something and see the results from the input BEFORE that. When you're using a REPL you do NOT need confusing output. This was one of the first things I fixed: Making sure that ENTER ENTER works. There are certainly alternatives, e.g., a symbol that means execute this. Several languages do exactly this. But that gets to a drag interactively; it's hard to beat the speed of ENTER ENTER. You don't need to use \ to make a blank line. A semicolon (possibly indented) will also cause the line to be ignored, and you don't need to match the indentation. This has the disadvantage that in text files, you can't have truly blank lines in the middle of a form, you have to put something (like a semicolon) in. Python solves this by making the interactive syntax DIFFERENT from syntax in code (blank lines end an expression only in interactive mode), but that seems like a bad idea for Lisp. * - With apologies to those who don't see html formatting in their email. Please speak up if there's someone like that. I try to avoid html emails -- until there's a genuine need for extra formatting. Um, me for one :-). --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Just to confirm, presuming SPLIT semantics (which is what is currently implemented) using \ as the SPLIT symbol: \ a b c Shouldn't this be ((a (b c)))? Yes, indeed, that's right. I think of this as \ starting a list with a 0-length function name. --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
OK, I'll summarize. First, we have a pool of syntax symbols. Let's not fix meanings to symbols for now: ~ \ . ! $ % ^ Then we have a bunch of concrete proposals: 1. almkglor: Don't use GROUP Don't use SPLICE Use SPLIT Use ENLIST Use 2 symbols from our pool of syntax symbols. Current proposal: \ = SPLIT, ~ = ENLIST 2. dwheeler: Don't use GROUP Don't use SPLICE Use SPLIT Don't use ENLIST Use 1 symbol from our pool of syntax symbols. Various: ! = SPLIT, ~ = SPLIT, \ = SPLIT (in order of preference?) 3. arne_bab: Use GROUP + GROUP-inline=dotted list Use SPLICE - SPLICE-at-beginning rule Don't use SPLIT Don't use ENLIST Use 2 symbols from our pool of syntax symbols. Current proposal: . = GROUP, \ = SPLICE Those positions/ideas look OK to consider? Are there more ideas? 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
a . b → do a double bracket . b → pure syntactic sugar to give the code a stronger structure. a SPLIT b = (a (b)) SPLIT b = b What isn't compatible is: a . b → construct a cons-cel since: a SPLIT b is two expressions, a followed by b Instead, your proposal is: a \ b → split a line in two a \ b → avoid a linebreak. So, using my terminology, your position is: I would not call it “position”, yet. Rather an idea. 1. Use GROUP = ., with the addition that GROUP-inline now means form a cons cell (in the original rules, GROUP-inline was meaningless and represented the symbol used by itself), (a . b) is the original syntax for forming a cons-cel, at least in emacs lisp. So this is a restriction on the use of the . (the reason why it cannot be used inline). So group-inline would still just mean the symbol itself. Addition: GROUP at the beginning means indent without meaning in the language. 2. Use SPLICE = \, with the removal of the SPLICE-at-the-beginning rule (and the retention of the SPLICE-inline and SPLICE-at-the-eol rule). Jepp. Best wishes, Arne -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Uhm. What you call GRIT *is* SPLIT. Ugh, I'm an idiot. That's what I get for trying to come up with new approaches on-the-keyboard. I tried some alternative ways of combining things, kept fiddling, and ended up circling back :-). That said, I think my alternative rule for SYMBOL-at-beginning, followed by something, *IS* subtly different - i.e., it's ALWAYS a list, even if there's only one datum in the end. Different isn't necessarily better, though. Maybe that handles let better? At this point, I'm trying to brainstorm different approaches that *might* be useful, so if we come up with a few stupid ideas on the way to a great new one, that's fine. Hence my continued position: SPLIT (to support :keyword-style juxtaposition pairings) and ENLIST (to support (k v)-style explicit pairings), using two different symbols. You can drop ENLIST, maybe, because SPLIT-by-itself can do part of its work, at the cost of adding one vertical line, but ENLIST can't do SPLIT's work, which is to juxtapose an indented line (i.e. to cancel an indentation). I'm convinced of the need for a SPLIT-style semantic *between* datums on a line, and of course we need something to handle lists of lists (e.g., GROUP, SPLIT symbol on its own line, whatever). I'm not as certain of ENLIST. I'd feel better trying around different ideas for a short while first. --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Hi Alan, At Wed, 11 Jul 2012 17:28:43 +0800, Alan Manuel Gloria wrote: All right all right, let's use this thread to discuss GROUP, SPLICE, SPLIT, and ENLIST. Let's call this DEBATE POINT 1, for reasons that are not readily apparent. I tried to follow your reasoning, but I did not get a concrete image of the different points. I think I missed code examples… GROUP - the original SRFI-49 rule. The GROUP marker is invisible when at the start of the line, and is removed, except for its effect on indentation - the indentation of that line is still the column where the GROUP marker is. The net effect is that if GROUP is on a line by itself followed by a line that is more indented, an extra open parenthesis appears. Otherwise, GROUP does *not* cause an increase in nestedness. I don't remember well, but it was not explicitly specified what would happen if group occurs on a line by itself and is followed by a line on the *same* indent level - presumably it inserts the empty list. The original GROUP marker was the symbol group. With . as group marker: let . a b c a (let ((a b)) (c a) SPLICE - a proposed addition to the sweet-expressions 0.2 spec. The SPLICE marker acts differently based on its location (1) at the end of a line, the next line's indentation is ignored and it is treated as a continuation of the previous line - i.e. spliced (2) at the start of a line, it is simply ignored (3) in the middle of the line, it is treated as a newline followed by an indentation to a column equal to the current line's indentation. It is not explicitly specified, but implied that if the SPLICE is on a line by itself, the end-of-line meaning is invoked rather than start-of-line. Originally proposed with \ being the SPLICE marker. defun \ a () \ b \ c (defun a () (b) (c)) SPLIT - a proposed modification of SPLICE rules that allows unification with existing GROUP rules. The end-of-line meaning is removed completely, and is interpreted in the same manner as the inline rule. SPLIT at the start of the line is ignored (the same meaning as SPLICE-at-the-start). SPLIT-by-itself invokes the start-of-line meaning. Variously proposed with \ or . being the SPLIT marker. defun a () . b . c defun a () \ b \ c (defun a () (b) (c)) let . ??? → I don’t understand what it means on its own. ENLIST - a proposed modification of GROUP rules that (probably?) gives better intuition to the meaning. ENLIST at the start of a line always increases the nestedness of the rest of the line, and if the succeeding line(s) are more indented, will have the same nestedness as the first line. Presumably, multiple ENLIST at the start of the line also further increase the nestedness, and presumably an empty ENLIST line (i.e. a line composed only of ENLIST markers) will simply increase nestedness of the succeeding line if it is more indented than the ENLIST line. Also presumably, an ENLIST in the middle of a line would allow succeeding lines to have multiple, reducing indentation levels as long as they more indented than the ENLIST line, although no actual concrete specification exists for this behavior. Originally proposed as a reinterpretation of GROUP, renamed in order to separate its concepts from GROUP and give better discussion. let \ a b defun c () \ d (let ((a b)) (defun c () (d))) Did I understand that correctly? I cannot comment on the pros and cons without being sure that I really understand the rules… Best wishes, Arne -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Alan Manuel Gloria almkg...@gmail.com:
Hence my continued position: SPLIT (to support :keyword-style
juxtaposition pairings) and ENLIST (to support (k v)-style explicit
pairings), using two different symbols.
You can drop ENLIST, maybe, because SPLIT-by-itself can do part of its
work, at the cost of adding one vertical line, but ENLIST can't do
SPLIT's work, which is to juxtapose an indented line (i.e. to cancel
an indentation).
My (current) position:
* I agree on SPLIT, let's do it.
* I disagree on ENLIST. Every rule we add has a cost in learning/explaining,
and using up a punctuation character is a big deal (there aren't many in
straight ASCII that aren't already used). Fundamentally, I'm skeptical that
ENLIST is worth the trouble.
We already have other ways to support (k v)-style pairings. Obviously (k v)
and k(v) work, for example.
I was looking at the various let uses, because let is a commonly-used case
that causes problems with indentation syntax. The example/streams.scm has
for example (thanks for the example!):
. let*
.\
. promise stream-unwrap(x)
. dataxforce(promise)
.{ data eq? private-stream-tag }
That is pretty readable as-is, actually. But all those lines consumed by let*
for a simple set of variable assignments *is* annoying. Yet even without
ENLIST, we can handle expressions with let* using much less vertical space:
. let* ( (promise stream-unwrap(x)) (data xforce(promise)) )
.{ data eq? private-stream-tag }
or:
. let* ( promise(stream-unwrap(x)) data(xforce(promise)) )
.{ data eq? private-stream-tag }
Once you're inside (...) indentation isn't used, so you could do a lot of
variable assignments without problems for simple assignments (which they often
are). Or if you have a lot of simple assignments, in many cases, you could
just use another let, e.g.:
. let* (var1(value1))
.let* (var2(value2))
. runme()
I'm not saying that ENLIST can't be usefulo, but even with let I think there
are often alternatives that reduce its utility.
I do agree on SPLIT; for completeness, let me document some of the reasons why.
Obviously SPLIT is useful in cases where you have a pair of datums that are
short logically related (so you'd like them on one line) but they must be at
the same level in a list.
For cases were there's a pair of datums that are not short you need deeper
indentation processing, but want to show their relation, SPLIT is also pretty
nifty, and the rule SYMBOL at beginning of line is ignored is really easy to
explain. E.G., Arc's:
if
long-cond-1
\ what-to-do-if-long-cond-1-true
long-cond-2
\ what-to-do-if-long-cond-2-true
...
I was trying to come up with an alternative rule for SPLIT when stuff happens
after the SPLIT symbol on the same line. That's such an easy-to-invoke
situation that I'd like it to have a *reason* to be used. My always creates a
list alternative rule is at least an alternative to the SPLIT notation. But
on reflection, it's too hard to explain, *and* using explicit (...) is probably
clearer in cases like let.
We could add ENLIST later if it turns out to be really necessary, since that'd
be a different symbol anyway.
So what do you think? Think you could be happy with SPLIT without ENLIST, and
give it a try?
--- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/13/12, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria almkg...@gmail.com:
Hence my continued position: SPLIT (to support :keyword-style
juxtaposition pairings) and ENLIST (to support (k v)-style explicit
pairings), using two different symbols.
You can drop ENLIST, maybe, because SPLIT-by-itself can do part of its
work, at the cost of adding one vertical line, but ENLIST can't do
SPLIT's work, which is to juxtapose an indented line (i.e. to cancel
an indentation).
My (current) position:
* I agree on SPLIT, let's do it.
* I disagree on ENLIST. Every rule we add has a cost in
learning/explaining, and using up a punctuation character is a big deal
(there aren't many in straight ASCII that aren't already used).
Fundamentally, I'm skeptical that ENLIST is worth the trouble.
We already have other ways to support (k v)-style pairings. Obviously (k v)
and k(v) work, for example.
I was looking at the various let uses, because let is a commonly-used
case that causes problems with indentation syntax. The
example/streams.scm has for example (thanks for the example!):
. let*
.\
. promise stream-unwrap(x)
. dataxforce(promise)
.{ data eq? private-stream-tag }
That is pretty readable as-is, actually. But all those lines consumed by
let* for a simple set of variable assignments *is* annoying. Yet even
without ENLIST, we can handle expressions with let* using much less
vertical space:
. let* ( (promise stream-unwrap(x)) (data xforce(promise)) )
.{ data eq? private-stream-tag }
or:
. let* ( promise(stream-unwrap(x)) data(xforce(promise)) )
.{ data eq? private-stream-tag }
Once you're inside (...) indentation isn't used, so you could do a lot of
variable assignments without problems for simple assignments (which they
often are). Or if you have a lot of simple assignments, in many cases, you
could just use another let, e.g.:
. let* (var1(value1))
.let* (var2(value2))
. runme()
I'm not saying that ENLIST can't be usefulo, but even with let I think
there are often alternatives that reduce its utility.
I do agree on SPLIT; for completeness, let me document some of the reasons
why.
Obviously SPLIT is useful in cases where you have a pair of datums that
are short logically related (so you'd like them on one line) but they must
be at the same level in a list.
For cases were there's a pair of datums that are not short you need deeper
indentation processing, but want to show their relation, SPLIT is also
pretty nifty, and the rule SYMBOL at beginning of line is ignored is
really easy to explain. E.G., Arc's:
if
long-cond-1
\ what-to-do-if-long-cond-1-true
long-cond-2
\ what-to-do-if-long-cond-2-true
...
I was trying to come up with an alternative rule for SPLIT when stuff
happens after the SPLIT symbol on the same line. That's such an
easy-to-invoke situation that I'd like it to have a *reason* to be used. My
always creates a list alternative rule is at least an alternative to the
SPLIT notation. But on reflection, it's too hard to explain, *and* using
explicit (...) is probably clearer in cases like let.
We could add ENLIST later if it turns out to be really necessary, since
that'd be a different symbol anyway.
So what do you think? Think you could be happy with SPLIT without ENLIST,
and give it a try?
Yes, I did say that you could drop ENLIST, since there are a multitude
of ways to get what it means, while that's harder for SPLIT. Notice
how I don't use ENLIST at all in example/streams, even though arguably
it's clearer with ENLIST than with SPLIT, and why I haven't gone
around to implementing it (^.^)v. Still, ENLIST does have the
advantage that it takes fewer lines (unlike replacing it with SPLIT,
which requires a separate line for SPLIT and for the first
let-variable) while still retaining indentation processing (unlike
surrounding with parentheses).
On 7/12/12, Arne Babenhauserheide arne_...@web.de wrote:
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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
Alan Manuel Gloria: All right all right, let's use this thread to discuss GROUP, SPLICE, SPLIT, and ENLIST. Agree. By the way, thanks very much for creating this summary on the mailing list + the info on the Wiki. Nicely done + very helpful. ... 1. NO to GROUP and SPLICE 2. YES to SPLIT, and use \ for it, and ignore other language's habit of using it to mean continue to next line 3. YES to ENLIST, and use ~ for it, and really start to crystallize what exactly is meant with ~ in various contexts. Cons to my position: 1. Both SPLIT-by-itself and ENLIST-by-itself, followed by a line that is more indented, mean exactly the same thing. This is arguably Not a Good Thing, as there is now more than one way to express something, neither being a truly preferred way. ... 3. Using \ for SPLIT is not compatible with most other language's usage, especially when it occurs at end-of-line. 4. Using up two punctuation symbols. They're in short supply. 5. The \ meaning is incompatible with its meaning in CL, and many other Lisps (including many Scheme implementations) also use this interpretation. We could implement both SPLIT and ENLIST, but I don't think that we really need the SPLIT char to work at the beginning of a line (after indent), and ENLIST could easily be limited to only apply at the beginning of a line (after indent). So here's another variant semantic that combines GROUP and SPLIT, let's call it GRIT :-). GRIT: - a proposed combination of GROUP and SPLIT, where a single SYMBOL is used. Semantics: 1. If SYMBOL is at the beginning of the line (after indent), and nothing else on the line (other than maybe space/tab/;-comment), then it creates a list without header using all children lines, like GROUP. 2. If SYMBOL is anywhere after the first datum on a line, it works like SPLIT. (What if it's the last one?) If something else follows on the line I'm not sure what it should be. It'd be good to focus on how to cleanly handle stuff like let since that seems to be a common case. It could be like ENLIST - force an extra list. Or, it could force a list in certain situations. Ideas? The obvious question is what SYMBOL should be. I'm wondering if ~ would be a better choice than \, since \ has a meaning in so many places. --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
On 7/9/12, David A. Wheeler dwhee...@dwheeler.com wrote:
The special chars that look most promising to me as single chars:
\ = often means continue on next line when at eol in other languages
This is one I've been using, and as noted earlier, it already has a meaning
to many readers.
~ = mostly unused except in Arc, where ~foo means the function foo
with its output notted and ~ means the not function; otherwise
valid function name
^ = otherwise valid function name (superscript? even infix
exponentiation or XOR operator: {a ^ b})
They don't have to be single characters, though. The current group marker
is already multiple characters. Plausible special abbreviations could
include:
~~
^^
--
I'm opposed to multi-char syntax markers mostly because of the
one-character lookahead. Current SRFI-49-based implementation handles
'group OK, but at the price of not following the structure of its
spec. This allowed spec bugs to get through. So: I'm more open to
single-char syntax as it is much easier to write the implementation to
be closer to the spec.
Since . is unlikely to occur at the beginning of a line, that's plausible
as a group marker, but as I described earlier I don't think we should use it
in the middle (e.g., for splits).
.-by-itself also precludes .-as-indent, and I feel that .-as-indent is
actually more useful, even though you were trolling when you proposed
that. As I mentioned before, proper design of the SPLICE rules allows
SPLICE = GROUP, so we can free up . to be indent by selecting
another character for SPLICE.
Maybe we can divide this discussion into two areas:
1. Which symbols can we use for special operations, e.g., ~
~
\
^
@
.
2. What semantics should we use. Perhaps we can use placeholders SYMBOL1,
SYMBOL2, SYMBOL3 when we don't care.
We should probably rename SPLICE, since at this point it's not
*really* SPLICE anymore. From my point of view, your original thought
seems to have been \-at-eol removes indentation from succeeding
line, which gives the word SPLICE the correct meaning, but you then
realized that it would not be sufficient to clearly express the Arc
'if and CL keywords if the sub-expression involved wants something
complicated. You then overloaded \ to have special meanings at the
start and middle of the line, which aren't actually splice per se
(and are more of end the expression at this point).
I then argued for the removal of the SPLICE-at-the-eol rule, which
utterly obliterates its splice meaning.
So: can we at least agree that GROUP can be coded as a special case of
what we currently call SPLICE, and rename SPLICE to END? or SPLIT?
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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
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)) Right. The goal is come up with a single syntax that makes common cases easy, and I really want it to be fundamentally the same across different LISPs. By the SPLICE-at-the-start and SPLICE-inline rules, we can express it as: if ..(cond1) ..\ (exp1) ..(cond2) ..\ (exp2) ..\ (exp-else) Hmm, that wasn't my intended meaning. My interpretation of that expression would be this, because \ at the beginning of a line means wrap () around it: (if (cond1) ((exp1)) ( (cond2) ((exp2)) ((exp-else I would instead write this if example as: if ..(cond1) \ (exp1) ..(cond2) \ (exp2) ..(exp-else) foo ..:foo-stuff \ (exp1) ..:bar-stuff \ (exp2) Here we agree on the intended meaning. By the way, these periods at the beginning of the line do make the code easier to read when you're quoting on a system that strips out front whitespace. I wonder if we should allow leading periods as an alternative to whitespace (?) when indentation is significant. I can't think of a case where leading periods are actually used for symbol names. As long as they're not FORCED they might be useful. What do you think? (In general, I'm trying to think outside of the box. 99% of the ideas might be stupid, but if in the journey we find good stuff, then great!) --- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
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… 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 Best wishes, Arne -- 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use . on own line instead of group
First of all, I''m delighted to see this discussion! I'll look over Alan Manuel Gloria's parser proposal more carefully soon. 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. I can be talked either way about the \ splice thing. The goal is to make easy things easy, without too many rules. Is the extra \ rule helpful? Neutral? More harm than good? I'd love to hear more feedback on it. --- 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
