On Oct 2, 2017, at 3:24 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>> 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")
>
> Allowing a custom operator that looks like `!` to be anything other than the
> force-unwrap operator would be unwise, IMO, and not a desirable goal.
> Likewise characters that look like `d` not being the character `d`, etc. In
> the previous PR, the authors deliberately created a system where these will
> not be possible.
I completely agree with Xiaodi here. Even if this were technically possible by
the rules that are defined, it would still be very poor form to do this. It
would violate the swift goal of clarity of code. If these operations need to
be an operator, it would be better to define a *new* operator for these
operations, so that a human at least knows that they donβt know what the
operation does - rather than being misled into thinking they are a familiar
construct.
> 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. Since manipulating
> matrices is a common programming task, and the current BLAS syntax is
> terribly cumbersome, being able to use operators for matrix multiplication,
> inversion, etc. is imminently reasonable. Having a way of writing
> `4.factorial()` that looks like an equation in a math textbook, however,
> wouldn't pass that bar.
+100. Clarity is the important thing, and sometimes operators are the right
way to get that. Emulating math syntax exactly is a non-goal.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
