```On 1/17/13, Alan Manuel Gloria almkg...@gmail.com wrote:
On 1/17/13, David A. Wheeler dwhee...@dwheeler.com wrote:
Personally I'm not (yet?) a big fan of \$.

Not a problem.  It's grown on me.  Once you have it, you find that
patterns
where it applies are remarkably common.

(^^)v

In support of that, consider the following:

(cond
(( x -1) (* x x))
(( x 1) (* x x))
(( x 0) (sqrt (abs x)))
(else (sqrt x)))

..without \$, we'd have to use:

cond
( x -1)
* x x
( x 1)
* x x
( x 0)
sqrt (abs x)
else
sqrt x

...with \$:

cond
( x -1) \$ * x x
( x 1) \$   * x x
( x 0) \$ sqrt \$ abs x
else \$ sqrt x

...which is a lot nearer to the original s-expression.  The only
caveat is that in this form, \$ is followed by a *single* expression,
but if you're using multiple expressions, you should really be using
indentation anyway.

(admittedly, you can also just retain the parentheses, but every
parenthesis cuts the power of t-expressions, because parentheses
disables stuff.)

Here's a better example of the intended use of \$:

import \$ srfi srfi-45
import \$ amkg object

; use for debugging
define probe(x)
print(x)
x

define lazy-construct(a d)
lazy \$ probe \$ let ((rv #f))
set! rv \$ object-construct 'cons-cell
object-method-register rv
'car \$ lambda () a
'set-car! \$ lambda (na) \$ set! a na
'cdr \$ lambda () d
'set-cdr! \$ lambda (nd) \$ set! d nd
rv

--

I feel \$ is a really good balance of something-weird (con) but
extremely useful (pro).

Sincerely,
AmkG

--
Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and
much more. Get web development skills now with LearnDevNow -
350+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
http://p.sf.net/sfu/learnmore_122812
___

```

```On 1/16/13, David A. Wheeler dwhee...@dwheeler.com wrote:
Alan Manuel Gloria:

Okay, the *semantics* is confusing to me.

How are the following suppose to parse?

The answer is, whatever we decide it should be :-).  So now is a perfect
time to discuss it.  And if some combination seems to be nonsense, we can
declare it an error.

BTW, Don't pay serious attention to the sweet.g file's action statements for
restart_list.  I'm doing a lot of experiments with them and they're almost
certainly wrong right now.  So with that caveat...

library foo
* begin

define cat 'meow

define dog 'woof

*

I assume:

(library foo
(begin
(define cat 'meow)
(define dog 'woof)
)

Yes, that's what I think too.

But that's if we allow same-line and later-lines simultaneously at *all*.
My current draft BNF *does* allow this (by intent), but if the semantics are
too complicated, we could just say either (1) it must be all on one line, or
(2) the start has to be followed by hspace* comment_eol.

But let's continue the thought...

But what happens with this?

library foo
* begin print(x)

define cat 'meow
define dog 'woof

*

To be honest, I don't know of a use case that suggests any particular
semantic.  I can image that this *might* mean:

(library foo
(begin
(print x)
(define cat 'meow)
(define dog 'woof)))

Though perhaps other semantics would make sense.

let * x 5 * { x + 42 }

I think t that should mean:
(let ((x 5)) (+ x 42)

Basically, *...* wraps an extra () around an expression. Since x 5 means
(x 5), * x 5 * == ((x 5)).  And since what follows *...* is just
another parameter, that parameter should be treated normally.

Or worse, this?

let *x y
w z *
42

I'm guessing that should perhaps be:
(let (x y (w z)) 42)

Perhaps we'd better off to not allow stuff to be on both the same line and
on later lines, at least at first.  The library definition use case and
the let use case are easily distinguished that way.  That might mean you'd
have a multi-line statement with a begin on its own line, but if it's a
long sequence of definitions, that may not be a big deal.

Okay here's the concrete semantics I propose:

1.  The head production is the part that looks for the *.  Upon
finding a *, it consumes any number of horizontal spaces, line
production

2.  superlist just calls the top-level i_expr repeatedly, creating
a list of items, and terminating upon finding a *, returning the
yielded list.

3.  When superlist returns, head just takes its returned value and
takes it as a single item, and continues on its merry way looking for
n-expressions and superlists after the *.

The third part allows:

let * x 5 \\ y 6 * {x + y}

You know, maybe we should call it SUPERLIST in contrast with SUBLIST.
^^;;;

You're smiling, but that's not an entirely insane name.  It's hard to think
of a good name for this.

MEGALIST
UBERLICHST

Sincerely,
AmkG

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
http://p.sf.net/sfu/learnmore_122612
___

```

