> On Oct 2, 2017, at 3:24 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
>> On Mon, Oct 2, 2017 at 12:58 PM, David Sweeris <daveswee...@mac.com> wrote:
>>
>>> On Oct 2, 2017, at 09:14, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>>>
>>> What is your use case for this?
>>>
>>>> On Mon, Oct 2, 2017 at 10:56 David Sweeris via swift-evolution
>>>> <swift-evolution@swift.org> wrote:
>>>>
>>>>> On Oct 1, 2017, at 22:01, Chris Lattner via swift-evolution
>>>>> <swift-evolution@swift.org> wrote:
>>>>>
>>>>>
>>>>>> On Oct 1, 2017, at 9:26 PM, Kenny Leung via swift-evolution
>>>>>> <swift-evolution@swift.org> wrote:
>>>>>>
>>>>>> Hi All.
>>>>>>
>>>>>> I’d like to help as well. I have fun with operators.
>>>>>>
>>>>>> There is also the issue of code security with invisible unicode
>>>>>> characters and characters that look exactly alike.
>>>>>
>>>>> Unless there is a compelling reason to add them, I think we should ban
>>>>> invisible characters. What is the harm of characters that look alike?
>>>>
>>>> Especially if people want to use the character in question as both an
>>>> identifier and an operator: We can make the character an identifier and
>>>> its lookalike an operator (or the other way around).
>>
>> Off the top of my head...
>> In calculus, “𝖽” (MATHEMATICAL SANS-SERIF SMALL D) would be a fine
>> substitute for "d" in “𝖽y/𝖽x” ("the derivative of y(x) with respect to x").
>> In statistics, we could use "𝖢" (MATHEMATICAL SANS-SERIF CAPITAL C), as in
>> "5𝖢3" to mimic the "5C3" notation ("5 choose 3"). And although not strictly
>> an issue of identifiers vs operators, “！” (FULLWIDTH EXCLAMATION MARK) would
>> be an ok substitution (that extra space on the right looks funny) for "!" in
>> “4！” ("4 factorial").
>>
>> I'm sure there are other examples from math/science/<insert any
>> "symbology"-heavy DSL here>, but “d” in particular is one that I’ve wanted
>> for a while since Swift classifies "∂" (the partial derivative operator) as
>> an operator rather than an identifier, making it impossible to use a
>> consistent syntax between normal derivatives and partial derivatives (normal
>> derivatives are "d(y)/d(x)", whereas partial derivatives get to drop the
>> parens "∂y/∂x")
>
> I think we should specify from the outset of re-examining this topic that
> supporting arbitrary math/science notation without demonstrable improvement
> in code clarity for actual, Swift code is a non-goal.
I gave up on trying to get the restrictions on the normal "!" removed a while
ago... I guess we'll just have to agree to disagree on !-lookalikes.
Supporting arbitrary math/science notation, though, is almost by definition an
increase in code clarity for the people who are used to it. Is that everyone?
Of course not. Is it the majority? I doubt it; the days when Computer Science
was part of the Math department are long gone, and it's common for people to
become developers without getting any formal education in the field at all
(which is great, IMHO... that means we're successfully making computing more
accessible). That doesn't seem to me like a good reason not to support such
symbolic notations, though. I'm not suggesting a change to the standard library
here, to be forced on everyone -- I'm merely suggesting a way to help people
who prefer the more symbol-heavy notations to use them if they and their teams
(and their clients, if they're a library vendor) want to.
I would never claim that the particular cases I raised are “critical to Swift's
long-term success” or anything (I think the # of people who care about "𝖽y" vs
"d(y)" enough to let it dictate their language choice is probably zero), but I
would like to point out that a few of the threads here have demonstrated just
how differing the opinions are on this matter even within the relatively small
group of people who participate on this list. If Swift’s long-term goal is to
take over the world, that means the language needs to “work” for very diverse
groups of people... We probably shouldn’t be restricting syntax at the language
level unless we actually have to.
- Dave Sweeris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
