Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: Scala 2.7.2
    • Component/s: Misc Compiler
    • Labels:
      None
    • Environment:

      unicode syntax

      Description

      How very exciting! Scala is the first language I’ve programmed in which has a Unicode character, ⇒, as one of the built-in language operators!

      However, in ‘for’ statements, one must still use primitively-constructed ASCII arrows, as in for(v <- blah) stuff. Please can you allow for(v ← blah) stuff.

      Also, for writing pairs, key → value would be nice.

      Thank you very much.

        Activity

        Hide
        spoon added a comment -

        Geoff, I actually think Unicode is pretty good. My objection is that we should minimize the dependencies users face. I shudder to think of someone posting pretty Scala code in a blog, readers copy pasting it, and the resulting code failing to compile. What do you make of that scenario?

        Iulian, I agree except that I suspect too few people use the Unicode right arrow for us to really draw conclusions. Do you know of any uses in the wild? I bet if we checked some right arrows into the compiler repository, most people wouldn't notice, but an occasional person would get stuck when their svn chose UTF-8 but their scalac chose Latin-1.

        In fact, if there are a lot of people tempted to add more Unicode support, how about we start with just that experiment? Check in a Unicode right arrow and then see if anyone gets tripped up by it. If after a few months not a person has been tripped up, then I retract my objection. If someone does complain, though, we would have evidence that even the existing right arrow support should be deprecated.

        Show
        spoon added a comment - Geoff, I actually think Unicode is pretty good. My objection is that we should minimize the dependencies users face. I shudder to think of someone posting pretty Scala code in a blog, readers copy pasting it, and the resulting code failing to compile. What do you make of that scenario? Iulian, I agree except that I suspect too few people use the Unicode right arrow for us to really draw conclusions. Do you know of any uses in the wild? I bet if we checked some right arrows into the compiler repository, most people wouldn't notice, but an occasional person would get stuck when their svn chose UTF-8 but their scalac chose Latin-1. In fact, if there are a lot of people tempted to add more Unicode support, how about we start with just that experiment? Check in a Unicode right arrow and then see if anyone gets tripped up by it. If after a few months not a person has been tripped up, then I retract my objection. If someone does complain, though, we would have evidence that even the existing right arrow support should be deprecated.
        Hide
        andrewf added a comment -

        Crickey, I seem to have started a robust discussion here. As the original reporter, can I say that personally I have been using the \u21D2 double arrow in my code, and it makes a small, though pleasant improvement to the readability— especially since it’s quite a common Scala operator. If I had the option (again for readability), I’d be tempted to use ≤, ≥, ≠ in my code too. I have been known to define π = 3.14159 on occasion…

        IDEs could choose to display => as ⇒ but you know that they probably won’t. Or at least, the ones everybody uses won’t.

        Some people might have problems when checking out and trying to compile Unicode, under some circumstances. For public code bases (like the Scala runtime libraries), I’d understand (and even support) an ASCII-only rule… But it seems odd to banish the opportunity to use the ‘right’ character for the right purpose just because a lot of tools and systems still don’t have seamless Unicode support yet. Mine does and I’d like to make use of it!

        By the same token, French, Norwegian and Japanese are able to use their native characters in identifiers. You might as well stop them doing so on the basis that it creates potential portability problems.

        Show
        andrewf added a comment - Crickey, I seem to have started a robust discussion here. As the original reporter, can I say that personally I have been using the \u21D2 double arrow in my code, and it makes a small, though pleasant improvement to the readability— especially since it’s quite a common Scala operator. If I had the option (again for readability), I’d be tempted to use ≤, ≥, ≠ in my code too. I have been known to define π = 3.14159 on occasion… IDEs could choose to display => as ⇒ but you know that they probably won’t. Or at least, the ones everybody uses won’t. Some people might have problems when checking out and trying to compile Unicode, under some circumstances. For public code bases (like the Scala runtime libraries), I’d understand (and even support) an ASCII-only rule… But it seems odd to banish the opportunity to use the ‘right’ character for the right purpose just because a lot of tools and systems still don’t have seamless Unicode support yet. Mine does and I’d like to make use of it! By the same token, French, Norwegian and Japanese are able to use their native characters in identifiers. You might as well stop them doing so on the basis that it creates potential portability problems.
        Hide
        Geoffrey Alan Washburn added a comment -

        Done in r15327.

        Show
        Geoffrey Alan Washburn added a comment - Done in r15327.
        Hide
        Andrew Foggin added a comment -

        Small point I know but \u2190 (<-) needs to be added to the language specification as a reserved word (as is already done for \u21D2 (=>))

        Show
        Andrew Foggin added a comment - Small point I know but \u2190 (<-) needs to be added to the language specification as a reserved word (as is already done for \u21D2 (=>))
        Hide
        Geoffrey Alan Washburn added a comment -

        Documentation is updated too, but I can't figure out how to build that. I guess someone can do that next time the website is updated.

        Show
        Geoffrey Alan Washburn added a comment - Documentation is updated too, but I can't figure out how to build that. I guess someone can do that next time the website is updated.

          People

          • Assignee:
            Geoffrey Alan Washburn
            Reporter:
            andrewf
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development