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
