Some similarities to TCL. TCL’s core syntax is COMMAND ARGS and ’ “ and { are ways of quoting. You can trivially define new control structures. One of my favorites was defining how functions were defined so that all functions took doc strings that were available via a documentation web UI. (ad_proc) https://openacs.org/api-doc/proc-view?proc=ad_proc
As much as I generally like python, I’m just not a fan of indentation based languages.
Z seems neat, but your contrast with Tcl is helpful. I recently ‘discovered’ Tcl and find it nearly perfectly suited to the niche of a ‘practical Scheme for scripting’. Tcl is fast, mature, and covers most of my use-cases from ‘something more than a shell script’ to ‘not quite a full-featured web application’. I would love to see Tcl more widely adopted among SICP fans, even if Abelson, et al. did call it ‘Lisp without a brain’.
TCL is a typical scripting language where tokens are self-quoting by default. I’ve explored that avenue in another language; my description there pretty much verbatim matches the official TCL documentation. I’ve since turned away from quoted-by-default language design as a dead-end, but YMMV.
I think the two approaches to language design are radically different. Z, by comparison, is closer to a Common Lisp where all macros are reader macros, and s-expressions are universally swapped out for z-expressions. See here for other comment.
But none of those fit the name and language like Z does. This language looks to be mostly a cool concept, and hasn’t taken off in the seven years since the article was written. I think most of the people who care about both this and Z notation will be able to infer which is which based on conversation context.
It depends! Is this language named the letter Z or the sound Z? If the former, then they’re phonetically distinguishable in America: Z notation is always pronounced “Zed”.
The other projects attempt to reduce the number of parentheses used, by introducing whitespace, and allow free mixing of indentation with s-expressions. This free mixing results in a variety of trade-offs and exceptions.
z-expressions retain the uncompromising regularity of s-expressions, replacing parentheses entirely with an indentation scheme, capable of expressing any grouping that parentheses can. The new benefit is that input to macros (which are all reader macros in z), have no start/end delimiter tokens (such as () or {} or []), and therefore also no escape sequences needed. The indentation delimits the text input, just like a code block in markdown. Unlike a Common Lisp reader macro, you can parse the rest of the document before finding an ending delimiter.
Cool syntax idea, It get’s a bit sparse but if it were to get some use then I’m sure some nice conventions / macros would be developed to counteract that.
Which, if you think about it, is the natural grouping for the definition of the name argument syntax I gave above.
Disagree. When I see foo bar baz I think of a command line where that’s essentially foo(bar, baz). You can abuse currying and make this (foo bar) baz where foo bar returns a function that takes an argument and returns the ‘real’ result of foo. That makes much more sense than foo bar baz meaning foo (bar baz).
Of course you create examples where either example makes more sense.
fold (+) [1, 2, 3]
-- makes more sense as
(fold (+)) [1, 2, 3]
-- because (fold (+)) is a meaningful kind of thing
whereas
foreach person as person:
print name-of person
-- obviously makes more sense as
print (name-of person)
Note, if you will, that these special operators interpret their arguments in a non-function normal-order way. They interpret their arguments syntactically!
I don’t quite understand what this sentence means, and why if is a special operator instead of a regular function which takes 3-arguments.
Because you have to delay the evaluation of your then or else statement depending on the result of the condition. If statements can be implemented as a function if the language uses lazy evaluation, but with eager evaluation you have to delay the evaluation of the branches with a macro or something.
Some similarities to TCL. TCL’s core syntax is COMMAND ARGS and ’ “ and { are ways of quoting. You can trivially define new control structures. One of my favorites was defining how functions were defined so that all functions took doc strings that were available via a documentation web UI. (ad_proc) https://openacs.org/api-doc/proc-view?proc=ad_proc
As much as I generally like python, I’m just not a fan of indentation based languages.
Z seems neat, but your contrast with Tcl is helpful. I recently ‘discovered’ Tcl and find it nearly perfectly suited to the niche of a ‘practical Scheme for scripting’. Tcl is fast, mature, and covers most of my use-cases from ‘something more than a shell script’ to ‘not quite a full-featured web application’. I would love to see Tcl more widely adopted among SICP fans, even if Abelson, et al. did call it ‘Lisp without a brain’.
I don’t recognise any similarities.
TCL is a typical scripting language where tokens are self-quoting by default. I’ve explored that avenue in another language; my description there pretty much verbatim matches the official TCL documentation. I’ve since turned away from quoted-by-default language design as a dead-end, but YMMV.
I think the two approaches to language design are radically different. Z, by comparison, is closer to a Common Lisp where all macros are reader macros, and s-expressions are universally swapped out for z-expressions. See here for other comment.
Name clash with Z notation. That one has an ISO standard and derivatives like Z++ and Object-Z.
If you are looking for a free name, there is none. However, you can probably overwrite H, I, T, V, or W.
But none of those fit the name and language like Z does. This language looks to be mostly a cool concept, and hasn’t taken off in the seven years since the article was written. I think most of the people who care about both this and Z notation will be able to infer which is which based on conversation context.
There’s a new v.
(That one can probably be overwritten, too, but…)
It depends! Is this language named the letter Z or the sound Z? If the former, then they’re phonetically distinguishable in America: Z notation is always pronounced “Zed”.
Not really a new idea. White space based syntax has been done a scheme SRFI before as well as a number of scheme variants (e.g. wart)
There is also SRFI-119, which allows you to continue arguments to a procedure on one line.
Others commented the same back in 2013 when this was published. It has not been done before, in SFRI-49, SRFI-119, SRFI-110 nor Wart.
Could you comment on the differences? They look superficially similar but I can imagine this kind of syntax lives or dies on small subtleties.
The other projects attempt to reduce the number of parentheses used, by introducing whitespace, and allow free mixing of indentation with s-expressions. This free mixing results in a variety of trade-offs and exceptions.
z-expressions retain the uncompromising regularity of s-expressions, replacing parentheses entirely with an indentation scheme, capable of expressing any grouping that parentheses can. The new benefit is that input to macros (which are all reader macros in z), have no start/end delimiter tokens (such as
()or{}or[]), and therefore also no escape sequences needed. The indentation delimits the text input, just like a code block in markdown. Unlike a Common Lisp reader macro, you can parse the rest of the document before finding an ending delimiter.Ah, that’s really interesting. Thanks.
I agree. Z is just damn cool. (Author of Wart here.)
A Lispy language with a Pythonic syntax philosophy! I like it.
Cool syntax idea, It get’s a bit sparse but if it were to get some use then I’m sure some nice conventions / macros would be developed to counteract that.
Disagree. When I see
foo bar bazI think of a command line where that’s essentiallyfoo(bar, baz). You can abuse currying and make this(foo bar) bazwherefoo barreturns a function that takes an argument and returns the ‘real’ result offoo. That makes much more sense thanfoo bar bazmeaningfoo (bar baz).Of course you create examples where either example makes more sense.
whereas
I don’t quite understand what this sentence means, and why
ifis a special operator instead of a regular function which takes 3-arguments.Because you have to delay the evaluation of your then or else statement depending on the result of the condition. If statements can be implemented as a function if the language uses lazy evaluation, but with eager evaluation you have to delay the evaluation of the branches with a macro or something.
Good point. I was sub-consciously thinking in terms of lazy evaluation, while this language is strict.
(Not unsafe: Implemented in Haskell.)