6 ms·

Walter, D has conditional compilation, versioning and CTFE without preprocessor so I guess that covers the 99% "sane" functionality. Where do you draw the line

Walter, D has conditional compilation, versioning and CTFE without preprocessor so I guess that covers the 99% "sane" functionality. Where do you draw the line between that and the 1% abomination part, i.e. your thoughts on, say, compile time type introspection and things like generating ('printing') types/declarations?

WalterBright 5y ago
The abomination is using the preprocessor to redefine the syntax and/or invent new syntax. Supporting identifier characters that look like `:` is just madness. Of course, I've also opined that Unicode supporting multiple encodings for the same glyph is also madness. The Unicode people veered off the tracks and sank into a swamp when they decided that semantic information should be encoded into Unicode characters.
- foxfluff 5y ago
  > The Unicode people veered off the tracks and sank into a swamp when they decided that semantic information should be encoded into Unicode characters. As if that weren't enough, they also decided to cram half-assed formatting into it. You got bold letters, italics, various fancy-style letters, superscripts and subscripts for this and that.. all for the sake of leagacy compatibility. Unicode was legacy right from the beginning.
  - WalterBright 5y ago
    Yeah, where do you stop when you start adding fonts to Unicode?
    - hug 5y ago
      If #include <𝒸𝓊𝓇𝓈𝒾𝓋𝑒.h> is wrong, I don't want to be right.
      - foxfluff 5y ago
        𝐼 𝘭𝘪𝘬𝘦 𝑢𝑠𝑖𝑛𝑔 𝐛𝐨𝐥𝐝 𝑎𝑛𝑑 𝘪𝘵𝘢𝘭𝘪𝘤 𝑡𝑒𝑥𝑡 𝑗𝑢𝑠𝑡 𝑡𝑜 𝒎𝒆𝒔𝒔 𝑤𝑖𝑡ℎ 𝑎𝑛𝑦𝑜𝑛𝑒 𝑤ℎ𝑜'𝑠 𝑡𝑟𝑦𝑖𝑛𝑔 𝑡𝑜 𝑢𝑠𝑒 𝑡ℎ𝑒 𝑠𝑒𝑎𝑟𝑐ℎ 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 𝑖𝑛 𝑡ℎ𝑒𝑖𝑟 𝑏𝑟𝑜𝑤𝑠𝑒𝑟 𝑜𝑟 𝑒𝑑𝑖𝑡𝑜𝑟. Sᴍᴀʟʟ ᴄᴀᴘs ᴡᴏʀᴋ ғᴏʀ ᴀ sɪᴍɪʟᴀʀ ᴇғғᴇᴄᴛ. ℑ𝔱 𝔤𝔢𝔱𝔰 𝔢𝔵𝔱𝔯𝔞 𝔣𝔲𝔫 𝔦𝔫 𝔯𝔦𝔠𝔥 𝔱𝔢𝔵𝔱 𝔢𝔡𝔦𝔱𝔬𝔯𝔰 𝔴𝔥𝔢𝔯𝔢 𝔶𝔬𝔲 𝔠𝔞𝔫 𝔪𝔦𝔵 𝔲𝔫𝔦𝔠𝔬𝔡𝔢 𝔰𝔱𝔶𝔩𝔢𝔰 𝔞𝔫𝔡 𝔯𝔢𝔞𝔩 𝔰𝔱𝔶𝔩𝔢𝔰. pᵁrⁿoͥvͨiͦdͩeͤs oͤpⁿpͩoˡrͤtˢuˢnities cᶠoͦnͬfusing aᵖnͤdͦᵖˡᵉ sͭoͪfͤtͥwͬare.
      - WalterBright 5y ago
        Use Markdown if you want italics.
    - deleted 5y ago
      [deleted]
    - bombcar 5y ago
      We have emojis so we’re probably not far from Unicode characters that blink.
  - pornel 5y ago
    The "fonts" in Unicode are meant to be for math and scientific symbols, and not a stylistic choice. Don't use them for text, as it can be a cacophony in screen readers. Unicode chose to support lossless conversion to and from other encodings it replaces (I presume it was important for adoption), so unfortunately it inherited the sum of everyone else's tech debt.
  - WalterBright 5y ago
    Unicode did worse than that. They added code points to esrever the direction of text rendering. Naturally, this turned out to be useful for injecting malware into source code, because having the text rendered backwards and forwards erases the display of the malware, so people can't see it. Note that nobody needs these code points to reverse text. I did it above without gnisu those code points.