```On Jan 16, 2013 3:29 PM, David A. Wheeler dwhee...@dwheeler.com wrote:

If we separate the 2 issues, I feel the no-blank-lines is the more
problematic of them.  In Python, I'm fine with most of my defs being
indented because they're class methods, but couldn't live without new
lines.
Do you agree?

I don't *exactly* agree, though you may be missing an element of
sweet-expressions that makes end-on-blank-lines work.   But first, my
priorities.

My current view is that the more important requirement is that the REPL
and file format need to be exactly the *same* in a Lisp-based system. In
Python you often cannot cut-and-paste from files into the command line
(REPL), because Python files and the REPL have different blank-line
semantics.  (Technically, the Python spec only covers files, but that's a
useless nuance.)  That's actually a problem in Python today, and annoys me
sometimes.  In a Lisp such a difference would be crazy, because Lisps are
programmable programming languages where experimentation is common.

I'll defer to you on this though I don't feel this is such a big problem in
python; GUI shells solve it by distinguishing pressing Enter from pasting
Enter, and/or by requiring ctrl+Enter (or backspacing the indent then
Enter) to terminate multiline command (IIRC dreampie does the latter).
Unfortunately, lisp doesn't have python's : hint that the expression will
be a multiline one.

It's indeed annoying in the terminal.  IIRC ipython has some magic %paste
syntax to paste an arbitrary block.  IOW, the file/repl tension does
justify a construct like this, but it's a REPL only construct...

Now for blank lines.  Blank lines ending an expression actually isn't
bad, even in a larger program, because of the rule that comment-only lines
(possibly indented) are completely ignored, and do NOT end an expression.
I agree that without that rule it'd be hideous to use, but using
comment-only lines to vertically separate material actually works very
cleanly.

Ah, indeed I missed that!
It changes a lot of priorities in my arguments, because if I'd keep the
indentation and only use this for empty lines, that feels a  petty -
perhaps I should just live with empty comments and not need a new construct
at all; and let people who also want to reset indentation have their way...

It's not insane to use some marker to mean end of expression, several
languages do that.  Indeed, sweet-expressions could be modified to that
easily enough.  But then users have to remember to do that after every
expression.  If REPL use is rare, that'd be fine.  But I expect lots of
people to use the REPL, often, and I want the REPL to be very pleasant to
use.  It's hard to beat enter a blank line to evaluate.

Agreed.  I absolutely hate SQL prompts that don't execute until I add a ;

Well, the current notation is obviously not a disaster, since we've
written programs without it.  But when the variables involve modest amounts
of calculation, it gets harder to see what you're doing than I'd prefer,
because it's easy to suddenly require more paren-nesting than is typical in
other languages.

Contrast:

let ((x cos(f(c
! dostuff x

with:
let * x cos(f(c)) *
! dostuff x

In one-variable lets, a common mistake is to forget to embed the variable
in double-parens.  Since the parens are also usually used for the
expression calculation, it can be easy to miss.  Making it possible to
visually distinguish the outer parens that create the variable list, from
the internal parens used for the expression, makes it clearer which parens
are more structural vs. the ones involved in the variable calculation.
That, in turn, makes it easier to notice the omission of doubled parens for
one variable.

* is 2 chars, (( is 2 chars.  Some of your win here is just from using
spaces to set apart the delimiters.
Isn't this better addressed by schemes that allow [..] in place of (..):

let [ (x cos(f(c)))
(y sin(f(c))) ]
! dostuff x y

which is more homoiconic by preserving the nesting level.
I feel that let's structure is truly annoying, but it's not the notation's
job to hide that if it becomes less homoiconic; I'd rather fix the
construct and use a let1 macro.

or:
let * x \$ cos \$ f c *
! dostuff x

Personally I'm not (yet?) a big fan of \$.
I have even more reservations about \\ usage:
let * x cos(f(c)) \\ y sin(f(c)) *
where the list depth hinges on the fact that there are 2 elements between
the \\.

I see how such constructs are appealing in-line once you're used to them,
but this makes me ask: could you lift \$ and/or \\ to a separate layer from
indent processing, so they remain available inside regular (..) lists?

As it turns out, the new ruleset for *...* that I just posted is quite
simple, and it basically only requires one extra line in the spec to handle
the on-the-same-line case.

I must admit I haven't even tried to keep up with your grammar work.  I'll
try to take a look - the whole thing is much shorter than the ```

