Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"

2012-07-19 Thread Kartik Agaram
> 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"

2012-07-18 Thread David A. Wheeler
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"

2012-07-18 Thread David A. Wheeler
- 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"

2012-07-18 Thread David A. Wheeler
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"

2012-07-18 Thread Alan Manuel Gloria
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"

2012-07-18 Thread Alan Manuel Gloria
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"

2012-07-18 Thread Kartik Agaram
> "." 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"

2012-07-18 Thread Alan Manuel Gloria
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"

2012-07-18 Thread Alan Manuel Gloria
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"

2012-07-18 Thread Kartik Agaram
> 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"

2012-07-18 Thread Kartik Agaram
> \
> . 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"

2012-07-18 Thread Kartik Agaram
> > 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"

2012-07-18 Thread Alan Manuel Gloria
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"

2012-07-18 Thread Kartik Agaram
> 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"

2012-07-18 Thread Alan Manuel Gloria
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"

2012-07-18 Thread David A. Wheeler
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"

2012-07-18 Thread David A. Wheeler
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"

2012-07-18 Thread David A. Wheeler
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"

2012-07-18 Thread David A. Wheeler
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"

2012-07-18 Thread Alpheus Madsen
>
> 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/
".

define solve-kalotan-puzzle
  lambda []
let
  group
parent1 amb('m 'f)
parent2 amb('m 'f)
kibiamb('m 'f)
kibi-self-desc  amb('m 'f)
kibi-lied?  amb(#t #f)
  assert
   distinct?(list(parent1 parent2))
  assert
   if eqv?(kibi 'm)   not(kibi-lied?)  assert   if
kibi-lied?  xor{eqv?(kibi-self-desc 'm) and
eqv?(kibi 'f)}{eqv?(kibi-self-desc 'f) and eqv?(kibi 'm)}
assert   if not(kibi-lied?)  xor
{eqv?(kibi-self-desc 'm) and eqv?(kibi 'm)}
{eqv?(kibi-self-desc 'f) and eqv?(kibi 'f)}  assert   if
eqv?(parent1 'm)
  and
eqv?(kibi-self-desc 'm)xor
{eqv?(kibi 'f) and eqv?(kibi-lied? #f)}
 {eqv?(kibi 'm) and eqv?(kibi-lied? #t)}  assert
if eqv?(parent1 'f)
  {eqv?(kibi 'f) and eqv?(kibi-lied? #t)}
  list(parent1 parent2 kibi)
solve-kalotan-puzzle()

I'll try it with whitespace-enabled parentheses:

define solve-kalotan-puzzle
  lambda []
let(parent1   

Re: [Readable-discuss] Arne Babenhauserheide proposal: use "." on own line instead of "group"

2012-07-18 Thread 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.

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"

2012-07-18 Thread Alpheus Madsen
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"

2012-07-18 Thread Alpheus Madsen
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"

2012-07-15 Thread David A. Wheeler
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"

2012-07-15 Thread Alan Manuel Gloria
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"

2012-07-15 Thread David A. Wheeler
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"

2012-07-15 Thread Alan Manuel Gloria
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"

2012-07-13 Thread Arne Babenhauserheide
> > 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"

2012-07-12 Thread Alan Manuel Gloria
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"

2012-07-12 Thread David A. Wheeler
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"

2012-07-12 Thread Arne Babenhauserheide
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"

2012-07-12 Thread Arne Babenhauserheide
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"

2012-07-12 Thread David A. Wheeler
> 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"

2012-07-11 Thread Alan Manuel Gloria
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"

2012-07-11 Thread David A. Wheeler
- 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"

2012-07-11 Thread David A. Wheeler
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"

2012-07-11 Thread Alan Manuel Gloria
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"

2012-07-08 Thread Alan Manuel Gloria
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"

2012-07-08 Thread David A. Wheeler
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"

2012-07-08 Thread Alan Manuel Gloria
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"

2012-07-08 Thread David A. Wheeler
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"

2012-07-04 Thread Alan Manuel Gloria
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"

2012-07-04 Thread Alan Manuel Gloria
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"

2012-07-03 Thread Alan Manuel Gloria
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"

2012-07-03 Thread Arne Babenhauserheide
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"

2012-07-01 Thread Alan Manuel Gloria
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"

2012-07-01 Thread David A. Wheeler
> 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"

2012-06-30 Thread Alan Manuel Gloria
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"

2012-06-30 Thread David A. Wheeler
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"

2012-06-30 Thread Arne Babenhauserheide
> 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"

2012-06-30 Thread Alan Manuel Gloria
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"

2012-06-30 Thread Arne Babenhauserheide
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"

2012-06-29 Thread Alan Manuel Gloria
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"

2012-06-09 Thread Arne Babenhauserheide
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"

2012-05-23 Thread Alpheus Madsen
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"

2012-05-23 Thread David A. Wheeler
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"

2012-05-22 Thread 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.

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