- mananaysiempre 5y ago
  What other kind of difference should be encoded into Unicode characters? For example, the glyphs for the Latin a and the Cyrillic а, or the Latin i and the Cyrillic (Ukrainian, Belarusian, and pre-1918 Russian) і look identical in practically every situation, and the Latin (Turkish) ı and the Greek ι aren’t far off. At least not far off compared to the Cyrillic (most languages) д and the Cyrillic (Southern) g-like version (from the standard Cyrillic cursive), or the Cyrillic т and the several Cyrillic (Southern) versions that are like either an m or a turned m (from the cursive, again). Yet most people who are acquainted with the relevant languages would say the former are different “letters” (whatever that means) and the latter are the same. [Purely-Latin borderline cases: umlaut (is not two dots in Fraktur) vs diaeresis (languages that use it are not written in Fraktur), acute (non-Polish, points past the letter) vs kreska (Polish, points at the letter). On the other hand, the mathematical “element of” sign was still occasionally typeset as an epsilon well into the 1960s.] Unicode decides most of these based on the requirement to roundtrip legacy encodings (“have these been ever encoded differently in the same encoding?”), which seems reasonable, yet results in homograph problems and at the same time the Turkish case conversion botch. In any case, once (sane) legacy encodings run out but you still want to be consistent, what do you base the encoding decisions on but semantics? (On the other hand, once you start encoding semantic differences, where do you stop?..) You could do some sort of glyph-equivalence-class thing, but that would still give you no way to avoid unifying a and а—everyone who writes both writes them the same. None of this touches on Unicode “canonical equivalence”, but your claim (“Unicode supporting multiple encodings for the same glyph is [...] madness”) covers more than just that if I understood it correctly. And while I am attacking it in a sense, it’s only because I genuinely don’t see how this part could have been done differently in a major way.
  - wyldfire 5y ago
    Ignoring Unicode and focusing just on C: if the glyph matches a glyph used in any existing C operator maybe it shouldn't be legal as an identifier character.
    - mananaysiempre 5y ago
      I’m not defending either standard Unicode identifiers or C Unicode identifiers (which are, incidentally, very different things, see WG14/N1518), no :) The Agda people make good use of various mathematical operators, including ones that are very close to the language syntax (e.g. colon as built-in type ascription and equals as built-in definition, but Unicode colon-equals as a substitution operator for a user-defined type of terms in a library for processing syntax), but overall I’m not convinced it’s worth it at all. As a way to avoid going ASCII-only, though, excluding only things that look like syntax might be simultaneously not going far enough (how are homograph collisions between user-defined identifiers any better?) and too far (reliably transplating identifiers between languages that use different sets of punctuation seems like it’d be torturously difficult).
- scatters 5y ago
  That ship sailed long before Unicode. Even ASCII has characters with multiple valid glyphs (lower case a can lose the ascender, and lower case g is similarly variable in the number of loops), not to mention multiple characters that are often represented with the same glyph (lower case l, upper case I, digit 1).
  - WalterBright 5y ago
    That's a font issue with some fonts, not a green light for blessing multiple code points with the exact same glyph. In fact, having a font that makes l I and 1 indistinguishable is plenty of good reason to NOT make this a requirement.

WalterBright 5y ago

The abomination is using the preprocessor to redefine the syntax and/or invent new syntax. Supporting identifier characters that look like `:` is just madness. Of course, I've also opined that Unicode supporting multiple encodings for the same glyph is also madness. The Unicode people veered off the tracks and sank into a swamp when they decided that semantic information should be encoded into Unicode characters.

foxfluff 5y ago
> The Unicode people veered off the tracks and sank into a swamp when they decided that semantic information should be encoded into Unicode characters. As if that weren't enough, they also decided to cram half-assed formatting into it. You got bold letters, italics, various fancy-style letters, superscripts and subscripts for this and that.. all for the sake of leagacy compatibility. Unicode was legacy right from the beginning.
- WalterBright 5y ago
  Yeah, where do you stop when you start adding fonts to Unicode?
  - hug 5y ago
    If #include <𝒸𝓊𝓇𝓈𝒾𝓋𝑒.h> is wrong, I don't want to be right.
    - foxfluff 5y ago
      𝐼 𝘭𝘪𝘬𝘦 𝑢𝑠𝑖𝑛𝑔 𝐛𝐨𝐥𝐝 𝑎𝑛𝑑 𝘪𝘵𝘢𝘭𝘪𝘤 𝑡𝑒𝑥𝑡 𝑗𝑢𝑠𝑡 𝑡𝑜 𝒎𝒆𝒔𝒔 𝑤𝑖𝑡ℎ 𝑎𝑛𝑦𝑜𝑛𝑒 𝑤ℎ𝑜'𝑠 𝑡𝑟𝑦𝑖𝑛𝑔 𝑡𝑜 𝑢𝑠𝑒 𝑡ℎ𝑒 𝑠𝑒𝑎𝑟𝑐ℎ 𝘧𝘶𝘯𝘤𝘵𝘪𝘰𝘯 𝑖𝑛 𝑡ℎ𝑒𝑖𝑟 𝑏𝑟𝑜𝑤𝑠𝑒𝑟 𝑜𝑟 𝑒𝑑𝑖𝑡𝑜𝑟. Sᴍᴀʟʟ ᴄᴀᴘs ᴡᴏʀᴋ ғᴏʀ ᴀ sɪᴍɪʟᴀʀ ᴇғғᴇᴄᴛ. ℑ𝔱 𝔤𝔢𝔱𝔰 𝔢𝔵𝔱𝔯𝔞 𝔣𝔲𝔫 𝔦𝔫 𝔯𝔦𝔠𝔥 𝔱𝔢𝔵𝔱 𝔢𝔡𝔦𝔱𝔬𝔯𝔰 𝔴𝔥𝔢𝔯𝔢 𝔶𝔬𝔲 𝔠𝔞𝔫 𝔪𝔦𝔵 𝔲𝔫𝔦𝔠𝔬𝔡𝔢 𝔰𝔱𝔶𝔩𝔢𝔰 𝔞𝔫𝔡 𝔯𝔢𝔞𝔩 𝔰𝔱𝔶𝔩𝔢𝔰. pᵁrⁿoͥvͨiͦdͩeͤs oͤpⁿpͩoˡrͤtˢuˢnities cᶠoͦnͬfusing aᵖnͤdͦᵖˡᵉ sͭoͪfͤtͥwͬare.
    - WalterBright 5y ago
      Use Markdown if you want italics.
  - deleted 5y ago
    [deleted]
  - bombcar 5y ago
    We have emojis so we’re probably not far from Unicode characters that blink.
