Syntax

[shelby3]

Syntax of identifier names:

• type parameter ^{_{(aka PID)}}: [A-Z][A-Z0-9]*
• data, interface & (de/con)structor function ^{_{(aka TID)}}: [A-Z](?:_[A-Z])?(?:[a-zA-Z0-9]|[A-Z]_[A-Z])*
• function ^{_{(aka FID)}}: (?:[a-z](?:[a-zA-Z0-9]|[A-Z]_[A-Z])*|[αβγδεζηθικλμνξοπρςτυφχψωℎℏ𝑒])(?:'*|′*)
• non-function ^{_{(aka VID)}}: (?:[_a-z][_a-z0-9]*|[αβγδεζηθικλμνξοπρςτυφχψωℎℏ𝑒])(?:'*|′*)
• overlap for function or non-function ^{_{(aka ID)}}: (?:[a-z][a-z0-9]*|[αβγδεζηθικλμνξοπρςτυφχψωℎℏ𝑒])(?:'*|′*)

Everywhere a-z really means a-z𝕒𝕓𝕔𝕕𝕖𝕗𝕘𝕙𝕚𝕛𝕜𝕝𝕞𝕟𝕠𝕡𝕢𝕣𝕤𝕥𝕦𝕧𝕨𝕩𝕪𝕫𝔞𝔟𝔠𝔡𝔢𝔣𝔤𝔥𝔦𝔧𝔨𝔩𝔪𝔫𝔬𝔭𝔮𝔯𝔰𝔱𝔲𝔳𝔴𝔵𝔶𝔷𝓪𝓫𝓬𝓭𝓮𝓯𝓰𝓱𝓲𝓳𝓴𝓵𝓶𝓷𝓸𝓹𝓺𝓻𝓼𝓽𝓾𝓿𝔀𝔁𝔂𝔃, A-Z really means A-Z𝔸𝔹ℂ𝔻𝔼𝔽𝔾ℍ𝕀𝕁𝕂𝕃𝕄ℕ𝕆ℙℚℝ𝕊𝕋𝕌𝕍𝕎𝕏𝕐ℤ𝔄𝔅ℭ𝔇𝔈𝔉𝔊ℌℑ𝔍𝔎𝔏𝔐𝔑𝔒𝔓𝔔ℜ𝔖𝔗𝔘𝔙𝔚𝔛𝔜ℨ𝓐𝓑𝓒𝓓𝓔𝓕𝓖𝓗𝓘𝓙𝓚𝓛𝓜𝓝𝓞𝓟𝓠𝓡𝓢𝓣𝓤𝓥𝓦𝓧𝓨𝓩, and 0-9 really means 0-9𝟘𝟙𝟚𝟛𝟜𝟝𝟞𝟟𝟠𝟡.

Design points:

• All uppercase are type variables in function type signatures, and programmer must employ data.R or interface.R to distinguish a conflicting data or interface which is in lexical scope.
• To reduce noise, the I prefix for distinguishing interface from data was dropped in favor of optional syntax coloring in clients.
• Camel case is preferred (even for exported identifiers) for data, interface, and function identifier names, except underscore _ is allowed between two capital letters. Prefixing them with underscores is not allowed even for the not exported case, but can employ the ′ suffix instead. Removing dependencies on exported removes a conflation of the lexer and parser state machines. Readability is maximized in open source with a consistent style, thus camel case is chosen as the preferred style for the reasons argued in the cited reference discussions.
• Do not allow JavaScript’s $ in identifier names because it is symbol soup; and we want to reserve symbols for operators (and type annotations). Chose to reserve $ within identifier names such as for transpiling x′′′ to x$prime3 although we could reserve some Unicode character instead.
• The ' character can be typed from most keyboards, but the correct Unicode character is ′ (' vs. ′). The prime is included because @keean suggested it for math notation.
• The lexer can not always distinguish between a function and non-function, nor between a type parameter and a data or interface.
• I am not including non-English character sets because there are too many of them; and it is antithetical to maximum readability that the world uses different languages in coding. English is the de facto international language at this point in time, and apparently is one of most homogeneous languages. The Greek characters are included for math notation. Although someone can make the argument that a project with a scope in a foreign language could benefit from native language character sets, I argue that the overall ecosystem network effects will be greater by coders who communicate their art in an international language.

References:

https://github.com/keean/zenscript/issues/11#issuecomment-249375781 thru https://github.com/keean/zenscript/issues/11#issuecomment-249386453. https://github.com/keean/zenscript/issues/11#issuecomment-249405587 thru https://github.com/keean/zenscript/issues/11#issuecomment-249440439. https://github.com/keean/zenscript/issues/11#issuecomment-249720509 thru https://github.com/keean/zenscript/issues/11#issuecomment-249741723.

[shelby3]

Syntax of a Python-like yet more structured block indenting with line continuations:

https://github.com/keean/zenscript/issues/11#issuecomment-305987788

[shelby3]

1. Syntax, type annotation, and typing of functions (definitions and call sites), including default arguments, named arguments, and overloaded function names:

   https://github.com/keean/zenscript/issues/6#issuecomment-305624956 thru https://github.com/keean/zenscript/issues/6#issuecomment-306021582 https://github.com/keean/zenscript/issues/6#issuecomment-306324398

   Inline function shorthand: https://github.com/keean/zenscript/issues/11#issuecomment-249277181 & https://github.com/keean/zenscript/issues/6#issuecomment-248631325

2. Typeclasses (although perhaps we prefer to start with manual dependency injection):

   https://github.com/keean/zenscript/issues/30#issuecomment-302123983 thru https://github.com/keean/zenscript/issues/30#issuecomment-302952957

   Including design patterns for avoiding HKT:

   https://github.com/keean/zenscript/issues/27#issuecomment-302921541 thru https://github.com/keean/zenscript/issues/27#issuecomment-303283072

3. Inferred HRT:

   https://github.com/keean/zenscript/issues/27#issuecomment-302055101 https://github.com/keean/zenscript/issues/6#issuecomment-306381433

[shelby3]

Syntax for non-block-indented if (…) … else … ternary “operator” expression and syntax of block-indented if-else, do-loop if, and while:

https://github.com/keean/zenscript/issues/11#issuecomment-286645796

[shelby3]

Syntax and design of modules, exports, private keyword in general, and import:

https://github.com/keean/zenscript/issues/11#issuecomment-306974094 thru https://github.com/keean/zenscript/issues/11#issuecomment-307558325 https://github.com/keean/zenscript/issues/14#issuecomment-302775198 thru https://github.com/keean/zenscript/issues/14#issuecomment-308722477

[shelby3]

Syntax for (simplified data and) alias (instead of (see also) the keyword type) for anonymous structurally typed, type-indexed-tagged, partial-order-disjointed sum (aka) union (but not intersection (see also)!) types:

https://github.com/keean/zenscript/issues/13#issuecomment-303445358 https://github.com/keean/zenscript/issues/13#issuecomment-303538864

To create nominal sum type, wrap it in a data type:

https://github.com/keean/zenscript/issues/13#issuecomment-303552617

[shelby3]

Type annotations for r/w access restrictions, borrowing, optional types, and unboxed, packed binary records:

https://github.com/keean/zenscript/issues/32#issuecomment-301060409