Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Jacob Bandes-Storch via swift-evolution 
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  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)
>> >   foo
>>
>> 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
>> ___
>> 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] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Jacob Bandes-Storch via 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)
> >   foo
>
> 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
> ___
> 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] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Chris Lattner via swift-evolution 
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  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 
>>  wrote:
>> 
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution 
>> >  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
>> 
>> 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
>> ___
>> 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] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Michel Fortin via swift-evolution 
Le 3 janv. 2016 à 13:40, Félix Cloutier via swift-evolution 
 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.

-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Kevin Ballard via swift-evolution 
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 
>  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.

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
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread John Joyce via 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 
>  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  > 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 
>> > wrote:
>> 
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution 
>> > > 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
>> 
>> 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
>> ___
>> 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] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Developer via swift-evolution 
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  のメッセージ:

>> 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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-03 Thread Félix Cloutier via swift-evolution 
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 
>  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  のメッセージ:
> 
>>> 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

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

[swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-02 Thread Developer via 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.

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

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-02 Thread Jacob Bandes-Storch via swift-evolution 
+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-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] [Proposal]: Free the '$' Symbol!

2016-01-02 Thread Brent Royal-Gordon via 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

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