```Beni Cherniavsky-Paskin:
* is 2 chars, (( is 2 chars.  Some of your win here is just from using
spaces to set apart the delimiters.
Isn't this better addressed by schemes that allow [..] in place of (..):

let [ (x cos(f(c)))
(y sin(f(c))) ]
! dostuff x y

which is more homoiconic by preserving the nesting level.
I feel that let's structure is truly annoying, but it's not the notation's
job to hide that if it becomes less homoiconic; I'd rather fix the
construct and use a let1 macro.

I agree that let's structure in the 1-variable case is annoying (I also
sometimes use a let1 macro), and I agree that it's not a notation's job to
*hide* annoying structures.

But if a structure is common and annoying to *use*, it's reasonable to look for
notations that make it *easier* to use.  Hiding bad, ease-of-use good :-).

Personally I'm not (yet?) a big fan of \$.

Not a problem.  It's grown on me.  Once you have it, you find that patterns
where it applies are remarkably common.

I have even more reservations about \\ usage:
let * x cos(f(c)) \\ y sin(f(c)) *
where the list depth hinges on the fact that there are 2 elements between the
\\.

I see how such constructs are appealing in-line once you're used to them,

I think that's the key point.  It needs to be easy for people to mentally map a
construct to the underlying list structure, of course, but after a while, you
learn that certain visual patterns are the easy way to use a construct.  The
same thing happens in other languages; I read the following C construct:
for (i=0; i  max; i++) ...
as a single trivial idea, because it's such a common pattern.

but this makes me ask: could you lift \$ and/or \\ to a separate layer from
indent processing, so they remain available inside regular (..) lists?

Sure, that's possible.  But do we *want* to?
1. That would mean that you'd have to escape them even inside (...).
2. It mildly interferes with backwards compatibility.  I'd like traditional
code to mostly work as is - in a backward-compatible way - if it's cleanly
formatted.  Programs that use symbols \$ or \\ would then have problems.
3. I'd like to be able to call down to the underlying reader as much as
possible to implement constructs; doing this *requires* that we override
processing the contents of a list, even if it already has a curly-infix reader.

I must admit I haven't even tried to keep up with your grammar work.  I'll
try to take a look - the whole thing is much shorter than the one-at-a-time

Thanks!

I'm not against having a way to restart indentation; I just wanted to keep
the *option* to not restart it to 0, as a matter of taste.
Though in light of empty comments always being available, I'm ok with a
construct that always forces indent to 0, if it's simpler.

It's much simpler.  There are some nasty subtleties in *starting* with a
non-zero indent and trying to make it mean the obvious in a Lisp-based
language; see the draft SRFI for more details if you're curious.  It could work
in other languages, but in Scheme, it's hard because (1) the read interface
of Scheme is already fixed, and (2) standard Scheme doesn't support unlimited

Sure, it must be multi-char.  I was think more in the directions of e.g. #(
... )# but those might well be taken for things like vectors.

Yes, #( introduces a vector comment.  And # is busy enough; there are a lot
of nonstandard Scheme extensions that start with #, so anything starting with
# is frankly not safe for use (it'd probably conflict with SOMETHING).

Another very unbaked idea: perhaps we can take a hint from typography and
formats such as reStructuredText, markdown and emacs outline-mode (which
all took that hint):
Represent most structure using indentation, but some structure above that

Not a crazy idea, but that would only deal with the case for multi-line that
begins on the left edge.  That wouldn't deal with the small let case, or
anything that has some simple prefix.  I know you don't care about short let,
but *I* do :-).

I think like this direction on aesthetic grounds, but I suspect the
practical convenience of having some reader macro entering the t-expr
parser in the middle of s-expr parsing will prevail.

Yes, that's my thinking too.

--- David A. Wheeler

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___

```

