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

[John Joyce]

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 at 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 at gmail.com <mailto:jtbandes at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> > On Jan 2, 2016, at 11:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at 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 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/20160104/98708399/attachment.html>