Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
~Robert Widmann
+10
On Sat, Jan 2, 2016 at 11:36 PM, Developer via swift-evolution < swift-evolution@swift.org> wrote:
Swift currently does not allow operators to use $ - I assume because the
grammar reserves it in one place: `implicit-parameter-name`. I don't see
why an entire class of identifiers has been eliminated, so I propose $
instead be reclassified as an `operator-character` so it can be used mixed
in with other such characters, but prevents the introduction of
`$Identifier`-style declarations that might conflict with implicit
parameters.~Robert Widmann
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
brent@Brents-MacBook-Pro ~/D/Code> swift
Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
1> "foo"
$R0: String = "foo"
2> print($R0)
foo
--
Brent Royal-Gordon
Architechies
Well, that's just it. $ is a perfectly valid character in identifiers everywhere but in the grammar for operators for some reason. It isn't reserved, it just isn't there.
~Robert Widmann
2016/01/03 0:53、Brent Royal-Gordon <brent@architechies.com> のメッセージ:
Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
brent@Brents-MacBook-Pro ~/D/Code> swift
Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
1> "foo"
$R0: String = "foo"
2> print($R0)
foo--
Brent Royal-Gordon
Architechies
Right. That said, our current operator space (particularly the unicode segments covered) is not super well considered. It would be great for someone to take a more systematic pass over them to rationalize things.
-Chris
On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
brent@Brents-MacBook-Pro ~/D/Code> swift
Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
1> "foo"
$R0: String = "foo"
2> print($R0)
foo
As I recall it, there is no overlap between operator characters and identifier characters. If it's not in the operator set, it's effectively reserved for identifiers.
I also remember someone from Apple confirming what Brent said but I can't find it at the moment.
Félix
Le 3 janv. 2016 à 03:47:39, Developer via swift-evolution <swift-evolution@swift.org> a écrit :
Well, that's just it. $ is a perfectly valid character in identifiers everywhere but in the grammar for operators for some reason. It isn't reserved, it just isn't there.
~Robert Widmann
2016/01/03 0:53、Brent Royal-Gordon <brent@architechies.com> のメッセージ:
Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
brent@Brents-MacBook-Pro ~/D/Code> swift
Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
1> "foo"
$R0: String = "foo"
2> print($R0)
foo--
Brent Royal-Gordon
Architechies_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
Is it considered infeasible for any characters to be allowed in both
identifiers and operators?
On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution < swift-evolution@swift.org> wrote:
> On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
>
>> Swift currently does not allow operators to use $ - I assume because
the grammar reserves it in one place: `implicit-parameter-name`. I don't
see why an entire class of identifiers has been eliminated, so I propose $
instead be reclassified as an `operator-character` so it can be used mixed
in with other such characters, but prevents the introduction of
`$Identifier`-style declarations that might conflict with implicit
parameters.
>
> I believe the reason you don't see any other $ variables is that they're
reserved for the debugger and REPL.
>
> brent@Brents-MacBook-Pro ~/D/Code> swift
> Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15
clang-700.1.81). Type :help for assistance.
> 1> "foo"
> $R0: String = "foo"
> 2> print($R0)
> fooRight. That said, our current operator space (particularly the unicode
segments covered) is not super well considered. It would be great for
someone to take a more systematic pass over them to rationalize things.-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
It's funny that ¢, £, and ¥ are operator characters but not any other currency symbol.
Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution <swift-evolution@swift.org> a écrit :
As I recall it, there is no overlap between operator characters and identifier characters. If it's not in the operator set, it's effectively reserved for identifiers.
--
Michel Fortin
https://michelf.ca
We need a token to be unambiguously an operator or identifier - we can have different rules for the leading and subsequent characters though.
-Chris
On Jan 3, 2016, at 6:02 PM, Jacob Bandes-Storch <jtbandes@gmail.com> wrote:
Is it considered infeasible for any characters to be allowed in both identifiers and operators?
On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
> On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
>
>> Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
>
> I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
>
> brent@Brents-MacBook-Pro ~/D/Code> swift
> Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
> 1> "foo"
> $R0: String = "foo"
> 2> print($R0)
> fooRight. That said, our current operator space (particularly the unicode segments covered) is not super well considered. It would be great for someone to take a more systematic pass over them to rationalize things.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
I'm routinely proven wrong, but if $ was allowed to be either an operator or an identifier, it seems to me that `a <$> b` could produce two different and (potentially) valid ASTs depending only on whether <$> exists as an operator. Some people don't like operator overloading, imagine if you told them that they can't even be sure that what they're looking at is an operator at all.
Félix
Le 3 janv. 2016 à 21:02:40, Jacob Bandes-Storch via swift-evolution <swift-evolution@swift.org> a écrit :
Is it considered infeasible for any characters to be allowed in both identifiers and operators?
On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
>
> I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
>
> brent@Brents-MacBook-Pro ~/D/Code> swift
> Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
> 1> "foo"
> $R0: String = "foo"
> 2> print($R0)
> fooRight. That said, our current operator space (particularly the unicode segments covered) is not super well considered. It would be great for someone to take a more systematic pass over them to rationalize things.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto: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
Blame Unicode. $, ¢, £, and ¥ are the only Currency Symbols that have the Pattern_Syntax property, and since Swift explicitly reserves $ for identifiers that leaves just ¢, £, and ¥ for operators. Although you can in fact use ¤ if you want, which is the symbol that denotes an unspecified currency sign.
I suppose Swift could explicitly include the Currency_Symbol general category in the list of operators, but it seems odd to say that things like ฿, ₦, or ₭ should be operators when they look like letters. It would actually make more sense for Swift to explicitly reserve Currency_Symbol for identifiers, which would remove ¢, £, and ¥ from the operator list (but that would be a bit odd because Pattern_Syntax characters make sense as operators, with $ being the single special case that I'm aware of).
-Kevin Ballard
On Sun, Jan 3, 2016, at 12:55 PM, Michel Fortin via swift-evolution wrote:
Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution <swift-evolution@swift.org> a écrit :
> As I recall it, there is no overlap between operator characters and identifier characters. If it's not in the operator set, it's effectively reserved for identifiers.It's funny that ¢, £, and ¥ are operator characters but not any other currency symbol.
That's an interesting issue, I think you're right. Technically I think it
would only be a problem if you omitted spaces: "a<$>b", since infix
identifiers aren't allowed to have a space on one side but not the other
(thus "a <$> b" couldn't be ">(<(a, $), b)", but "a<$>b" could).
Jacob
On Sun, Jan 3, 2016 at 6:27 PM, Félix Cloutier <felixcca@yahoo.ca> wrote:
I'm routinely proven wrong, but if $ was allowed to be either an operator
or an identifier, it seems to me that `a <$> b` could produce two different
and (potentially) valid ASTs depending only on whether <$> exists as an
operator. Some people don't like operator overloading, imagine if you told
them that they can't even be sure that what they're looking at is an
operator at all.Félix
Le 3 janv. 2016 à 21:02:40, Jacob Bandes-Storch via swift-evolution < > swift-evolution@swift.org> a écrit :
Is it considered infeasible for any characters to be allowed in both
identifiers and operators?On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution < > swift-evolution@swift.org> wrote:
> On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution < >> swift-evolution@swift.org> wrote:
>
>> Swift currently does not allow operators to use $ - I assume because
the grammar reserves it in one place: `implicit-parameter-name`. I don't
see why an entire class of identifiers has been eliminated, so I propose $
instead be reclassified as an `operator-character` so it can be used mixed
in with other such characters, but prevents the introduction of
`$Identifier`-style declarations that might conflict with implicit
parameters.
>
> I believe the reason you don't see any other $ variables is that
they're reserved for the debugger and REPL.
>
> brent@Brents-MacBook-Pro ~/D/Code> swift
> Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15
clang-700.1.81). Type :help for assistance.
> 1> "foo"
> $R0: String = "foo"
> 2> print($R0)
> fooRight. That said, our current operator space (particularly the unicode
segments covered) is not super well considered. It would be great for
someone to take a more systematic pass over them to rationalize things.-Chris
_______________________________________________
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
I have been thinking about this topic a lot, but not '$' symbol, rather the tools to create DSLs within Swift to enable productive & meaningful special casing. (Ruby's Rake vs Make/GNUMake come to mind a lot, or Ruby's Sinatra web framework come to mind, perhaps Python's Flask to a lesser extent, and in general the way things can be constructed for tools like HTTP handling or similar.)
I think native Regular Expressions will enable a lot of things, but if it were possible to have more flexibility in the operator space, a lot could be possible.
My thinking is along the lines of class or struct internal operators or pseudo operators.
The infix operator pattern allows functions without parens. If these can be written to be human language characters, this enables many interesting DSL behaviors.
From thinking about Regular Expression support and how many languages use / to delimit Regular Expression literals, and provide special scoping rules that make escaping \ unnecessary, perhaps there is something to the scoping rules that might be more flexible, long-term?
Apologies if I have wandered off a bit on a tangent but the DSL space seems to tie these together potentially.
I would posit that making human language characters available rather than symbols will have a much greater productivity and creativity impact. (and also likely more accessible by virtue of being potentially readable, literally)
The alternatives at the moment all seem to come back to either stringly-typed dictionaries or to enums + boilerplate.
On Jan 4, 2016, at 12:17 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:
We need a token to be unambiguously an operator or identifier - we can have different rules for the leading and subsequent characters though.
-Chris
On Jan 3, 2016, at 6:02 PM, Jacob Bandes-Storch <jtbandes@gmail.com <mailto:jtbandes@gmail.com>> wrote:
Is it considered infeasible for any characters to be allowed in both identifiers and operators?
On Sun, Jan 3, 2016 at 1:23 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
> On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>> Swift currently does not allow operators to use $ - I assume because the grammar reserves it in one place: `implicit-parameter-name`. I don't see why an entire class of identifiers has been eliminated, so I propose $ instead be reclassified as an `operator-character` so it can be used mixed in with other such characters, but prevents the introduction of `$Identifier`-style declarations that might conflict with implicit parameters.
>
> I believe the reason you don't see any other $ variables is that they're reserved for the debugger and REPL.
>
> brent@Brents-MacBook-Pro ~/D/Code> swift
> Welcome to Apple Swift version 2.1.1 (swiftlang-700.1.101.15 clang-700.1.81). Type :help for assistance.
> 1> "foo"
> $R0: String = "foo"
> 2> print($R0)
> fooRight. That said, our current operator space (particularly the unicode segments covered) is not super well considered. It would be great for someone to take a more systematic pass over them to rationalize things.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution