shelby3 / lucid Goto Github PK

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:

keean/zenscript#11 (comment) thru keean/zenscript#11 (comment).
keean/zenscript#11 (comment) thru keean/zenscript#11 (comment).
keean/zenscript#11 (comment) thru keean/zenscript#11 (comment).

Block-level (Promise integrated) block-level deterministic RAII-like destructors:

keean/zenscript#14 (comment)
keean/zenscript#33 (comment) & keean/zenscript#33 (comment)

_{(design pattern possible in TypeScript, but the boilerplate reduction, correctness checking, and automated deployment can’t be obtained without transpilation)}

---

Not supporting weak nor strong references:

keean/zenscript#32 (comment)