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
