7 ms·

The fact that kebab-case support is a rarity constantly boggles my mind, nevermind that it isn't the de facto default for any language created after *sh/lisp. R

by txbuck 4y ago

The fact that kebab-case support is a rarity constantly boggles my mind, nevermind that it isn't the de facto default for any language created after *sh/lisp. Readability, ease-of-typing, parallel with the way it's used in (Romantic) natural language. If I were writing a new language I intended to popularize this would be one of the features I would emphasize. Spicy semi-snarky aside: if your counterpoint is that kebab-case prevents crushing your arithmetic operators together, I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself).

Arch-TK 4y ago
It's a bit hard to parse it outside of languages like lisp because of infix.
- thaumasiotes 4y ago
  Infix has nothing to do with it. We can already parse expressions of the form "x - 20". The change would be to stop interpreting "x-20" as being the same set of three tokens as "x - 20".
  - taeric 4y ago
    That is the point, though? Is "x- 20" the same as "x - 20" the same as "x -20" In the vast majority of modern programming languages, that is a yes. If you allowed dashes in the names, not so much. Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
    - thaumasiotes 4y ago
      > Is "x- 20" the same as "x - 20" the same as "x -20"[?] In the vast majority of modern programming languages, that is a yes. Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen"). Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
      - Arch-TK 4y ago
        Distinguishing unary minus from binary minus is not done by spacing in parsers. Most modern language parsers ignore whitespace except where it would cause the concatenation of two identifiers (or in the case of languages like python or nim, where it is at the beginning of a line). I know this for a fact since I've studied their grammars. Infix notation and - are really the reasons why nobody does this, some people like to use spacing to indicate precedence too (writing code such as "a - 1*g") so it would break some workflows and realistically having a language which is whitespace agnostic except for identifiers AND the minus operator just seems too irregular for people to commit to it.
        Joker_vD 4y ago
        Depends on the parser. See e.g. [0] for Elm's take on it: it already had special logic for differentiating "(.)" and "( . )". [0] https://elm-lang.org/news/0.9 https://elm-lang.org/news/0.9
        Arch-TK 4y ago
        That's why I said most. Obviously there exist languages, such as elm, where this is not the case, but in the case of those languages, the teaching literature (as is the case with elm) explains these things. Most languages don't do this precisely because their designers made the judgement call that the additional parsing complexity (both for the actual parser and the human) outweighed the benefits of allowing you to have minuses in identifiers.
gnulinux 4y ago
I think you're maybe just a little confused, or I'm missing something. Kebab case is in general not viable to implement unless you have very a special/quirky syntax, because there is no way differentiate to `a-b` from `Id("a-b")` and `Subtract(Id("a"), Id("b"))` from syntax alone. Now, there are of course options that introduce trade-offs. First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with. Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language. This is very useful because then you can have identifiers like "a+b", or even identifiers like "a+[b+c-d]" etc... As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that, well now you're not allowed to condense arithmetic operations. This may or may not be a problem, depending on the programming language designer. When you said: > I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself). I'm guessing your opinion is that you're ok with this trade-off. Fact of the matter is that this a very fringe syntax for any programming language to have. As an Agda programmer, I like it, and it is useful, but I'm not convinced something like this would find mass appeal. The last option I'm aware is to have semantic differentiation. When you find a statement like "c = a-b" you need to ask two things. One, are there identifiers "a", "b" and "a-b". If "a-b" exist and "a" or "b" doesn't exist, you're all set. If all three exist, second question is, are "a" and "b" subtractible? If the answer is yes then programming language designer can choose to prioritize "a - b" over identifier "a-b". Alternatively, you can always choose to prioritize identifier "a-b" as long as it exists. I'm personally not aware of any language that implements something like this, however I have implemented toy languages that go through this, it's pretty easy. It's a matter of making the decision to introduce this type of complexity into your language. All in all, although I love kebab case, in order to have it in your language you need to make pretty significant trade-offs. Given this, I'm not surprised any mainstream non-lisp-like language doesn't have it.
- thaumasiotes 4y ago
  > First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with. This is a gross error. In your sense, Lisp does not even have operators, only identifiers. The reason there is no confusion between "(- a b)" and "(-ab)" is the spacing that separates the three identifiers in the first case.[1] Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does". [1] However, Lisp does have a potential problem with identifiers that begin with a hyphen, due to the need to support literal numeric values like -3. Thus the Common Lisp decrement function is named "1-" despite not returning the value (1 - operand).
