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 BTW, another option to consider: explicitly avoid the case of macros. In wart I have no way to state quasiquote without parens. I figure the point of s-exps is to do macros, so it's not a big hardship if macros have parens. "Syntax most of the time, drop down to s-expressions when you need macros." I realize that there are lots of other reasons to use group/split/enlist/grit. But if people are ok with it, this makes our job a little bit less circumscribed. -- 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"
- Start Original Message - Sent: Wed, 18 Jul 2012 19:28:34 -0700 From: Kartik Agaram To: Alan Manuel Gloria 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"
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"
On 7/19/12, Kartik Agaram 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"
On 7/19/12, Kartik Agaram 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 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"
> "." 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 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"
On 7/19/12, Kartik Agaram 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"
> 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))? -- 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"
> > 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 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 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
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"
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"
Alan Manuel Gloria > 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"
Kartik Agaram:
> I've been falling behind as well. I wanted to see if time would reduce
> my dislike for GROUP, but that doesn't seem to be happening. Indeed, I
> can't even bring myself to do more than skim the discussions about it.
> I've struggled to understand/articulate why this is to myself, and
> mostly failed. The best I can come up with: making a language
> indent-sensitive should never add new syntax. Certainly not syntax
> that isn't attached to existing code (like quote, parens, unquote --
> or python's colon), and absolutely not a keyword like 'group'. SRFI 49
> is utterly wrong-headed about this.
I agree with you. I started with SRFI-49 because it had a lot of good ideas,
but using an *alphabetic* symbol for grouping is not (in my view) a good idea.
So, let's fix that.
> Also, using backslash for any meaning is butt ugly.
Okay, a vote *against* "\".
I don't mind the *look* of backslash, I just worry about its affect on Lisps
that use slashification.
> > 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}
>
> Modulo my reservations about group, this is my favorite idea so far.
> But it also screams to me that we could just use parens. It might help
> the discussion if we always use a complex example that we think
> *requires* group.
You can run the iformat.scm on various files to come up with nasties. It's not
that group is required in a Turing-complete sort of way; the problem is that
having lists-of-lists, with complex structures (like code) inside them, is a
problem when (...) disables indentation. Obviously, one solution is to enable
indentation inside (...), but that creates all sorts of backwards-compatibility
issues, and it's REALLY convenient to be able to *disable* indentation where
it's not helpful.
--- 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"
Alpheus Madsen:
> 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.)
The "status" is in some sense easy: We're discussing that right now!
There are several proposed semantics, and several proposed symbols.
There are advantages to the various alternatives; now is the time to
discuss them.
A summary of the options is here:
http://sourceforge.net/p/readable/wiki/Current/
> 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.)
This is my concern with "\" as well.
Alan Manuel Gloria's analysis (on 16 Jul 2012 09:31:55 +0800) suggests
a mild (but not necessarily decisive to me) advantage to using "\"
for several common use cases. But since "\" as an escape mechanism is
widely-used, that is a big disadvantage to it.
> 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...)
Right. If we don't have "\" mean SPLIT or GROUP, and your Lisp doesn't
include slashification, you could indeed use \(...) if you wanted to.
That's another argument for NOT using "\" as SPLIT or GROUP.
> 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.
Okay! That would just mean that GROUP="...".
That's certainly a reasonable proposal.
One implication is that some of the period-as-indentation proposals
can't be used, but if you say that period is only indentation if followed
by space or tab (my current proposal) then there's no issue.
This proposal would, in fact, be really easy to implement given our
current code. If you just strip away the "...", I think that'd
be a 2-line change.
HOWEVER, this would mean that you could not easily have "..." as a first
parameter, and this *can* happen in Scheme (e.g., in macros).
Yes, they can be escaped, but it's best if the notation minimizes the
need for escapes.
If you change the symbol to GROUP="" (4 periods), that problem
disappears.
> 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}
Agreed. Also, inserting the ellipses on *each* line would be a pain
when doing it by hand, so I don't like this one as much.
> 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.
Fair enough.
Actually, though, changing symbols makes sense.
> 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.)
...
> 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 betw
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
Hmm, a new fly in the ointment for \-as-symbol. I've found that using symbol \ as SPLIT/GROUP symbol has an implementation complication for anyone who also wants to support slashification inside (...). And I expect some reader implementations *will* want to slashification, at least inside (...). I think that is a negative against using \ as GROUP=SPLIT; let me explain. First: I've merged in a 2-line patch so that the SPLIT symbol is only considered as such if it BEGINS with the first split character. This means that, if SPLIT is \, you can escape it using (. \). This is great, we can escape the SPLIT symbol easily, instead of the old GROUP GROUP approach. EXAMPLES: \ . a b => ((a b)) (. \) . a b => (\ (a b)) HOWEVER, this presumes that NO implementation will EVER want slashification. It would make sense to implement arbitrary slashification inside (...), since SPLIT cannot ever have that meaning inside (...), but that turns out to be more complicated to implement. The problem is that when the modern-expression reader is invoked, indentation processing may be on - or it may be off. So when the modern-reader sees \ space as the first two characters, it doesn't know what to do. Common Lisp requires slashification, and the Scheme spec specifically notes slashification as a possibility, and I'm pretty sure that several Scheme implementations support it (I'm not sure how many, I suppose we could check). So while not everyone needs to support slashification, making it unusually *hard* to do seems like something to avoid. We could create two entry points for the modern-expression reader, or an extra parameter, so it'd know if indentation processing is active (and thus if initial slashification is okay). But that's annoying to use, and is otherwise unnecessary. Also, this extra parameter would spread through any modern-expression reader implementation. This implementation problem does NOT happen with other symbols. Changing to another symbol, like ! or ~, makes it go away completely. BTW: I don't think we even have to have a single-character symbol for SPLIT, our current implementation handles that easily. I *do* think that the SRFI-49's use of the symbol "group" was a mistake - it's very confusing to have *alphabetic* symbols have a special meaning (especially one with potentially other uses). Now granted, we might have other escaping mechanisms for the SPLIT (GROUP?) symbol, but it's important that we have one, and (. EXPR) is a pretty good one (it doesn't interfere with existing code). --- 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"
>
> Is 'group' really going to be easier to understand than enabling
> whitespace-sensitivity inside parens? I think that's a good test if
> we've decided the latter is too complex.
>
> Also, using backslash for any meaning is butt ugly.
>
I don't completely agree with your sentiments; in part, because adding
significant whitespace is bound to change the language significantly, so
adding a symbol or two here or there isn't a concern for me.
Oddly enough, I kindof like the idea of GROUP; I just don't like the
current syntax.
In my modest attempts to write my own whitespace parser, though, I find
that turning off whitespace in brackets simplifies implementation; it's
also useful for creating long lists without a "continue to next line"
character; and since a goal of the project is to preserve s-expr
compatibility, turning off whitespace significance in brackets is rather
important!
If we were designing a language from scratch, I'd be a little more open to
leaving significant whitespace on in brackets, and breaking s-expr
compatibility. But the project has an even more important goal (and one
that attracts me to this particular project): to prove the isomorphic
nature between s-exprs and sweet-expressions, particularly with
compatibility with macros. This is an important reason why operator
precedence is, in particular, something to avoid as much as possible.
Besides, I really like the simplicity of s-exprs; the way I see it, the
goal of sweet-expressions is to prove that we can have
infix-yet-syntax-free, whitespace-significant s-exprs. (With this goal in
mind, of course, sweet-expressions had better be just as elegant!)
> Arc, if I understand correctly, uses "\" to separate two lists on a line.
>
> Perhaps we're thinking about different Arcs? http://arclanguage.org is
> not whitespace sensitive at all. (It does not use backslash --
> otherwise I wouldn't be using it :)
No, we're thinking about the same Arc; it was my understanding from reading
the list that Arc uses "\" in certain contexts, and certain
sweet-expressions are trying to preserve the idioms.
I may be wrong, though: perhaps the Arc idioms in discussion are of the
form
(list 1 2 3) (list 4 5 6)
which, for sweet-expressions, would be
list 1 2 3 \ list 4 5 6
(I am probably getting even this example wrong).
Also, using backslash for any meaning is butt ugly.
>
I would partially disagree with this; but I'm willing to put up with it in
certain contexts. It's an idiom in several languages, for example,
including Bash and Python, to put a backslash at the end of a line; in
Python, though, I find it ugly enough that I usually try to wrap something
in parentheses (which turns off significant whitespace) than resort to
ending a line with a backslash.
For separating two lists on a single line, however, it isn't that bad of an
idea.
In many languages, using the backslash is a good way to escape characters;
since Common Lisp is one such language, and it's used for escaping
characters in symbols, using the backslash for other things is problematic.
And I *really* like how Haskell uses the backslash for lambda expressions!
I like it so much, I really wish we could use it in Common Lisp!
Perhaps it wouldn't be too much trouble to recognise when something is of
the form
\((x) {x + 5})
and translate it into
(lambda (x) (+ x 5))
as it is, I think that the current form,
lambda((x) {x + 5})
would be rather clunky. At the very least, Paul Graham gave us the
possibility of
fn((x) {x + 5})
> Modulo my reservations about group, this is my favorite idea so far.
> But it also screams to me that we could just use parens. It might help
> the discussion if we always use a complex example that we think
> *requires* group.
Here's an example taken from
"http://sourceforge.net/p/readable/wiki/Examples/
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
I've been falling behind as well. I wanted to see if time would reduce
my dislike for GROUP, but that doesn't seem to be happening. Indeed, I
can't even bring myself to do more than skim the discussions about it.
I've struggled to understand/articulate why this is to myself, and
mostly failed. The best I can come up with: making a language
indent-sensitive should never add new syntax. Certainly not syntax
that isn't attached to existing code (like quote, parens, unquote --
or python's colon), and absolutely not a keyword like 'group'. SRFI 49
is utterly wrong-headed about this.
Curly infix adds syntax, but it seems intuitive. Modern exps move
parens around; that's also fine. But a pass that just makes whitespace
sensitive is too complex if it also affects non-whitespace. I think
that will be a non-starter. It is seriously easier to use an existing
mechanism and just wrap the whole thing in parens.
> I'm not sure if it would be a good idea to have [editing functions]
> formally in the source code.
I think your sentiment here is close to my previous paragraph.
Is 'group' really going to be easier to understand than enabling
whitespace-sensitivity inside parens? I think that's a good test if
we've decided the latter is too complex.
Also, using backslash for any meaning is butt ugly.
> 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}
Modulo my reservations about group, this is my favorite idea so far.
But it also screams to me that we could just use parens. It might help
the discussion if we always use a complex example that we think
*requires* group.
> 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!
Yeah, I agree.
> Arc, if I understand correctly, uses "\" to separate two lists on a line.
Perhaps we're thinking about different Arcs? http://arclanguage.org is
not whitespace sensitive at all. (It does not use backslash --
otherwise I wouldn't be using it :)
--
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"
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 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 definitio
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 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
In the thread: "Proposal: Let's reserve some symbols "for future
syntactic purposes" in 0.3":
On 7/14/12, David A. Wheeler wrote:
>
> Although I think I'm the one who started using "\" for SPLIT, I'm
> increasingly thinking it's a bad symbol choice. The Common Lisp spec uses
> that as an escape for the next character in a symbol, and other Lisp
> implementations do the same. It'd be better to use a symbol that doesn't
> cause so much incompatibility from the start.
>
> Of this set, I think "!" and "~" are better choices. So you could do:
>
> myfunc
> . 1 ! 2 ! 3
>
> or maybe:
> myfunc
> . 1 ~ 2 ~ 3
>
> => (myfunc 1 2 3)
>
>
>
> If the symbol for GROUP == SPLIT, then:
> !
> . a b
> . c d
>
> or
> ~
> . a b
> . c d
>
> => ( (a b) (c d))
>
> Between the two, I have a slight affinity for "!" - it looks like a
> "separator" to start with.
>
> Thoughts? Comments?
Actually, I think I very much prefer the "\".
SPLIT has two rules, which when utilized, allow what I expect to be
four use cases:
let
. ; use case 1: extra indentation introducer
. SPLIT
. . foo bar()
. define quux()
. . nitz
. . . ; use case 2: next-line pairing
. . . :keyword
. . . SPLIT muti item
. . . . multi line expression
. . ; use case 3: line splitting / same-line pairing
. . arf() SPLIT meow()
. ; use case 4: alternative "empty line" marker
. SPLIT
. define quuux()
. . 42
. SPLIT
. SPLIT
. {quux() * quuux()}
Now, the reason why I prefer "\" is that it is a DIAGONAL line, which
serves to visually act as both a horizontal and vertical line.
So let's split by each use case:
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:
let
. !
; |
; v what's below it?
. . foo bar()
let
. ~ ; ---> what's here?
. . foo bar()
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"
Now, ~ works better here I think, although \ feels like a close second:
:keyword
~ multi item expr
And ! is not visually appealing at all:
:keyword
! multi item expr
3. The third use case:
arf() \ meow()
In this case, the \ looks almost like a vertical line.
Although ! is superior for this use case:
arf() ! meow()
Now, one *might* convincingly argue that a horizontal separator like ~
is good enough:
arf() ~ meow()
kinda like - you know - like this - where you separate clauses with -
what do they call it? - ah, em-dashes.
but in this case ! is clearly superior - and I think \ still beats ~
in this use case.
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:
define quuux()
. 42
!
!
{quux() * quuux()}
And again, ~ might argue that it could also look good, if you squint right:
define quuux()
. 42
~
~
{quux() * quuux()}
but \ works well visually for use cases 1 and 2, and is acceptable for
cases 3 and 4. ! doesn't work very well visually for case 1,
definitely looks weird for case 2, and works really well for cases 3
and 4. ~ doesn't work very well for use case 1, works reasonably well
visually for case 2, and requires some twisting to work for cases 3
and 4
--
So, I still think \ is superior, at least visually. Of course, its
use as an escape character is there for hysterical raisins, but the
escaping mechanism IMO doesn't really exploit its visual shape for its
full potential.
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"
Alan Manuel Gloria: > OK, I'll summarize... I think that's a great summary. I put it into [Current], too. --- David A. Wheeler === > > 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? -- 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"
On 7/13/12, David A. Wheeler wrote:
> Alan Manuel Gloria :
>> 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 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
>
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
Alan Manuel Gloria :
> 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"
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"
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 > 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
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"
On 7/12/12, David A. Wheeler wrote: > 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?) Uhm. What you call GRIT *is* SPLIT. SPLIT is the combination of GROUP and SPLICE, where a single SYMBOL is used for both, and removing the SYMBOL-at-eol rule from SPLICE (so that the only possible interpretation for SYMBOL-at-eol is the same as SYMBOL-inline - it ends the previous expression and starts a new one at the same ident). So: let . SPLIT . . x y . result ==> (let ( (x y)) result) See example/streams.scm in my latest bundle for usage of SPLIT as a replacement for GROUP. GRIT ***is*** SPLIT, down to the unresolved question of "What if it's the last one?". As to the end-of-line thing: One way of viewing this would be to think of things such that SPLIT means "end the current expression at the current indentation level", and that indentation figures out WHERE to put the SPLIT's. This means that: foo bar quux nitz kuu is equivalent to foo bar quux \ nitz kuu \ \ is equivalent to (foo (bar quux) ; <-- ended at this point (nitz kuu) ; <-- ended at this point ) ; <--- ended at this point Or something. This is Haskell's view of indentation processing: it figures out where to put the ";" that ends expressions. > > 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? We want to support something like this in Arc: if . pred(f) . \ let x f(g) . . . something(x) . . . something-else(y) . pred2 . . f . . g . \ with . . . \ . . . . x \ g(f) . . . . y \ something-something g f . . . something-something(y) . . . something-something(x) . ; else . \ do . . . remove-all foo x bar . . . convoke meow cat Also remember that the same problem occurs with :keyword arguments, so we need to support something much like this even if we decide that only PG uses Arc anyway: ; CL some-keyword-func . :pred . \ let ((x f(g))) . . . something(x) . . . something-else(y) . :pred2 . \ let . . . \ . . . . x g(f) . . . . y something-something g f . . . something-something(y) . . . something-something(x) . :else . \ begin . . . remove-all foo x bar . . . convoke meow cat So: if something follows SPLIT on the same line, where SPLIT is at the start of a line, then SPLIT **must** be ignored/removed from the input stream, except for its effect on defining where the indentation is - i.e. the current GROUP semantics. Hence: SPLIT = GROUP + SPLICE = GRIT. > > 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. Either way will do. Note that we have a significant tension between CL keywords and CL/Scheme's let (and arguably the rest of Lisp). So I think we should consider he use of a *different* symbol to support keyword-pairing and another symbol for list-pairing: (foo ; juxtaposition is enough :key value :key2 value2) (le
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
- Start Original Message - Sent: Wed, 11 Jul 2012 21:51:17 -0400 (EDT) From: "David A. Wheeler" To: almkg...@gmail.com Subject: 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?) Here's a proposed third rule for SYMBOL-at-beginning for GRIT: 3. If SYMBOL is at the beginning of the line, and something else is on the list afterwards, it ALWAYS creates a list from what follows, EVEN IF there is only one datum. (This makes it like ENLIST.) Okay, so it's really a combo of ENLIST and SPLIT. Here's my thinking - I'm particularly trying to support awkward things like "let". If you use let, you can simply say "the first parameter better start with an indented SYMBOL". If it's complicated, it can look like this: . let . . \ a(a0) b(b0) . . . c calculate-c0() . . . d calculate-d0() . . do-stuff-inside-let() Simpler versions look like: . let . . \ a(a0) b(b0) . . do-stuff-inside-let() In the above, you don't actually need "\"; it would work the same way without. Ah, but then when you go down to one variable it still works: . let . . \ a(a0) . . do-stuff-inside-let() --- 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"
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"
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. 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". 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. 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. 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. Note that the various concepts are NOT necessarily incompatible with each other - we could in theory assign different markers for ALL of them, but we would really like to reduce the number of existing rules. Pros of each: GROUP - exists in SRFI-49 (backward compatibility yeah!) - already implemented - current fallback position SPLICE - gives good syntax for Arc 'if and CL keywords (and can only be replaced with SPLIT). - BACKSLASH symbol at the end (as originally proposed) is compatible with other language's habits (consider sh and C). SPLIT - gives good syntax for Arc 'if and CL keywords (and can only be replaced with SPLICE). - subsumes both GROUP and SPLICE. ENLIST - arguably nearer to most user's intuition when encountering the "group" keyword in SRFI-49 - reduces vertical depth especially for let, the bane of indentation-based syntax. - subsumes GROUP Cons of each: GROUP - can be subsumed into either ENLIST or SPLIT SPLICE - arguably complicated rule - the BACKSLASH-at-the-end rule is arguably unrelated to the other two rules, and is a potential source of inconsistency. - not implemented SPLIT - Using BACKSLASH for this rule is incompatible with other language's habits. - Using PERIOD for this rule is incompatible arguably with general Lisp syntax. - If we can't use either BACKSLASH or PERIOD, we can't use anything for this meaning! - not implemented ENLIST - Not fully specified, possibly complicated to implement. - not implemented --- My position is: 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. Pros to my position: 1. We get good syntax for Arc 'if and CL keywords. This I think is the most important point. I feel that I cannot support a position that cannot similarly give a good syntax for Arc 'if and CL :keywords, and is my one non-negotiable. 2. Reduces the rules by removing the GROUP rule, making it a part of the overarching SPLIT rule. 3. Allows shorten
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
On 7/9/12, David A. Wheeler 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"
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:
~~
^^
--
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).
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.
--- 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 Mon, Jul 9, 2012 at 3:17 AM, David A. Wheeler 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.)
>
> Claiming "." as the "end of expression" is an interesting idea, but I don't
> think it is a good idea for Lisps. The problem is that "." already has a
> (very old) meaning; it precedes the cdr of a pair. E.G., (a . b). In cases
> where it makes sense, it'd be wise for the same operator to have the same
> meaning, or it's pretty confusing.
>
> I would expect during indentation processing that:
> a . b
> would mean the same as:
> (a . b)
>
> Thus, I don't think the following works well:
>> foo
>> :foo-stuff . exp1()
>> :bar-stuff . call the function
> because I think a reader would expect this to mean:
> (foo (:foo-stuff . (exp1)) (:bar-stuff . call...))
>
> I don't know of a Lisp spec that defines (. stuff), but interestingly, in
> practice, that usually evaluates (in the reader) as just "stuff" because of
> the way that the Lisp readers are interpreted. I'm fine with mandating that,
> if that helps; it creates an escape we can use.
>
> 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
\ = often means "continue on next line" when at eol in other languages
. = means dotted pair in normal Lisps
@ = could conflict with (!!) autoconf-standard replacement (and
de-facto standard when replacing autodetected stuff into files),
conflicts with Guile 2.0 module-access syntax
~ = 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})
>
>> 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.
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"
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.) Claiming "." as the "end of expression" is an interesting idea, but I don't think it is a good idea for Lisps. The problem is that "." already has a (very old) meaning; it precedes the cdr of a pair. E.G., (a . b). In cases where it makes sense, it'd be wise for the same operator to have the same meaning, or it's pretty confusing. I would expect during indentation processing that: a . b would mean the same as: (a . b) Thus, I don't think the following works well: > foo > :foo-stuff . exp1() > :bar-stuff . call the function because I think a reader would expect this to mean: (foo (:foo-stuff . (exp1)) (:bar-stuff . call...)) I don't know of a Lisp spec that defines (. stuff), but interestingly, in practice, that usually evaluates (in the reader) as just "stuff" because of the way that the Lisp readers are interpreted. I'm fine with mandating that, if that helps; it creates an escape we can use. So I don't like the idea of "." as "splice"; I think it's too confusing. > 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. --- 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/5/12, Alan Manuel Gloria wrote:
> existing meaning in other languages, we avoid it. Incidentally, "."
> has a meaning in general western written languages: it ends sentences.
Hmm.
%s/SPLICE/END/g
%s/GROUP/END/g
END = .
---
The "END" rule, in words:
1. Outside of an explicitly delimited list context (i.e. outside of
() [] {}), a "." surrounded by whitespace means "END the expression at
the current indentation". Any elements to the left (if any) of the
END are considered as part of the expression to the left. Any other
elements (if any) to the right of the END on the same line are
considered as part of a new expression at the same (current)
indentation. If END is at the start of a line, it's OK - the END has
no effect other than to denote indentation - succeeding elements on
the same line are put on the same expression. Multiple END markers
can exist on a single line.
2. As a side effect of the proviso of the above rule, a "." on a line
all by itself without any other elements, with a given indentation,
can be used to further indent succeeding lines:
let
.
var . fun value
var2 . fun2 value2
expr(var var2)
3. As another side effect of the proviso of rule 1, a "." at the
start of the line can be used to give the *appearance* of indentation
without giving the *actuality* of indentation:
foo
:a
. map
#'+
list-a
list-b
:b
. list-b
---
At the parser spec level, all we do is replace current meanings of
SPLICE and GROUP with END, and remove the SPLICE-at-the-eol rule.
Thoughts?
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"
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.) let . a b c d e if cond foo . expr parm cond bar . expr parm2 . expr parm3 define do-it-3() call 1 . call 2 . call 3 foo :foo-stuff . exp1() :bar-stuff . call the function foo :foo-stuff . exp1() :bar-stuff . call the function NB: this unfortunately conflicts with the ". as indentation whitespace LOL AHM IN UR WHITESPACE BEING INDENTZ" proposal. Yes, dwheeler was trolling us about it. But it's still interesting. 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"
On Wed, Jul 4, 2012 at 5:35 AM, Arne Babenhauserheide wrote: > Hi David, > >> 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. > > Personally I think that the inline \ makes it too complex. What I love about > lisp is the simplicity, and that is lost with more complex syntax rules. > > Best wishes, > Arne Inline \ is intended to support Arc if (and general Arc reduce-parenthesis habits) and CL keyword functions: if cond foo \ expr parm cond bar \ expr parm2 \ expr parm3 foo :keyword \ fun value :keyword \ fun2 value SPLICE-inline is hard to *describe*, but it enables what I feel is a pair of important use-cases. Without SPLICE-inline, you need to use twice as many lines of code. 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"
Hi David, > 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. Personally I think that the inline \ makes it too complex. What I love about lisp is the simplicity, and that is lost with more complex syntax 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"
On Mon, Jul 2, 2012 at 12:38 AM, David A. Wheeler wrote: >> 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. HUH?? It used to be! xref: from:David A. Wheeler dwhee...@dwheeler.com via lists.sourceforge.net reply-to:dwhee...@dwheeler.com to: readable-discuss@lists.sourceforge.net date:Fri, Nov 14, 2008 at 7:14 AM subject: Re: [Readable-discuss] Spliced information - any better ideas? mailing list:readable-discuss.lists.sourceforge.net Filter messages from this mailing list mailed-by: lists.sourceforge.net unsubscribe: Unsubscribe from this mailing-list > ; When condition1, dothis1, etc. are lengthy, you can do this: > if > (condition1) > \ (dothis1) > (condition2) > \ (dothis2) > (default) > > ; When condition1, dothis1, etc. are short, you can do this: > if > (condition1) \ (dothis1) > (condition2) \ (dothis2) > (default) By implication, I thought you were saying that both were supposed to be the same. so why the change? I agreed to the splice rules, as well as the GROUP = SPLICE proposal, because of this. If you're changing the meaning of GROUP from the meaning as expressed by Egil, then GROUP = SPLICE breaks. > 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? LOL. MAYBE. > > (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"
> 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"
On Sun, Jul 1, 2012 at 2:24 AM, Arne Babenhauserheide 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
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
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"
On Sat, Jun 30, 2012 at 9:06 PM, Arne Babenhauserheide wrote: > Hm, I did not even know about the splice rule. > > So, if it’s already necessary for syntax, \ would indeed be equivalent. > > I’m just used to using it for escaping special characters, so it seems > odd to me to see it on a line on its own :) > > Best wishes, > Arne > 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. 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. Sincereyl, 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"
Hm, I did not even know about the splice rule. So, if it’s already necessary for syntax, \ would indeed be equivalent. I’m just used to using it for escaping special characters, so it seems odd to me to see it on a line on its own :) 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"
dwheeler mentioned the use of "\" for the GROUP character. It happens to be the same as the SPLICE character. My initial instinct is that this is a non-breaking change, i.e. using the same character for both will not break things, as long as we remove the SPLICE-at-the-eol rule (i.e. only allow SPLICE at the start or in the middle of things). This means that the "GROUP" meaning of the character is not ambiguous with SPLICE-at-the-eol - remember, a "\" on a line by itself is either GROUP eol or SPLICE eol. On Sat, Jun 9, 2012 at 7:04 PM, Arne Babenhauserheide wrote: > Hi, > > At Wed, 23 May 2012 12:54:18 -0400 (EDT), > David A Wheeler wrote: > > > > Alpheus Madsen > > > One thought I've been wanting to experiment with, but haven't had the > time to attempt to implement, is to use a double-indent to indicate groups. > > > > I think that's even worse. It's very unreadable. It's also ambiguous > for the first indent; does "two spaces" mean an indent of two spaces, or a > double-indent for one-space indenting? > > Using double indent had also been my first idea, but I discarded it, > because the meaning of the double indent would not be obvious without the > less-indented line which comes later - it would be ambigous. > > example: > > (let > ((a b)(c d)) > (e)) > > becomes > > let >a b >c d > e > > Imagine 5 let arguments and you cannot know anymore if it’s > double-indented. > > Compare > > let > . >a b >c d > e > > The reason why I chose the . is to avoid adding any new syntax elements. . > is already used to create cons-cels, but it has little use on its own: > > (if (equal (. (quote "abc")) (quote "abc")) t) > > ; this syntax would be invalid with the .-notation. > if > equal >. > quote "abc" >quote "abc" > t > > Also I like about the . that it is so small: It is almost like double > indent, but explicit. And it scales: > > (a (b c)) > → > a > . >. > . >. > b c > > here it is explicit what happens, even though the code is evil. > > Best wishes, > Arne > > PS: Only answering now, because I we just moved, so I was overloaded for > quite some time. > > > -- > 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
Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"
Hi, At Wed, 23 May 2012 12:54:18 -0400 (EDT), David A Wheeler wrote: > > Alpheus Madsen > > One thought I've been wanting to experiment with, but haven't had the time > > to attempt to implement, is to use a double-indent to indicate groups. > > I think that's even worse. It's very unreadable. It's also ambiguous for > the first indent; does "two spaces" mean an indent of two spaces, or a > double-indent for one-space indenting? Using double indent had also been my first idea, but I discarded it, because the meaning of the double indent would not be obvious without the less-indented line which comes later - it would be ambigous. example: (let ((a b)(c d)) (e)) becomes let a b c d e Imagine 5 let arguments and you cannot know anymore if it’s double-indented. Compare let . a b c d e The reason why I chose the . is to avoid adding any new syntax elements. . is already used to create cons-cels, but it has little use on its own: (if (equal (. (quote "abc")) (quote "abc")) t) ; this syntax would be invalid with the .-notation. if equal . quote "abc" quote "abc" t Also I like about the . that it is so small: It is almost like double indent, but explicit. And it scales: (a (b c)) → a . . . . b c here it is explicit what happens, even though the code is evil. Best wishes, Arne PS: Only answering now, because I we just moved, so I was overloaded for quite some time. -- 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 Wed, May 23, 2012 at 9:54 AM, David A. Wheeler wrote: > Alpheus Madsen > > This is a problem I've thought about myself. I'm not sure if I like > Arne's solution, though, because a period is almost too small, but I would > agree that group is rather clunky too. > > Agree. > > > One thought I've been wanting to experiment with, but haven't had the > time to attempt to implement, is to use a double-indent to indicate groups. > > I think that's even worse. It's very unreadable. It's also ambiguous for > the first indent; does "two spaces" mean an indent of two spaces, or a > double-indent for one-space indenting? > > Perhaps another symbol would make sense, but that list is small. The > obvious one is "\" on a line by itself. > > --- 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"
Alpheus Madsen > This is a problem I've thought about myself. I'm not sure if I like Arne's > solution, though, because a period is almost too small, but I would agree > that group is rather clunky too. Agree. > One thought I've been wanting to experiment with, but haven't had the time to > attempt to implement, is to use a double-indent to indicate groups. I think that's even worse. It's very unreadable. It's also ambiguous for the first indent; does "two spaces" mean an indent of two spaces, or a double-indent for one-space indenting? Perhaps another symbol would make sense, but that list is small. The obvious one is "\" on a line by itself. --- 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"
This is a problem I've thought about myself. I'm not sure if I like Arne's solution, though, because a period is almost too small, but I would agree that group is rather clunky too. One thought I've been wanting to experiment with, but haven't had the time to attempt to implement, is to use a double-indent to indicate groups. For example, let group a b do-stuff would become let a b do-stuff I kindof like this solution, although I haven't experimented enough with it yet to be sure...I suspect it has its own potential pit-falls for readability, though. For one thing, the smaller the indent, the less likely it would be to be readable. I'd suspect that three spaces would be a minimal requirement, perhaps even four, although I understand that for Lispers, two-space indents are sometimes popular. Sincerely, Alphy Madsen. On Mon, May 21, 2012 at 9:56 AM, David A. Wheeler wrote: > Here's an interesting idea from Arne Babenhauserheide. > > It's a fair point. The only reason that I used "group" was because this > made it compatible with a previous proposal. > > Comments? > > --- David A. Wheeler > > > - Start Original Message - > Sent: Mon, 21 May 2012 17:11:20 +0200 > From: Arne Babenhauserheide ( arne_bab at web dot de...) > To: dwhee...@dwheeler.com > Subject: sweet expressions and group (xyzzy) > > > Dear David A. Wheeler, > > > > I read your sweet expressions work and I liked it very much - except > > for the group keyword as replacement of ((. > > > > Reason: I dabbled with expressionless-lisp myself, though only on > > paper, with elisp in mind and limited experience with other lisps > > > > What I love about indentation-sensitive programming is that it is > > possible to reduce the syntax to the bare necessities for > > understanding the code. With the group-keyword you use a pretty heavy > > identifier for (( - its actually heavier than the orgininal syntax. > > > > The alternative I came up with is a . on its own line. It is the > > syntax-element which is already used and which does not normally > > appear in front of lists. > > > > The . as infix creates a cons-cell, and it seems that it (. a) simply > > is a, so it seems nonsensical to me to use (. ( anywhere. > > > > To use the common let syntax as comparision: > > > > With groups it looks like this: > > > > let > > group > > a b > > > > With a dot it changes to: > > > > let > > . > > a b > > > > This makes the syntax much lighter for the reader while still clearly > > marking the double-brackets. > > > > but as with everything, just treat this as an idea. I really like > > your sweet-expressions work! > > > > Best wishes, > > Arne > > > > PS: I normally write in Python and love it, but I also see the power of > lisp (mainly through customizing my emacs), so I wish it were easier to > read. > > > > - End Original Message - > > > -- > 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
