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
On Jan 23, 2013 11:03 PM, "Alan Manuel Gloria" wrote:
>
> 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 arguments).
>
Thanks for the explanation.
> >...
> 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.
>
Indeed. This doesn't prevent it being used in languages with parens, but
those allow you to edit freely and then have the editor fix the indentation.
I agree now that opening several levels on same line - let's call this
"bullet bullet" - is too fragile and a bad idea.
(This wasn't obvious to me a couple days ago when I started that long
mail...)
But I still
> This is the main reason why Miranda and Haskell relaxed the "to the
> right" part of the original offside rule.
>
> > And of course I can use | many times on a line:
> >
> > | let | | x | cos a
> > ! | y | sin a
> > ! body-of-let ...
>
> Err I think this would be better off as:
>
> > | let | | x | cos a
> > ! ! | y | sin a
> > ! | body-expr-of-let
> > ! | body-expr-of-let-2
>
> what you think?
>
Absolutely, the "! body-of-let" in my example was wrong.
> > 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.
>
> And it's not half-bad IMO, actually.
>
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 think my proposal of postfix "foo| bar" was mostly a way to hide from
this fact...
- There is no way to undent (without $).
> I take it that postfix f| means something like n-expression f(?
>
> So:
>
> define| f| a b c
> body| x
>
> ==>
>
> define( f( a b c ) ; closing parens inserted
> body( x ) ; closing parens inserted
> ) ; closing parens inserted
>
> ==>
>
> (define (f a b c)
> (body x)
> )
>
Yes, precisely.
For some reason the "foo|" == "| foo" equivalence feels very cheap to me,
more so than "foo(" == "(foo". Probably because "foo(x)" is already a
familiar syntax.
> --
>
> Practical problems:
>
> 1. In Common Lisp, "|" is used to denote symbols with "special
> syntax", i.e. (symbol "foo bar") => |foo bar|.
>
Yeah, I remembered that minutes after sending the mail.
Anyway, this was just an exercise.
> 2. Supporting "| defun foo | a b" requires knowing how wide
> characters are (CJK width problem), especially if you can do something
> like:
>
> | defun foo | &key
> | ! | var1 | default-value 'var1
> ...
>
Yeah. I'm giving up on "bullet bullet" which requires char counting.
I still wish for a way to make a bul
Re: [Readable-discuss] Z language
On 1/24/13, Beni Cherniavsky-Paskin 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" 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(functio
Re: [Readable-discuss] Z language
Beni Cherniavsky-Paskin: > 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. Very different approach, thanks for posting. I think your list of the *problems* of the bullet approach puts the nail in that coffin quite convincingly. For example, in a world with proportional fonts, it doesn't make sense to create a notation that's impractical to use with them. Also, A-expressions don't look all that usable at this early stage of maturity, and more importantly, it's not clear to me that people would easily grok their meaning (are they "readable"?). Granted, people can learn anything if they must, but I'd like for the resulting code to have an "obvious meaning" if well-formatted. But that doesn't mean that the notation can't be improved, or that we can't learn from them. It'd be nice to see some examples of longer/useful functions written in this different notation, or whatever notation you come up with. I created a long list of functions, from many different Lisp notations, when creating sweet-expressions to make sure that it would have good results in typical use. Also, please make them easy to read on a mail reader that strips initial whitespace. To be honest, I'm really *happy* and *excited* about sweet-expressions as currently defined in the latest BNF. But if there's a better alternative, now would be the time to raise it. --- 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
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" 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. F
Re: [Readable-discuss] Z language
[forgot mailing list in reply, yet again] On 1/3/13, Ben Booth 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" 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 emplo
Re: [Readable-discuss] Z language
On 1/3/13, Ben Booth 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
Re: [Readable-discuss] Z language
Ben Booth: > 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. The > language uses Haskell/Parsec for parsing and evaluation, so it might be > interesting to compare that approach with the ANTLR-based grammar. Thanks so much for the pointer! I'll add a note about it in the draft SRFI. Focusing on the Z syntax, its syntax is simple: 1. A whitespace-separated sequence of terms applies to the next, so: foo bar mu zot would parse (in s-expression form) as: (foo (bar (mu zot))) 2. "To pass additional arguments to a function, the arguments are put on the next line and indented to the column of the first argument" 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). 2. Edits in one line could quietly change the meaning of other lines, in non-obvious ways. If you edit a line with children, you have to make sure that the lines that follow are moved as well. An IDE can do this, of course, but it's concerning if an IDE is a practical necessity. E.G., if you started with: fee fie foe fum foo bar and changed "fie" to "faction", fee fie faction fum foo bar which changes the meaning. 3. I suspect is that it's *especially* easy to make a mistake with this notation in a lisp. Writing "cons a b" would seem reasonable enough, but would be interpreted as (cons (a b)). Languages --- 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 ___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
[Readable-discuss] Z language
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. The language uses Haskell/Parsec for parsing and evaluation, so it might be interesting to compare that approach with the ANTLR-based grammar. Ben-- 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___ Readable-discuss mailing list Readable-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/readable-discuss