int_19h 4y ago
It is (was?) the default for XSLT and XQuery, if we're talking about something relatively mainstream. Beyond that I can think of Dylan and REBOL.
- capableweb 4y ago
  CSS is probably the most mainstream language allowing dashes in names.
  - int_19h 4y ago
    Depends on whether you count all the serialized data on the wire or not; if you do, it's probably XML. ~ But I think OP meant programming languages, not styling or markup.
    - gpderetta 4y ago
      Everybody forgets about shell scripts! Bash allows dashes in executable names (how it couldn't) and in function names, but not in variable names, at least not without a lot of effort.
txbuck 4y ago
For reference, something like like this (Python regex): ^[a-zA-Z_]+[a-zA-Z0-9_]*(-?[a-zA-Z0-9_]+)*$ some-name some2-name some-2-name some-2name some-name2 some-name-2 some2other-name some-other2name some-othername2 some-2othername some-0-other-name a-0-name a0-0a-0a-a0 kebab-case-pls tbh-didnt-write-any-underscore-tests -negated -negated-variable -(negated) -(also-negated) -(-double-negated) binary - operation binary + operation double - binary - operation 2-syntax-error-4-me 2syntaxerrorforme 1-2-3-4-syn-tax-err-or 80086-syntax-error syntax+error syntaxerror+ syntax-error+ syntax-error- syntax-(error) (syntax)-error syntax--error syntax++error
kibwen 4y ago
Make your language syntax require whitespace around arithmetic operators, and then we can finally live in a glorious paradise of kebab-case and `foo/bar` for namespaces.
Gibbon1 4y ago
My snarky suggestion is we switch to emoji's for arithmetic operators. Semi serious incorporate syntax highlighting via markup into the language.
- kaba0 4y ago
  I mean, not even a bad idea. I would honestly prefer operators to be more explicit like a-variableanother-varsomething-else. (EDIT: HN removed my emojis, but imagine a plus/minus emoji inbetween ids :( ) With a good font it would basically look similar to what a good IDE with syntax highlighting already does (different color for operators).
  - Lio 4y ago
    I think this would be a bad idea because emoji are hard to type. This might be a bit old school but I prefer things limited to plain ASCII. There's only so many keys on a keyboard and want to be able to touch type everything without thinking or looking at a special emoji bar.
    - kaba0 4y ago
      That I absolutely agree with, but I think it is about time we let go of “programs as plain text” axiom. With good tooling/IDE — which are already sort of visual editors only converting to and from to plain text on save — you could enter a ‘+’ and get autocomplete show the “emoji +” as an option for example. Because the actually important question to ask here in my opinion is “what is the easiest way to read/comprehend programs”, and we seem to have implicitly agreed that syntax highlighting is already a must (which works on even not yet valid program text!). Slightly more reliance on tooling doesn’t seem too bad to me.
    - goerz 4y ago
      With a proper keyboard layout, you can type a lot of unicode: https://michaelgoerz.net/notes/the-us-international-scientific-keyboard-layout/index.html https://michaelgoerz.net/notes/the-us-international-scientif...
- 4y ago

by txbuck 4y ago

Arch-TK 4y ago

It's a bit hard to parse it outside of languages like lisp because of infix.

thaumasiotes 4y ago
Infix has nothing to do with it. We can already parse expressions of the form "x - 20". The change would be to stop interpreting "x-20" as being the same set of three tokens as "x - 20".
- taeric 4y ago
  That is the point, though? Is "x- 20" the same as "x - 20" the same as "x -20" In the vast majority of modern programming languages, that is a yes. If you allowed dashes in the names, not so much. Now, I grant the point that it is doable. But the point is it complicate things. Now, fair, we have some of these complications already by virtue of the fact that we allow numbers in variable names. "foo3" is already allowed in many languages, and that clearly gets altered as you add space between the characters.
  - thaumasiotes 4y ago
    > Is "x- 20" the same as "x - 20" the same as "x -20"[?] In the vast majority of modern programming languages, that is a yes. Is that really true? I wouldn't exactly feel comfortable with "x -20", though I suspect you're right about at least a large number of languages determining the meaning of the hyphen through local syntactic context ("I just saw an identifier; that must be a non-unary hyphen"). Now I'm interested in whether the corpus of existing code shows any bias between "y = -x" (perfectly allowed, I think) and "y = -1 * x".
    - Arch-TK 4y ago
      Distinguishing unary minus from binary minus is not done by spacing in parsers. Most modern language parsers ignore whitespace except where it would cause the concatenation of two identifiers (or in the case of languages like python or nim, where it is at the beginning of a line). I know this for a fact since I've studied their grammars. Infix notation and - are really the reasons why nobody does this, some people like to use spacing to indicate precedence too (writing code such as "a - 1*g") so it would break some workflows and realistically having a language which is whitespace agnostic except for identifiers AND the minus operator just seems too irregular for people to commit to it.
      - Joker_vD 4y ago
        Depends on the parser. See e.g. [0] for Elm's take on it: it already had special logic for differentiating "(.)" and "( . )". [0] https://elm-lang.org/news/0.9 https://elm-lang.org/news/0.9
        Arch-TK 4y ago
        That's why I said most. Obviously there exist languages, such as elm, where this is not the case, but in the case of those languages, the teaching literature (as is the case with elm) explains these things. Most languages don't do this precisely because their designers made the judgement call that the additional parsing complexity (both for the actual parser and the human) outweighed the benefits of allowing you to have minuses in identifiers.

gnulinux 4y ago

I think you're maybe just a little confused, or I'm missing something. Kebab case is in general not viable to implement unless you have very a special/quirky syntax, because there is no way differentiate to `a-b` from `Id("a-b")` and `Subtract(Id("a"), Id("b"))` from syntax alone. Now, there are of course options that introduce trade-offs. First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with. Another option is to require a space between operators. E.g. you are not allowed to write "a+b" to mean "add a to b". You have to write "a + b". This is used in Agda programming language. This is very useful because then you can have identifiers like "a+b", or even identifiers like "a+[b+c-d]" etc... As long as any char doesn't have a special meaning (e.g. in Agda "(", ";", "," etc have special meanings) you can use it in an identifier. The trade-off is that, well now you're not allowed to condense arithmetic operations. This may or may not be a problem, depending on the programming language designer. When you said: > I strongly suggest you either reconsider or never write any code you think may be read by another human being (and possibly yourself). I'm guessing your opinion is that you're ok with this trade-off. Fact of the matter is that this a very fringe syntax for any programming language to have. As an Agda programmer, I like it, and it is useful, but I'm not convinced something like this would find mass appeal. The last option I'm aware is to have semantic differentiation. When you find a statement like "c = a-b" you need to ask two things. One, are there identifiers "a", "b" and "a-b". If "a-b" exist and "a" or "b" doesn't exist, you're all set. If all three exist, second question is, are "a" and "b" subtractible? If the answer is yes then programming language designer can choose to prioritize "a - b" over identifier "a-b". Alternatively, you can always choose to prioritize identifier "a-b" as long as it exists. I'm personally not aware of any language that implements something like this, however I have implemented toy languages that go through this, it's pretty easy. It's a matter of making the decision to introduce this type of complexity into your language. All in all, although I love kebab case, in order to have it in your language you need to make pretty significant trade-offs. Given this, I'm not surprised any mainstream non-lisp-like language doesn't have it.

thaumasiotes 4y ago
> First obvious option is to get rid of the infix "-" operator, which is what Lisp does. In lisp-like languages you don't write "a - b" instead you write "- a b", this way there is nothing to confuse "a-b" with. This is a gross error. In your sense, Lisp does not even have operators, only identifiers. The reason there is no confusion between "(- a b)" and "(-ab)" is the spacing that separates the three identifiers in the first case.[1] Your comment is especially weird because you go on to discuss Lisp's approach as being "an alternative option to what Lisp does". [1] However, Lisp does have a potential problem with identifiers that begin with a hyphen, due to the need to support literal numeric values like -3. Thus the Common Lisp decrement function is named "1-" despite not returning the value (1 - operand).

int_19h 4y ago

It is (was?) the default for XSLT and XQuery, if we're talking about something relatively mainstream. Beyond that I can think of Dylan and REBOL.

capableweb 4y ago
CSS is probably the most mainstream language allowing dashes in names.
- int_19h 4y ago
  Depends on whether you count all the serialized data on the wire or not; if you do, it's probably XML. ~ But I think OP meant programming languages, not styling or markup.
  - gpderetta 4y ago
    Everybody forgets about shell scripts! Bash allows dashes in executable names (how it couldn't) and in function names, but not in variable names, at least not without a lot of effort.

txbuck 4y ago

For reference, something like like this (Python regex): ^[a-zA-Z_]+[a-zA-Z0-9_]*(-?[a-zA-Z0-9_]+)*$ some-name some2-name some-2-name some-2name some-name2 some-name-2 some2other-name some-other2name some-othername2 some-2othername some-0-other-name a-0-name a0-0a-0a-a0 kebab-case-pls tbh-didnt-write-any-underscore-tests -negated -negated-variable -(negated) -(also-negated) -(-double-negated) binary - operation binary + operation double - binary - operation 2-syntax-error-4-me 2syntaxerrorforme 1-2-3-4-syn-tax-err-or 80086-syntax-error syntax+error syntaxerror+ syntax-error+ syntax-error- syntax-(error) (syntax)-error syntax--error syntax++error

kibwen 4y ago

Make your language syntax require whitespace around arithmetic operators, and then we can finally live in a glorious paradise of kebab-case and `foo/bar` for namespaces.

Gibbon1 4y ago

My snarky suggestion is we switch to emoji's for arithmetic operators. Semi serious incorporate syntax highlighting via markup into the language.

kaba0 4y ago
I mean, not even a bad idea. I would honestly prefer operators to be more explicit like a-variableanother-varsomething-else. (EDIT: HN removed my emojis, but imagine a plus/minus emoji inbetween ids :( ) With a good font it would basically look similar to what a good IDE with syntax highlighting already does (different color for operators).
- Lio 4y ago
  I think this would be a bad idea because emoji are hard to type. This might be a bit old school but I prefer things limited to plain ASCII. There's only so many keys on a keyboard and want to be able to touch type everything without thinking or looking at a special emoji bar.
  - kaba0 4y ago
    That I absolutely agree with, but I think it is about time we let go of “programs as plain text” axiom. With good tooling/IDE — which are already sort of visual editors only converting to and from to plain text on save — you could enter a ‘+’ and get autocomplete show the “emoji +” as an option for example. Because the actually important question to ask here in my opinion is “what is the easiest way to read/comprehend programs”, and we seem to have implicitly agreed that syntax highlighting is already a must (which works on even not yet valid program text!). Slightly more reliance on tooling doesn’t seem too bad to me.
  - goerz 4y ago
    With a proper keyboard layout, you can type a lot of unicode: https://michaelgoerz.net/notes/the-us-international-scientific-keyboard-layout/index.html https://michaelgoerz.net/notes/the-us-international-scientif...
4y ago