[swift-evolution] Allowing Characters for use as Custom Operators

[Howard Lovatt]

Scala allows a method with one argument to be used infix with spaces either
side, this would allow

for index in 1 ..< 10 by 2 { ... }


if Range had a by method.

This feature has proved popular in Scala.

  -- Howard.

On 29 March 2016 at 21:37, Haravikk via swift-evolution <
swift-evolution at swift.org> wrote:

> Personally I prefer the requirement of spaces; if you require a method to
> have textual operators without spaces then IMO it’s probably not a good
> place to use a textual operator in the first place.
>
> I like the space requirement as it essentially lets textual operators be
> custom keywords, for example the recent thread on striding for loops, we
> could do the following:
>
> for eachIndex in 1 ..< 10 by 2 { … }
>
> With the “by” defined as a custom operator on Range, rather than defining
> a new keyword or for loop variant (since it’s still essentially a for in
> loop). It’s really just a nicer alternative to: (1 ..< 10).by(2).
>
> On 28 Mar 2016, at 16:21, Thorsten Seitz via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Am 08.01.2016 um 09:38 schrieb Jacob Bandes-Storch via swift-evolution <
> swift-evolution at swift.org>:
>
> I'd be hesitant to support something like this. • is a very natural choice
> for a binary operator by itself, and restricting it to require the use of
> spaces seems unfortunate.
>
>
> What about if • would have to begin and end an operator containing letters?
>
> x = a •times• b •mod• 8
>
> This looks more symmetrically (like Haskell’s backticks) and wouldn’t need
> the restriction to require spaces.
>
> Or maybe
>
> x = a ‹times› b ‹mod› 8
>
> Also easily typeable on a Mac keyboard.
>
>
>
> Re: free functions vs. methods: why does this matter? Supposing `foo` were
> the syntax (bad choice, because it already has another meaning, but bear
> with me), then you could disambiguate "a `foo` b" vs "a `self.foo` b" just
> as you can with regular function calls.
>
>
> Indeed.
>
> -Thorsten
>
>
> Re: named parameters: there are two clear choices:
> - Restrict such a syntax to functions without named parameters (seems
> acceptable to me).
> - Ignore parameter names, allowing any binary function to be used
> (challenges with disambiguation, which I believe has had some discussion in
> the other thread about function names).
>
> This might be a crazy idea, but is it possible to support "a myfunc b"
> without any extra delimiters? As far as I can tell, there's currently no
> way this could parse as a valid expression, so there's no ambiguity to
> resolve, although I imagine it would be hard to make diagnostics work well.
> I'm not sure how this would play with precedence, but that hasn't been
> discussed for any of the other solutions either.
>
> Jacob Bandes-Storch
>
> On Fri, Jan 8, 2016 at 12:29 AM, Jo Albright via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> The rationale is the same - the design of Swift really wants operators
>> and identifiers to be partitioned into different namespaces.  Violating
>> that would make it impossible to parse a swift file without parsing all of
>> its imports.  This is a mistake that C made (you have to parse all the
>> headers a file uses to reliably parse the file) that we don’t want to
>> replicate in Swift.
>>
>>
>>
>> Thanks Chris. I now understand the reasoning for separating the two
>> groups. I don’t have a background in language creation, so whatever I can
>> learn from these email lists is awesome. I have already gained a ton of
>> knowledge following these conversations.
>>
>>
>> Alternative: Reserve one of the operator characters as an operator
>> introducer. Everything from that character to the next whitespace is an
>> operator name. This would allow non-operator characters in operator names
>> while still preserving the strict operator/identifier separation.
>>
>>    // • is the operator introducer character
>>    infix operator •times …
>>    infix operator •mod …
>>    x = a •times b •mod 8
>>
>> Limitations:
>> You still can't use an unadorned word as an operator name.
>> You can't use such an operator without whitespace (unlike operators whose
>> names use operator characters only).
>>
>>
>>
>> Oooooo … that is a very cool alternative Greg. Honestly went into this
>> proposal thinking there was no possibility, but now I have a glimmer of
>> hope.
>>
>> Using “•” (option + 8 on keyboard) would be great since it is accessible
>> through key combo, but isn’t widely used in normal expressions.
>>
>> What is needed to prove worth of such a feature to be added?
>>
>>
>>  Nerd . Designer . Developer
>> Jo Albright
>>
>>
>> _______________________________________________
>> 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
>
>
> _______________________________________________
> 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/20160330/ce0726ea/attachment.html>