3 ms·

About kebab-case identifiers. What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like t

About kebab-case identifiers. What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. All those space imitations, whether they're dashes, underscores or camels - they're just imitations. Nothing compares to real spaces. If anything, underscores are closest ones, if you ask me.

lelanthran 4y ago
> What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. What would this look like, though?[1] How would you solve the problem of adjacent identifiers vs a single identifier which has spaces? Maybe having identifiers, and only identifiers, starting with a uppercase letter with no uppercase in the rest of the identifier? Then lines like `if MySubRoutine()` is easily parsed as `if My Sub Routine`, and `MyVarType MyVarName;` becomes an easily parser `My var name My var type;`. Looks harder to read than the usual camelCase, kebab-case and PascalCase identifiers though. [1] I ask because I'd like to do something like this when writing a program that comes with it's own language for the end-user to use to enhance the program.
- vbezhenar 4y ago
  Well, I would imagine that it requires designing a language which ordinary does not allow adjacent identifiers. Of course keywords must not be allowed as part of identifiers (or there should not be no keywords at all like with Lisp). Just an example of my head that I didn't think really much about: function print person (p: person) { var full name = p.first name + p.last name; if p.middle name != "" { full name += p.middle name } print line(full name) for c : p.subordinate person list { print person(c) } } I think this syntax should be parseable with little restrictions (like your identifier can't start with keyword).
  - still_grokking 4y ago
    That's completely unreadable! I can't "parse it" by looking at it, and a computer would have even more trouble doing so. How do I tokenise something like `full name += p.middle name`? Maybe as `(full) (name +=) (p.middle) (name)`? Or is it `(full) (name) (+= p.middle) (name)`? How about `print person(c)`? Is it the call of the `print` function with `person(c)` as argument?
int_19h 4y ago
It's pretty easy, actually, and was common in early PL designs such as ALGOL. All you need to do is make a special syntax for keywords - https://en.wikipedia.org/wiki/Stropping_(syntax) https://en.wikipedia.org/wiki/Stropping_(syntax) - and then whitespace becomes completely redundant for tokenization purposes, and can be ignored altogether, or treated as part of the identifier in which it occurs.
still_grokking 4y ago
That's a terrible idea given the fact that code is processed by human brains in a symbolic way, and not like a (western) written language. https://news.mit.edu/2020/brain-reading-computer-code-1215 https://news.mit.edu/2020/brain-reading-computer-code-1215

lelanthran 4y ago

> What I always wanted is proper spaces! Designing syntax where identifier could have spaces (without backticks or something like that) might be tricky of course. But may be it's not impossible. What would this look like, though?[1] How would you solve the problem of adjacent identifiers vs a single identifier which has spaces? Maybe having identifiers, and only identifiers, starting with a uppercase letter with no uppercase in the rest of the identifier? Then lines like `if MySubRoutine()` is easily parsed as `if My Sub Routine`, and `MyVarType MyVarName;` becomes an easily parser `My var name My var type;`. Looks harder to read than the usual camelCase, kebab-case and PascalCase identifiers though. [1] I ask because I'd like to do something like this when writing a program that comes with it's own language for the end-user to use to enhance the program.

vbezhenar 4y ago
Well, I would imagine that it requires designing a language which ordinary does not allow adjacent identifiers. Of course keywords must not be allowed as part of identifiers (or there should not be no keywords at all like with Lisp). Just an example of my head that I didn't think really much about: function print person (p: person) { var full name = p.first name + p.last name; if p.middle name != "" { full name += p.middle name } print line(full name) for c : p.subordinate person list { print person(c) } } I think this syntax should be parseable with little restrictions (like your identifier can't start with keyword).
- still_grokking 4y ago
  That's completely unreadable! I can't "parse it" by looking at it, and a computer would have even more trouble doing so. How do I tokenise something like `full name += p.middle name`? Maybe as `(full) (name +=) (p.middle) (name)`? Or is it `(full) (name) (+= p.middle) (name)`? How about `print person(c)`? Is it the call of the `print` function with `person(c)` as argument?

int_19h 4y ago

It's pretty easy, actually, and was common in early PL designs such as ALGOL. All you need to do is make a special syntax for keywords - https://en.wikipedia.org/wiki/Stropping_(syntax) https://en.wikipedia.org/wiki/Stropping_(syntax) - and then whitespace becomes completely redundant for tokenization purposes, and can be ignored altogether, or treated as part of the identifier in which it occurs.

still_grokking 4y ago

That's a terrible idea given the fact that code is processed by human brains in a symbolic way, and not like a (western) written language. https://news.mit.edu/2020/brain-reading-computer-code-1215 https://news.mit.edu/2020/brain-reading-computer-code-1215