Re: [swift-evolution] superscripts, subscripts, etc.

[Chris Lattner via swift-evolution]

> On Oct 5, 2017, at 3:57 AM, Dennis Ferguson via swift-evolution 
>  wrote:
> 
> I concur with Taylor and John on this particular issue. As much as I use 
> annotations in my daily work, I wouldn’t want the language cluttered up and 
> there will always be industry unique annotations that would be frustratingly 
> unsupported (e.g. I say “j” and you say “i”). 

Understandable across the world at large, but one of the points of language 
design is to standardize spelling of things.

-Chris


___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] superscripts, subscripts, etc.

[Nevin Brackett-Rozinsky via swift-evolution]

On Tue, Oct 3, 2017 at 2:02 AM, Chris Lattner via swift-evolution <
swift-evolution@swift.org> wrote:

> You want:
>
> x²  to parse as “superscript2(x)” - not as an identifier “xsuperscript2”
> which is distinct from x.
>
> -Chris


I am of two minds on this. Sometimes I want x² to parse as x*x (an
operator) but other times I want to store the value of x*x in an identifier
spelled… x². This could be simply to avoid repeatedly performing the same
calculation, or it could be the natural result as in,

let r² = someStatisticsThing(xVals, yVals)

Not sure where I’m going with this, just wanted to mention it.

Nevin
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] superscripts, subscripts, etc.

[Dennis Ferguson via swift-evolution]

I concur with Taylor and John on this particular issue. As much as I use 
annotations in my daily work, I wouldn’t want the language cluttered up and 
there will always be industry unique annotations that would be frustratingly 
unsupported (e.g. I say “j” and you say “i”). 
dennis.

> On Oct 5, 2017, at 02:23 AM, John McCall via swift-evolution 
>  wrote:
> 
>> On Oct 5, 2017, at 2:31 AM, Taylor Swift via swift-evolution 
>> > 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 
>> > 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 
>> > wrote:
>> 
>>> 
> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
> > 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 
>>> 

Re: [swift-evolution] superscripts, subscripts, etc.

[John McCall via swift-evolution]

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

Re: [swift-evolution] superscripts, subscripts, etc.

[Taylor Swift via swift-evolution]

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

Re: [swift-evolution] superscripts, subscripts, etc.

[Swift via swift-evolution]

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 
>  wrote:
> 
> 
>>> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
>>>  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

Re: [swift-evolution] superscripts, subscripts, etc.

[John Payne via swift-evolution]

>> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
>> > 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

Re: [swift-evolution] superscripts, subscripts, etc.

[Chris Lattner via swift-evolution]

> On Oct 2, 2017, at 10:56 PM, John Payne via swift-evolution 
>  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

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution