[swift-evolution] superscripts, subscripts, etc.

[Taylor Swift]

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 at 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 at swift.org> wrote:
>
>
> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution <
> swift-evolution at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171005/4e85c7d4/attachment.html>