```On 1/17/13, David A. Wheeler dwhee...@dwheeler.com wrote:
(library
(amkg animals (1 0))
(export cat (rename (rover dog)))
(import (only (amkg pets (1 0)) rover))
(define cat (quote meow)))

Is that what you expected?

Yes ^^

On 1/17/13, David A. Wheeler dwhee...@dwheeler.com wrote:
Personally I'm not (yet?) a big fan of \$.

Not a problem.  It's grown on me.  Once you have it, you find that patterns
where it applies are remarkably common.

(^^)v

I'm not against having a way to restart indentation; I just wanted to
keep
the *option* to not restart it to 0, as a matter of taste.
Though in light of empty comments always being available, I'm ok with a
construct that always forces indent to 0, if it's simpler.

It's much simpler.  There are some nasty subtleties in *starting* with a
non-zero indent and trying to make it mean the obvious in a Lisp-based
language; see the draft SRFI for more details if you're curious.  It could
work in other languages, but in Scheme, it's hard because (1) the read
interface of Scheme is already fixed, and (2) standard Scheme doesn't

*Technically* R5RS and R6RS don't support unread-char, at all.
However, most implementations of Scheme support some kind of
So we have adopted the limitation of requiring only 1 character

Another very unbaked idea: perhaps we can take a hint from typography and
formats such as reStructuredText, markdown and emacs outline-mode (which
all took that hint):
Represent most structure using indentation, but some structure above that

Not a crazy idea, but that would only deal with the case for multi-line that
begins on the left edge.  That wouldn't deal with the small let case, or
anything that has some simple prefix.  I know you don't care about short
let, but *I* do :-).

An interesting idea IMO.  Hmm.

I think like this direction on aesthetic grounds, but I suspect the
practical convenience of having some reader macro entering the t-expr
parser in the middle of s-expr parsing will prevail.

Yes, that's my thinking too.

--- David A. Wheeler

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___

--
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
___

```

