> On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution > <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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