- pornel 5y ago
  The "fonts" in Unicode are meant to be for math and scientific symbols, and not a stylistic choice. Don't use them for text, as it can be a cacophony in screen readers. Unicode chose to support lossless conversion to and from other encodings it replaces (I presume it was important for adoption), so unfortunately it inherited the sum of everyone else's tech debt.
- WalterBright 5y ago
  Unicode did worse than that. They added code points to esrever the direction of text rendering. Naturally, this turned out to be useful for injecting malware into source code, because having the text rendered backwards and forwards erases the display of the malware, so people can't see it. Note that nobody needs these code points to reverse text. I did it above without gnisu those code points.
mananaysiempre 5y ago
What other kind of difference should be encoded into Unicode characters? For example, the glyphs for the Latin a and the Cyrillic а, or the Latin i and the Cyrillic (Ukrainian, Belarusian, and pre-1918 Russian) і look identical in practically every situation, and the Latin (Turkish) ı and the Greek ι aren’t far off. At least not far off compared to the Cyrillic (most languages) д and the Cyrillic (Southern) g-like version (from the standard Cyrillic cursive), or the Cyrillic т and the several Cyrillic (Southern) versions that are like either an m or a turned m (from the cursive, again). Yet most people who are acquainted with the relevant languages would say the former are different “letters” (whatever that means) and the latter are the same. [Purely-Latin borderline cases: umlaut (is not two dots in Fraktur) vs diaeresis (languages that use it are not written in Fraktur), acute (non-Polish, points past the letter) vs kreska (Polish, points at the letter). On the other hand, the mathematical “element of” sign was still occasionally typeset as an epsilon well into the 1960s.] Unicode decides most of these based on the requirement to roundtrip legacy encodings (“have these been ever encoded differently in the same encoding?”), which seems reasonable, yet results in homograph problems and at the same time the Turkish case conversion botch. In any case, once (sane) legacy encodings run out but you still want to be consistent, what do you base the encoding decisions on but semantics? (On the other hand, once you start encoding semantic differences, where do you stop?..) You could do some sort of glyph-equivalence-class thing, but that would still give you no way to avoid unifying a and а—everyone who writes both writes them the same. None of this touches on Unicode “canonical equivalence”, but your claim (“Unicode supporting multiple encodings for the same glyph is [...] madness”) covers more than just that if I understood it correctly. And while I am attacking it in a sense, it’s only because I genuinely don’t see how this part could have been done differently in a major way.
- wyldfire 5y ago
  Ignoring Unicode and focusing just on C: if the glyph matches a glyph used in any existing C operator maybe it shouldn't be legal as an identifier character.
  - mananaysiempre 5y ago
    I’m not defending either standard Unicode identifiers or C Unicode identifiers (which are, incidentally, very different things, see WG14/N1518), no :) The Agda people make good use of various mathematical operators, including ones that are very close to the language syntax (e.g. colon as built-in type ascription and equals as built-in definition, but Unicode colon-equals as a substitution operator for a user-defined type of terms in a library for processing syntax), but overall I’m not convinced it’s worth it at all. As a way to avoid going ASCII-only, though, excluding only things that look like syntax might be simultaneously not going far enough (how are homograph collisions between user-defined identifiers any better?) and too far (reliably transplating identifiers between languages that use different sets of punctuation seems like it’d be torturously difficult).
scatters 5y ago
That ship sailed long before Unicode. Even ASCII has characters with multiple valid glyphs (lower case a can lose the ascender, and lower case g is similarly variable in the number of loops), not to mention multiple characters that are often represented with the same glyph (lower case l, upper case I, digit 1).
- WalterBright 5y ago
  That's a font issue with some fonts, not a green light for blessing multiple code points with the exact same glyph. In fact, having a font that makes l I and 1 indistinguishable is plenty of good reason to NOT make this a requirement.