```Okay, I've tried to write down my thoughts on WHY I think restart lists are a
good idea.

Comments welcome.  A better name is welcome for sure :-).

BTW, I have a draft BNF and action rules, but don't take them seriously for
restart lists; I used them more for experimentation.

--- David A. Wheeler

h2 id=reservedRestart lists (lt;* ... *gt;)/h2
p
Sweet-expressions without restart lists (lt;* ... *gt;)
work well in a vast number of circumstances.
However, they can be somewhat awkward for two typical use cases:
/p
ol
liA long sequence of definitions contained within an initial statement.
This situation occurs in many library definition structures such as
Scheme R7RS ttdefine-library/tt and in some larger data structures./li
liA let-style statement with one or two variables
with short initial values./li
/ol
p
Let's begin with the first use case.
When there is a long sequence of definitions contained within an
initial statement, and no special notation like restart lists,
all the definitions in the long sequence must be
indented and none can be separated by a blank line
(since that would end the entire sequence, not just a definition).
Indenting almost an entire file is annoying, and needing no blank lines
for that long invites mistakes.
/p

p
For example, here's an example from the R7RS Scheme specification
for define-library:
/p
pre
(define-library
(example grid)
(export make rows cols ref each (rename put! set!))
(import (scheme base))
(begin
(define (make n m)
(let ((grid (make-vector n)))
(do ((i 0 (+ i 1)))
((= i n) grid)
(let ((v (make-vector m #f alse)))
(vector-set! grid i v)
(define (rows grid) (vector-length grid))
(define (cols grid)
(vector-length (vector-ref grid 0)))
(define (ref grid n m)
(and ( -1 n (rows grid))
( -1 m (cols grid))
(vector-ref (vector-ref grid n) m)))
(define (put! grid n m v)
(vector-set! (vector-ref grid n) m v
/pre
p
This is easily reformatted into this sweet-expression:
/p
pre
define-library
example grid
export make rows cols ref each rename(put! set!)
import scheme(base)
begin
define make(n m)
let (grid(make-vector(n)))
do (i(0 {i + 1}))
! {i = n} grid
! let (v(make-vector(m #f alse))) vector-set!(grid i v)
define rows(grid) vector-length(grid)
define cols(grid) vector-length(vector-ref(grid 0))
define ref(grid n m)
and
{-1  n  rows(grid)}
{-1  m  cols(grid)}
vector-ref vector-ref(grid n) m
define put!(grid n m v) vector-set!(vector-ref(grid n) m v)
/pre

p
But there are reasons that sweet-expressions are defined the way they are.
It is fundamental that a child line is indented from its parent, since
that is the point of indentation.
Opening a parentheses intentionally disables indentation processing;
this is what developers typically expect (note that both Python and
SRFI-49 do this), and it also makes sweet-expressions very
Ending a definition at a blank line is very convenient for interactive use,
and interactive and file notation should be identical
(since people often switch between them).
Changing all of sweet-expressions, just to handle this particular case,
does not seem warranted.
/p

p
Now let's look at the second use case.
The sweet-expression notation cleanly handles cases where let-expression
variables have complex values (e.g., using \\), but for simple cases
(1-2 variables having short initial values)
it can take up more vertical space than traditional formatting.
Using a leading \$ takes up somewhat less vertical space, but it still
takes up an additional line for a trivial case, it does not work
the same way for let expressions with 2 variables,
and David A. Wheeler thinks it is a rather unclear construction.
You can also use parenthetical notation directly, but this is
relatively ugly and it is annoying to need to do this for a common case.
A similar argument applies to do-expressions, and these are
not at all unusual in Scheme code:
/p
pre
let  ; Using \\ takes up a lot of vertical space in simple cases
\\
x 5
{x + x}

let
\\
x 5
y 7
{x + x}

let  ; Less vertical space, but 1 variable only
\$ x 5
{x + 5}

; Note \$ x 5 \$ y 7 isn't right; that maps to ((x 5 (y 7))).

; The two-variable format can be surprising and does not let the
; programmer emphasize the special nature of the variable assignments
; (compared to the later expressions in a let statement).
let
x(5) y(7)
{x + 5}

let (x(5)) ; Use parentheses
{x + x}
let (x(5) y(7))
{x + x}
/pre

p
A irestart list/i is surrounded by the markers lt;* and *gt;.
The lt;* and *gt; represent opening and closing
parentheses, but restart indentation processing
at the left edge instead of disabling indentation processing.
The purpose of restart lists is to make it easy to clearly
express these and similar use cases.
/p

```

