tchrist would probably agree that $addresses[🙈][🙉][🙊] looks pretty, but you probably can't get it to compile without a source filter or patch.
The biggest problem is that those aren’t even identifier characters:
% uniprops 1F648 1F649 1F64A
U+1F648 ‹🙈› \N{SEE-NO-EVIL MONKEY}
\pS \p{So}
All Any Assigned InEmoticons Common Zyyy Emoticons So S Gr_Base
Grapheme_Base Graph GrBase Other_Symbol Print Symbol X_POSIX_Graph
X_POSIX_Print
U+1F649 ‹🙉› \N{HEAR-NO-EVIL MONKEY}
\pS \p{So}
All Any Assigned InEmoticons Common Zyyy Emoticons So S Gr_Base
Grapheme_Base Graph GrBase Other_Symbol Print Symbol X_POSIX_Graph
X_POSIX_Print
U+1F64A ‹🙊› \N{SPEAK-NO-EVIL MONKEY}
\pS \p{So}
All Any Assigned InEmoticons Common Zyyy Emoticons So S Gr_Base
Grapheme_Base Graph GrBase Other_Symbol Print Symbol X_POSIX_Graph
X_POSIX_Print
And Perl isn’t fond of random symbols appearing where it is expecting a TERM.
| [reply]
[d/l] |
I know. They are not letters.
It's an academic difference though. No reason why a language couldn't include them for whatever purpose it wants. In fact, because they are not part of any existing words, it makes it easy to grab them to use for some hot-wired specific purpose, like a single-character constant.
I have a dim memory of musing over that with the Perl6 people, as characters for constants or as part of user-defined operators were often classified wrong for the intended purpose. So it needs a way to specify, lexically, such a classification as well.
A source filter could easily expand odd characters into something else, such as a legal identifier name. Because they are abnormal, it stands a good chance of not messing up the rest of the file as filters are wont to do.
It would be interesting to see if anyone could get it to compile in 5.14 without a source filter. Perhaps munging the unicode database, perhaps other tricks I don't know about, perhaps some combination of overloads and other junk.
| [reply] |
