Date: Tue, 23 Jun 2020 17:24:12 +0200
On Tue, Jun 23, 2020 at 4:27 PM Corentin Jabot <corentinjabot_at_[hidden]>
wrote:
>
> Emojis are not just codepoints, they are a complex grammar that cannot
> just be "allowed", there needs to be a non trivial support. In fact the
> only sane way to support that would be to only allow the "recommended for
> general interchange" emojis from a specific list.
> See http://unicode.org/reports/tr51/ for details.
>
I understand that there are technical issues that make emoji "undesirable"
-- namely, as you point out, the unnecessary(?) complexity that identifying
emojis would introduce in tools.
My suggestion would be to add that explanation of (or a reference to) the
rationale behind the decision.
But again it should be driven by an analysis of use cases for emojis in
> identifiers and the impact on future evolution (emojis are symbols). For
> example Swift found itself in a situation where some emojis are considered
> identifiers and other custom operators.
>
> Same for other scripts, individual letters are allowed but ZWNJ are not.
> UAX#31 lists these scenarios. A quick survey seems to show that there is
> no demand for Farsi, for example, because neither tools or people like to
> deal with mixed-directions languages. Is that a chicken egg problem ? Maybe
>
> Other partially supported scripts are those which use a virama
> https://en.wikipedia.org/wiki/Virama , which is not
> semantically meaningful.
>
> My understanding is that it is not customary for Brahmic scripts to be
> used in programming languages, because of poor IDE or input support, or
> cultural reasons.
> I would definitely love to see a proposal for this, but it should
> ultimately be driven by people familiar with these scripts and who
> understand the demand for them.
>
My point is that it would be interesting to have clear indication in the
paper of what we are effectively dropping.
Maybe we can see it as a matter of educating the reader. Just in case
someone is currently coding C++ in Brahmic, for example, is warned.
And again, we need to adopt the proposal as presented to find ourselves in
> a clean slate from which we can build upon iteratively as/if demand arises.
>
>
wrote:
>
> Emojis are not just codepoints, they are a complex grammar that cannot
> just be "allowed", there needs to be a non trivial support. In fact the
> only sane way to support that would be to only allow the "recommended for
> general interchange" emojis from a specific list.
> See http://unicode.org/reports/tr51/ for details.
>
I understand that there are technical issues that make emoji "undesirable"
-- namely, as you point out, the unnecessary(?) complexity that identifying
emojis would introduce in tools.
My suggestion would be to add that explanation of (or a reference to) the
rationale behind the decision.
But again it should be driven by an analysis of use cases for emojis in
> identifiers and the impact on future evolution (emojis are symbols). For
> example Swift found itself in a situation where some emojis are considered
> identifiers and other custom operators.
>
> Same for other scripts, individual letters are allowed but ZWNJ are not.
> UAX#31 lists these scenarios. A quick survey seems to show that there is
> no demand for Farsi, for example, because neither tools or people like to
> deal with mixed-directions languages. Is that a chicken egg problem ? Maybe
>
> Other partially supported scripts are those which use a virama
> https://en.wikipedia.org/wiki/Virama , which is not
> semantically meaningful.
>
> My understanding is that it is not customary for Brahmic scripts to be
> used in programming languages, because of poor IDE or input support, or
> cultural reasons.
> I would definitely love to see a proposal for this, but it should
> ultimately be driven by people familiar with these scripts and who
> understand the demand for them.
>
My point is that it would be interesting to have clear indication in the
paper of what we are effectively dropping.
Maybe we can see it as a matter of educating the reader. Just in case
someone is currently coding C++ in Brahmic, for example, is warned.
And again, we need to adopt the proposal as presented to find ourselves in
> a clean slate from which we can build upon iteratively as/if demand arises.
>
>
Received on 2020-06-23 10:28:00