```The bit: ; Note \$ x 5 \$ y 7 isn't right; that maps to ((x 5 (y 7))).

..should be better placed in a paragraph - I for one tend to skim over
source code in the SRFI.

--

The bit: Changing all of sweet-expressions, just to handle this particular case,
does not seem warranted.

...this doesn't seem to scan well.  It seems to introduce an argument
to support a position (don't change all of sweet-expressions) but the
paragraph it's in doesn't look like it introduces the opposing
position.

--

You might want to juxtapose:

let
\\
x \$ foo bar
use x

versus:

let * x \$ foo bar *
use x

I suggest you use something similar to what you did in
readable.sourceforge.net: use a table so that both examples are
side-by-side.

I also suggest using the given example above rather than (let ((x 5))
(+ x x)), since it gives a better justification for using RESTARTBEGIN
/ RESTARTEND : We want to use foo bar not foo(bar) for stylistic
reasons (i.e. foo is a command whose return status we want to know,
not a function that just computes something).

--

This bit:   begin lt;*

Looks wrong.  Shouldn't that be: lt;* begin ??

Of course, it depends on what, exactly, is meant by * *.  So maybe:
begin . * ??

Sincerely,
AmkG

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
http://p.sf.net/sfu/learnmore_122612
___

```

```Okay, the *semantics* is confusing to me.

How are the following suppose to parse?

library foo
* begin

define cat 'meow

define dog 'woof

*

I assume:

(library foo
(begin
(define cat 'meow)
(define dog 'woof)
)

But what happens with this?

library foo
* begin print(x)

define cat 'meow
define dog 'woof

*

let * x 5 * { x + 42 }

Or worse, this?

let *x y
w z *
42

Sincerely,
AmkG

P.S.
You know, maybe we should call it SUPERLIST in contrast with SUBLIST. ^^;;;

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
http://p.sf.net/sfu/learnmore_122612
___

```

```Alan Manuel Gloria:

Okay, the *semantics* is confusing to me.

How are the following suppose to parse?

The answer is, whatever we decide it should be :-).  So now is a perfect time
to discuss it.  And if some combination seems to be nonsense, we can declare it
an error.

BTW, Don't pay serious attention to the sweet.g file's action statements for
restart_list.  I'm doing a lot of experiments with them and they're almost
certainly wrong right now.  So with that caveat...

library foo
* begin

define cat 'meow

define dog 'woof

*

I assume:

(library foo
(begin
(define cat 'meow)
(define dog 'woof)
)

Yes, that's what I think too.

But that's if we allow same-line and later-lines simultaneously at *all*.  My
current draft BNF *does* allow this (by intent), but if the semantics are too
complicated, we could just say either (1) it must be all on one line, or (2)
the start has to be followed by hspace* comment_eol.

But let's continue the thought...

But what happens with this?

library foo
* begin print(x)

define cat 'meow
define dog 'woof

*

To be honest, I don't know of a use case that suggests any particular semantic.
I can image that this *might* mean:

(library foo
(begin
(print x)
(define cat 'meow)
(define dog 'woof)))

Though perhaps other semantics would make sense.

let * x 5 * { x + 42 }

I think t that should mean:
(let ((x 5)) (+ x 42)

Basically, *...* wraps an extra () around an expression. Since x 5 means (x
5), * x 5 * == ((x 5)).  And since what follows *...* is just another
parameter, that parameter should be treated normally.

Or worse, this?

let *x y
w z *
42

I'm guessing that should perhaps be:
(let (x y (w z)) 42)

Perhaps we'd better off to not allow stuff to be on both the same line and on
later lines, at least at first.  The library definition use case and the
let use case are easily distinguished that way.  That might mean you'd have a
multi-line statement with a begin on its own line, but if it's a long
sequence of definitions, that may not be a big deal.

You know, maybe we should call it SUPERLIST in contrast with SUBLIST.
^^;;;

You're smiling, but that's not an entirely insane name.  It's hard to think of
a good name for this.

--- David A. Wheeler

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.