I concur with Taylor and John on this particular issue. As much as I use annotations in my daily work, I wouldn’t want the language cluttered up and there will always be industry unique annotations that would be frustratingly unsupported (e.g. I say “j” and you say “i”). dennis.
> On Oct 5, 2017, at 02:23 AM, John McCall via swift-evolution > <swift-evolution@swift.org> wrote: > >> On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> not to rain on anyone’s parade here but y’all are aware unicode superscripts >> don’t even form a complete alphabet right? This kind of syntax would really >> only work for positive integer literals and I don’t think making a wholesale >> change to the language like this is worth that. > > I agree with this and would add only that making Swift code look like > idiomatic math notation is a huge problem and will probably never yield > satisfactory results. Anyone who's really interested in this would probably > be much better off writing a source-to-source transformation that started > with the mathematical markup of their choice and just rewrote it as > idiomatically as possible. > > John. > >> >> On Thu, Oct 5, 2017 at 1:19 AM, Swift via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> Going a little further... >> >> It’s not hard to imagine a situation where the order of a trailing >> annotation matters. Ie, that X²₃ is a different thing from X₃². (X squared >> sub 3 ≠ X sub 3 squared) >> >> So i think you’d want an array of trailing annotations and an array of >> leading annotations, where an annotation is either a .superscript(U) or a >> .subscript(V). That way you’d be able to preserve the (potentially) relevant >> order. >> >> Dave >> >> Sent from my iPhone >> >> On Oct 5, 2017, at 12:04 AM, John Payne via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>>> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> Chris Lattner wrote: >>>>> >>>>>> Just FWIW, IMO, these make sense as operators specifically because they >>>>>> are commonly used by math people as operations that transform the thing >>>>>> they are attached to. Superscript 2 is a function that squares its >>>>>> operand. That said, perhaps there are other uses that I’m not aware of >>>>>> which get in the way of the utilitarian interpretation. >>>>> >>>>> But there are SO MANY uses for superscripts, subscripts, and other such >>>>> annotations, and they are all context specific, just in math, without >>>>> getting into chemistry, physics, statistics, and so forth. >>>>> >>>>> They’re really more like methods on the object to which they’re attached, >>>>> or the combination of a method and an argument. >>>> >>>> I agree. >>>> >>>>> Wouldn’t classing them as identifiers lend itself better to this? >>>> >>>> No, making them an operator is better for this usecase. >>>> >>>> You want: >>>> >>>> x² to parse as “superscript2(x)” - not as an identifier “xsuperscript2” >>>> which is distinct from x. >>>> >>>> -Chris >>> >>> I’m not competent to evaluate the implications of that, but let me just >>> pass along what makes sense to me. For all I know it may be a restatement >>> in different words, or a higher level view which your approach enables, or >>> I may just have no grasp at all of what’s involved. >>> >>> For brevity I’ll refer to superscripts, subscripts, etc. as annotations. >>> >>> An object may have more than one annotation, as with chemical elements >>> which are usually presented at least with both their atomic number and >>> atomic weight. Moreover, in some circumstances it might not be possible to >>> evaluate the significance of any single annotation without taking one or >>> more others into account, so it might be important to present them >>> together, as in a struct or a collection. >>> >>> Taking them singly, their significance is three part: 1) the type of the >>> object, 2) the position of the annotation, and 3) the value of the >>> annotation. >>> >>> I would parse x² as x.trailingSuperscript(2), or better yet… >>> >>> where X is the type of x, X.annotations would be a struct, similar to the >>> following >>> >>> struct annotations { >>> leadingSuperscript: T? >>> leadingSubscript: U? >>> triailingSuperscript: V? >>> trailingSubscript: W? >>> } >>> >>> Taking this approach, x² would parse as x.annotations.trailingSuperscript = >>> 2, and would fail if X made no allowance for trailingSuperscripts. >>> >>> Annotation values are frequently variables, xⁿ for example, and this is the >>> main reason it seems reasonable to me to class the value as anything >>> permitted by the type associated with an annotation in that position for >>> the overall type in question. >>> >>> I’ll read any replies with interest, but I don’t think I'll have anything >>> more to say on this subject myself. >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
