Re: [Readable-discuss] Z language
First, a quick note: the Haskell offside rule works because it triggers on specific keywords (e.g., do, let, of, and where). I think it's important for a *Lisp* that the semantics be *general* and not tied to a semantic, as I've explained further elsewhere, so I don't think that approach is a good one as-is for a Lisp. Beni Cherniavsky-Paskin had an interesting post about a completely different approach, but as both he and Alan Manuel Gloria have noted, that alternative has some serious problems. E.G.: Alan Manuel Gloria: Here's an even bigger deal-breaker: it makes parent structures harder to modify, because if the length of the parent is changed (for example inserting an argument you forgot in the first pass of writing the code, or modifying an existing function to accept a new argument, or adding some logging code, or whatever) then you have to re-indent all the children. ... ... In Common Lisp, | is used to denote symbols with special syntax, i.e. (symbol foo bar) = |foo bar|. ... Supporting | defun foo | a b requires knowing how wide characters are (CJK width problem), ... I separately noted that this approach won't work with varying-width fonts at all (and many email systems display with them!). Beni Cherniavsky-Paskin later posted: I actually don't like it much :-) It was interesting to me as simplest thing that could possibly work, but: - I actually do like the auto-listification of foo bar. Having to prepend each line with | would annoy me... I still wish for a way to make a bullet-style call or list where the first line is handled like the others. Though not exactly what you asked for, sweet-expressions currently have something that might make you happier. Fundamentally \\ as the first marker just means nothing, but use this position as the indent level, so you can already do this in sweet-expressions: f \\ a \\ b \\ c == (f a b c) You can even do that at the top level: \\ a \\ b \\ c == a b c This works in the current prototype implementation (unsweeten) and the new BNF (implemented with ANTLR). We envisioned using this for *distinguishing* elements that were at the same list level but were in fact different, such as Arc's if statement: if condition1 \\ action1 condition2 \\ action2 elseaction But it could be used this other way instead if you wanted to. --- 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/learnnow-d2d ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
Re: [Readable-discuss] Z language
[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
Re: [Readable-discuss] Z language
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.
Re: [Readable-discuss] Z language
On 1/24/13, Beni Cherniavsky-Paskin c...@users.sf.net wrote:
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).
Perhaps it can be mitigated by the simple expedient of disabling
indentation processing in parentheses.
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.
Offside rule simply looks at the column of the first non-{ token after
keywords do, let, of, and where, and memorizes that column,
inserting the missing {. Tokens starting at that column will have a
; inserted before it (basically, ending the previous expression),
and tokens starting at columns to the left of the off-sided column
will end the off-siding (inserting a } to end it).
So for example:
do ! x
! y
bar
Gets translated to:
do ! {x
! ;y
}bar
So basically, Haskell implicitly supports the bullet style, but can
admit the header style.
In practice, most Haskell code is in header style.
*Technically* the name of the rule offside refers to the fact that
inner elements should be to the *to the side of and below* their
parent keyword (i.e. think a strict combination of the bullet and
header). The requirement to be to the side was relaxed in Miranda
(and eventually Haskell), but the rule remained offside.
By my memory the original offside rule (below and to the right,
strictly) is the first time that anyone formalized indentation-based
program organization.
In practice, Haskell can support either header or bullet because
only some keywords support indentation formatting(function
applications in Haskell *must* be grouped by parens or infixes, so you
can't use indent to denote boundaries of function
Re: [Readable-discuss] Z language
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 ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
