[forgot mailing list in reply, yet again]
On 1/3/13, Ben Booth <benwbo...@gmail.com> wrote: > There was an
interesting language that made the rounds on reddit > /r/programming a few
days ago: > > http://chrisdone.com/z/> > Reddit discussion page: > >
http://www.reddit.com/r/programming/comments/15r6tb/z_a_tiny_strict_impure_dynamically_typed_curried/>
> It's an indentation-based lisp-like language,
although the indentation rules > differ somewhat from sweet-expressions. It
also features a macro system that > actually parses its own input and
outputs a string that gets re-parsed.
Eww. String-based macros make me worry: look at what infelicities it does
to C! Granted, C's macros are not Turing-complete, and Z's at least are,
but processing text seems to be a step backward.
> The > language uses Haskell/Parsec for parsing and evaluation, so it
might be > interesting to compare that approach with the ANTLR-based
grammar.
Hehehe...
------------------------------------------------------------------------------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. SALE $99.99 this month only
-- learn more at: http://p.sf.net/sfu/learnmore_122812
▶ Show quoted text
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:
| defun f | a b c ; in scheme: define| f| a b c - cf. 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.
------------------------------------------------------------------------------
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
