Bah! Mobile gmail ate my indentation AND many newlines! Sorry.
Hope this copy is sent correctly.
Converted examples to fixed-width font to make up for the noise.
On Jan 2, 2013 7:15 PM, "David A. Wheeler" <dwhee...@dwheeler.com> wrote:
>
> Ben Booth:
> > There was an interesting language that made the rounds on reddit
/r/programming a few days ago:
> >
> > http://chrisdone.com/z/
> >
> I agree with 1337hephaestus_sc2: "The main idea seems clever, but also
too clever." A few issues:
> 1. When you have multi-parameter functions, this syntax quickly forces
you to grow vertically. This is exactly the opposite of the actual real
estate available. Screens are wide and short, and even if you use
traditional paper sizes it's wider than tall (typically 80 characters
across, ~66 lines down).
While I wouldn't use Z as is, it appeals to me for 2 reasons.
The first is excellent handling of nested lists in let:
let ! \\ ! x cos a
! ! y sin a
! do-something ...
By \\ here I mean GROUP (not SPLIT). Z doesn't have GROUP but it trivially
could [1].
I also introduced ! because I'm writing this in a variable-width font,
which is a big problem; more on this below.
This is excellent in the sense that it introduces a second level without
wasting any vertical real estate!
(This is opposite of David's observation that Z makes you grow vertically.
Both can be true - the problem is that Z is *fully normalized*, so
sometimes it's too wide and sometimes too tall, and you don't have any
leeway to trade one for the other.)
The second is symmetric treatment of args on the same line and followup
lines.
It's a point which has long bothered me about sweet-exprs, and I don't have
a concrete solution I'm happy with; but let me explain what I mean and
introduce a strawman notation as a starting point.
[BTW, I'm well aware that I'm late to the party, to express now doubts
about basics of t-expr while you guys are busy polishing the BNF. But I
didn't have time previously to write this down well, so here goes FWIW...]
The purest uses of indentation can be visually parsed in one of 2 ways,
which I'll call "header" vs "bullet".
When short on horizontal space, people resort to compromise "undent" styles.
== header ==
Body lines lie *below* the header line(s), shifted a fixed width to the
right:
defun func (arg1 arg2)
; ----------------------------
body ...
...
This style is used in most languages for control structures.
The body is usually considered a series of lines - even if newlines are not
significant, there are strong conventions to prefer one "instruction" per
line.
Python's significant indentation is all in header style.
Sweet-expressions handle this style well, allowing several args on header
line and one per
== bullet ==
All arguments lie to the *right* of the function, lined up one under the
other:
!
* ! (cos x)
! (sin x)
! 2
!
This is used in typography for bullet lists (and rare constructs like
"compact" definition lists), hence the name.
In most programming languages, this is commonly used for function calls:
func(nested1(nested, long, calls,
can, be, split),
arg2, arg3,
nested4(x, y,
z))
Splitting args to one per line is usually considered optional, a matter of
taste.
Z *always* uses this style and requires 1 arg per line.
I'm confused on whether the "offside rules" of Haskell and similar
languages support this style.
Sweet-expressions admit this style, BUT treat the first line asymetrically
from the followup lines.
1. First line can contain 0 or more args, all handled the same.
2. Followup lines are treated as 1 arg per line - mulitple args are wrapped
in a list, unless you use \\.
3. You CAN'T have the nested1 call on first line, unless you fall back to
(...) notation. I'm not sure how bad this is, but it's at the heart of the
let problem - and the loss of \\ and $ resulting from (...) use was a
motivation to employ <* .. *> there.
-- Practical issues --
Unfortunately, there are several practical issues with making bullet style
indentation meaningful and opening several levels of indentation on one
line, like func(nested1( above.
- It's harder to implement, requires parser to count columns while parsing
actual code.
- If you support unicode, zero-width and full-width CJK chars are a
problem. I don't remember how reStructuredText specced this (it's relevant
for table syntax), but it's a complication in any case.
- It's even more ambiguous and sensitive to indentation-lossage in email
etc. than "header" style of indent.
- Even when spaces are preserved, merely viewing it with PROPORTIONAL FONTS
- which most places on internet use nowdays - breaks it badly!
- Things don't line up, so the visual appeal is lost, even without nest
calls on first line.
- Nested calls one first line become very hard to decipher. It's
acceptable in most languages because you have parens, but not if all you
have is indentation.
The last point is really a deal-breaker.
Fortunately, we have ! which would allow this style to survive media like
forums and email and still be decipherable. But it gets tedious.
[In an ideal world everybody would preserve tabs, and display them
according to Elastic tabstops spec <
http://nickgravgaard.com/elastictabstops/>.
In an even better world, everybody would size leading spaces to match
corresponding letters in the less-indented line above them.
Nobody does either, so ! is our best weapon.]
== Compromise "undent" styles ==
When things get too wide, the first thing people try is convert some
"bullet" calls into "header" style:
long_function_name(
another_long_func(
bar,
)
foo,
)
But this costs vertical space, so sometimes (especially when the outer
structure has just one child), people do this:
long_function_name(another_long_func(
bar))
Now that's somewhat evil - how come bar is far to the left of (another_...
while beeing deeper than it?! Shouldn't indentation increase monotonically
with depth?
But some people are OK with it, and in some constructs it look quite
natural, especially if there are no parens to highlight the "violation":
variable = [
bar,
]
which looks really innocent compared to the fully parenthesised:
(setq variable (list
bar
))
In sweet-expressions, this is supported by $:
setq variable $ list
bar
I'd say "define (f args) $ cond" is a good example for a construct that is
acceptable with $ but too ugly with full parens.
So I'm calling it "undent(ation)", following F# which allows it in some
situations, with frightfully specific rules:
http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/spec.html#_Toc335819062
== "list" style? ==
In lisp the first element of most constructs is special, but occassionally
lists do have flat structure - within quoted data, or the list of let
clauses (what is it about let that makes it crop up everywhere?!)...
In those cases, it's customary to align all elements:
(f '(foo
bar
baz))
But I wouldn't consider this a special style, it's just a degenerate case
of "bullet" style.
Flat lists are also sometimes seen in "header" style, especially in
languages with "traditional" syntax:
x = [
foo,
bar,
]
or undented as mentioned above.
==== Strawman: A-expressions ====
Consider now a notation opposite to Z where things are *never* implicitly
grouped into lists.
I'm not proposing this is usable, only as food for thought.
In A-expressions to open a list you must use ( - from where you're in
S-expr mode - or the new operator |, which has "bullet" semantics -
everything to the right on this and followup lines is part of the list, but
division into lines doesn't matter.
So a simple long function call looks like:
| f arg1 arg2
long_arg3
arg4 arg5
Hmm, that's ugly, I want here to align under arg1!
- I can just allow superflous indentation.
- I could also follow neoteric f(args) syntax and add a postfix form of |:
f| arg1 arg2
long_arg3
arg4 arg5
In any case, the point is that all 5 arguments are handled uniformly - no
special casing of first line, no special treatment of long_arg3 because
it's alone on its line, no need for \\ between arg4 \\ arg5...
And of course I can use | many times on a line:
| let | | x | cos a
! | y | sin a
! body-of-let ...
It's tempting to unify | and ! but the difference is important - the ! do
not open a new list.
So far so good, but what about "header" style?
| defun f | a b c
; note BTW how the second | above consumes
; only a b c, not the whole body as $ a b c would do.
| cond
| condition1
| let
| | x | cos a
| y | sin a
body-of-let...
| condition2
body2...
Again, I'd like defun, cond, let to stand out better.
This would look mildly better if I allow deeper indentation than required:
; in scheme: define| f| a b c - similar to
; defun f (a b c) vs. define f(a b c)
| defun f | a b c
| cond
| condition1
| let
...
But this is merely lisp with s/(/| / and s/)//!
And all the leading | are still distracting.
What about using postfix |? I don't want the full "bullet" indent of:
defun| f | a b c
cond|
condition1|
...
It's only acceptable if I allow *shallower* indents for postfix|, as long
as its deeper than the word preceding |:
defun| f | a b c
cond|
condition1|
let|
| x| cos| a
y| sin| a
body-of-let ...
condition2|
body2...
Note that this notation provides no "undent" facility - one can compress
things such as "defun| f (a b c) cond|" or "cond| condition1|" but those
force deeper bullet-style indents on the rest.
OK, that's enough for now.
I'm starting to have concrete proposals for sweet-expressions, but that's
for a future post.
--
[1] Aside: I don't understand what's the point of Z fully currying
functions. It'd make perfect sense if "func x y" would group as "((func x)
y)" but it doesn't; moreover without GROUP the language has no way to at
all to represent a list in first position, so no way to call a curried
function!
Perhaps any multi-argument (i.e. multi-line) call is syntactic sugar for
nested lists, in which case Z does have a way to represent let ((x (cos a))
(y (sin a))):
let ! x ! cos a
! ! y sin a
! do-something ...
but that's perverted and asymmetric.
--
Beni Cherniavsky-Paskin
------------------------------------------------------------------------------
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/learnnow-d2d
_______________________________________________
Readable-discuss mailing list
Readable-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/readable-discuss
