[swift-evolution] Allowing Characters for use as Custom Operators
Félix Cloutier
felixcca at yahoo.ca
Thu Jan 7 13:40:26 CST 2016
What I meant is that they're not operators in the sense that they are defined in a library. These two keywords may semantically be operators, but they are hardcoded in the language grammar to be recognized as operators. Most operators (+, -, /, %, *, etc) are not. See https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/zzSummaryOfTheGrammar.html#//apple_ref/doc/uid/TP40014097-CH38-ID480 <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/zzSummaryOfTheGrammar.html#//apple_ref/doc/uid/TP40014097-CH38-ID480>
Félix
> Le 7 janv. 2016 à 14:14:23, Jo Albright <me at jo2.co> a écrit :
>
> Answers inline.
>
> Nerd . Designer . Developer
> Jo Albright
>
>
>> On Jan 7, 2016, at 11:53 AM, Dennis Lysenko <dennis.s.lysenko at gmail.com <mailto:dennis.s.lysenko at gmail.com>> wrote:
>>
>> Jo, it sounds like you're describing infix functions. If you want to bring up a concrete example, Kotlin has this implementation and it's fantastic for creating your own syntactic sugar.
>>
>
> I am not looking to make the language change. Just want to open up flexibility for naming custom operators.
>
> Currently working on a syntax sugar library for CoreGraphics drawing. Would be nice if I could do something like this :
>
> typealias Point = (x: CGFloat,y: CGFloat)
> typealias Curve = (a1: Point, a1: Point, p: Point)
>
> infix operator m { associativity left precedence 200 }
> infix operator l { associativity left precedence 200 }
> infix operator c { associativity left precedence 200 }
> infix operator fill { associativity left precedence 200 }
>
> public func m (lhs: CGContextRef?, rhs: Point) -> CGContextRef? {
>
> CGContextMoveToPoint(lhs, rhs.x, rhs.y); return lhs
>
> }
>
> public func l (lhs: CGContextRef?, rhs: Point) -> CGContextRef? {
>
> CGContextAddLineToPoint(lhs, rhs.x, rhs.y); return lhs
>
> }
>
> public func c (lhs: CGContextRef?, rhs: Curve) -> CGContextRef? {
>
> CGContextAddCurveToPoint(lhs, rhs.a1.x, rhs.a1.y, rhs.a2.x, rhs.a2.y, rhs.p.x, rhs.p.y); return lhs
>
> }
>
> public func fill (lhs: CGContextRef?, rhs: UIColor) {
>
> rhs.set()
> CGContextFillPath(lhs)
>
> }
>
> func drawRect(rect: CGRect) {
>
> UIGraphicsGetCurrentContext() m (10,10) l (20,20) fill UIColor.redColor()
>
> }
>
> I am also dreaming up a library that is not for app development, but education purposes only. I would love to have the ability to build multiple libraries that are based on different fields (economics, food, sports, etc). These libraries would be written to help students learn to write code with the focus on their favorite activities. This library would be for kids and teens to explore how to write code (possibly even adults that are looking to change fields and trying to get their head around how code works).
>
> Football : (note… just through this together, would be more polished and thought out if it becomes a possibility)
>
> typealias Score = Int
> typealias Yardage = Double
>
>
> struct Team {
>
> var totalYards = Yardage
>
> }
>
> infix operator gain { associativity left precedence 200 }
>
> public func gain (inout lhs: Team, rhs: Yardage) {
>
> lhs.totalYards += rhs
>
> }
>
> func runPlay() {
>
> offense gain 12
>
> }
>
>
>> On Thu, Jan 7, 2016, 11:31 AM Félix Cloutier <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> In a discussion about adding $ to the operator character set (it currently is an identifier character), Chris said that any token must be unambiguously either an identifier or an operator even before operators are "discovered", and that's why the identifier character sets and operator character sets have no overlap right now.
>>
>> "as" and "is" are not operators, they're keywords that were hard-coded into the grammar.
>
> I believe having them on the operator page is confusing then. Maybe there should be an explanation on there that they are not actually operators, but just work like them… thoughts?
> ...
> Closed range
> None
> Range, 135
> is
> Type check
> Left associative
> Cast, 132
> as, as?, and as!
> Type cast
> Left associative
> Cast, 132
> ??
> Nil Coalescing
> Right associative
> Nil Coalescing, 131
>
>> Félix
>>
>>> Le 7 janv. 2016 à 04:31:10, Jo Albright via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>>>
>>> As my obsession grows with custom operators. I have come across wanting to use small words or 1-2 alphabetical characters as custom operators. I noticed that “as” and “is” are character based operators and figured it wouldn’t hurt to propose the allowance of character based custom operators.
>>>
>>> Here are my reasons for allowing them:
>>>
>>> 1. easier to read “within” vs “>*<“ or “|*|”
>>>
>>> 2. potential opportunity to build an educational library to help explain expressions (see below)
>>>
>>> infix operator plus { associativity left precedence 200 }
>>>
>>> public func plus (lhs: Int, rhs: Int) -> Int {
>>>
>>> return lhs + rhs
>>>
>>> }
>>>
>>> let totalApples = 5 plus 5
>>>
>>> 3. potential to write more like a sentence (this isn’t as high of a need, but again a good for entry into the language)
>>>
>>> postfix operator oz { }
>>> postfix operator cup { }
>>> postfix operator gal { }
>>>
>>> public func oz (inout _ lhs: Double) -> Double {
>>>
>>> return lhs
>>>
>>> }
>>>
>>> public func cup (inout _ lhs: Double) -> Double {
>>>
>>> return lhs *= 8.0
>>>
>>> }
>>>
>>> public func gal (inout _ lhs: Double) -> Double {
>>>
>>> return lhs *= 128.0
>>>
>>> }
>>>
>>> let totalLiquidInOunces = 5oz plus 2cup plus 1gal
>>>
>>>
>>> I spent awhile looking to make sure this hasn’t been proposed before. I apologize if it is a repeat.
>>>
>>> Thanks
>>>
>>> Nerd . Designer . Developer
>>> Jo Albright
>>>
>>>
>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160107/1af93402/attachment-0001.html>
More information about the swift-evolution
mailing list