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.
On Thu, Oct 5, 2017 at 1:19 AM, Swift via swift-evolution < 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> wrote: > > > On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution < > 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 > 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