[Discussion] Modernizing Playground Literals


(Erica Sadun) #1

Presented for discussion and feedback. Thank you in advance for your thoughts.

-- Erica

Modernizing Playground Literals

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/b377a1abb53414b7a9f2#introduction>Introduction

Playground literals tokenize colors, files, and images. They provide drag-and-drop convenience and in-context visualizations that offer easy reference and manipulation when designing playground content. These literals are built using a simple square bracket syntax that, in the current form, conflicts with collection literals. This proposal redesigns playground literals to follow the precedent of #available and #selector.

Thanks to Chris Lattner <https://github.com/lattner> for suggesting this enhancement.

<https://gist.github.com/erica/b377a1abb53414b7a9f2#motivation>Motivation

Color, image, and file literals are currently represented as:

[#Color(colorLiteralRed: red, green: green, blue: blue, alpha: alpha)#]
[#Image(imageLiteral: localResourceNameAsString)#]
[#FileReference(fileReferenceLiteral: localResourceNameAsString)#]
Playground literals present the following features:

They appear within a container designated with [# #] endpoints.
They are marked with a capital camel case role name.
First label arguments use the word literal to punch the construction of each literal item.
There are several issues with this approach:

The enclosing square brackets conflict with collection literals, adding extra work for parsing.
The construction syntax does not follow modern Swift conventions.
The word literal describes the constructed items not the argument being passed to create the literal. It is misplaced in its current use.
<https://gist.github.com/erica/b377a1abb53414b7a9f2#detail-design>Detail Design

Simplifying constructors to octothorpe <https://en.wikipedia.org/wiki/Octothorpe>-delineated identifiers cleans up the language, removes potential grammar conflicts, and follows precedent for other identifiers used in modern Swift. Our proposed identifiers are #colorliteral, #imageliteral, and #fileliteral.

color-literal → #colorliteral(red: unit-floating-point-literal, green: unit-floating-point-literal, blue: unit-floating-point-literal, alpha: unit-floating-point-literal)
unit-floating-point-literal → floating point number greater or equal to zero, less than or equal to one

image-literal → #imageliteral(name: image-resource-name)
image-resource-name → static-string-literal referring to image resource name

file-literal → #fileliteral(resourceName: file-resource-name)
file-resource-name → static-string-literal referring to local resource name
In this design:

Each redesigned identifier uses lower case, to match existing Swift literals.
Arguments use lower camel case labels, as is conventional.
The word literal is added to identifiers denoting each item's role.
The arguments are simplified and standardized to red, green, blue, alpha, imageName, and resourceName.
<https://gist.github.com/erica/b377a1abb53414b7a9f2#alternatives-considered>Alternatives Considered

#resourceliteral may better describe a file resource than #fileliteral.


(Chris Lattner) #2

Presented for discussion and feedback. Thank you in advance for your thoughts.

Hi Erica,

You already know this, but big +1 from me. This is a syntactic construct that people are not supposed to see (which is why I’m not surprised you’re getting no feedback on the list) but it is important for us to pull the syntax inline with everything else, for consistency in the parser.

-Chris

···

On Feb 15, 2016, at 12:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

-- Erica

Modernizing Playground Literals

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/b377a1abb53414b7a9f2#introduction>Introduction

Playground literals tokenize colors, files, and images. They provide drag-and-drop convenience and in-context visualizations that offer easy reference and manipulation when designing playground content. These literals are built using a simple square bracket syntax that, in the current form, conflicts with collection literals. This proposal redesigns playground literals to follow the precedent of #available and #selector.

Thanks to Chris Lattner <https://github.com/lattner> for suggesting this enhancement.

<https://gist.github.com/erica/b377a1abb53414b7a9f2#motivation>Motivation

Color, image, and file literals are currently represented as:

[#Color(colorLiteralRed: red, green: green, blue: blue, alpha: alpha)#]
[#Image(imageLiteral: localResourceNameAsString)#]
[#FileReference(fileReferenceLiteral: localResourceNameAsString)#]
Playground literals present the following features:

They appear within a container designated with [# #] endpoints.
They are marked with a capital camel case role name.
First label arguments use the word literal to punch the construction of each literal item.
There are several issues with this approach:

The enclosing square brackets conflict with collection literals, adding extra work for parsing.
The construction syntax does not follow modern Swift conventions.
The word literal describes the constructed items not the argument being passed to create the literal. It is misplaced in its current use.
<https://gist.github.com/erica/b377a1abb53414b7a9f2#detail-design>Detail Design

Simplifying constructors to octothorpe <https://en.wikipedia.org/wiki/Octothorpe>-delineated identifiers cleans up the language, removes potential grammar conflicts, and follows precedent for other identifiers used in modern Swift. Our proposed identifiers are #colorliteral, #imageliteral, and #fileliteral.

color-literal → #colorliteral(red: unit-floating-point-literal, green: unit-floating-point-literal, blue: unit-floating-point-literal, alpha: unit-floating-point-literal)
unit-floating-point-literal → floating point number greater or equal to zero, less than or equal to one

image-literal → #imageliteral(name: image-resource-name)
image-resource-name → static-string-literal referring to image resource name

file-literal → #fileliteral(resourceName: file-resource-name)
file-resource-name → static-string-literal referring to local resource name
In this design:

Each redesigned identifier uses lower case, to match existing Swift literals.
Arguments use lower camel case labels, as is conventional.
The word literal is added to identifiers denoting each item's role.
The arguments are simplified and standardized to red, green, blue, alpha, imageName, and resourceName.
<https://gist.github.com/erica/b377a1abb53414b7a9f2#alternatives-considered>Alternatives Considered

#resourceliteral may better describe a file resource than #fileliteral.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Daniel Vollmer) #3

[snip]

Ignoring the fact that I think Erica’s proposal is an improvement over the current state, a more general solution would be something like user-defined literals in C++11 (with whatever syntax). A playground could then pre-import the definitions of any literal types it wants to support, without having to change the language / compiler any time a new literal type is added.

I’m not sure whether this use-case is so important (or I’m overlooking something basic) that these items need such special treatment (e.g. #-prefix); couldn’t one just offer global factory functions for the literals in question and treat them specifically in Xcode’s playground UI?

  Daniel.

···

On 15 Feb 2016, at 21:16, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Presented for discussion and feedback. Thank you in advance for your thoughts.

-- Erica

Modernizing Playground Literals


(Erica Sadun) #4

Ken Orr also gave it his blessing if that counts.

-- Erica

···

On Feb 16, 2016, at 10:03 AM, Chris Lattner <clattner@apple.com> wrote:

On Feb 15, 2016, at 12:16 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Presented for discussion and feedback. Thank you in advance for your thoughts.

Hi Erica,

You already know this, but big +1 from me. This is a syntactic construct that people are not supposed to see (which is why I’m not surprised you’re getting no feedback on the list) but it is important for us to pull the syntax inline with everything else, for consistency in the parser.

-Chris

-- Erica

Modernizing Playground Literals

Proposal: TBD
Author(s): Erica Sadun <http://github.com/erica>
Status: TBD
Review manager: TBD
<https://gist.github.com/erica/b377a1abb53414b7a9f2#introduction>Introduction

Playground literals tokenize colors, files, and images. They provide drag-and-drop convenience and in-context visualizations that offer easy reference and manipulation when designing playground content. These literals are built using a simple square bracket syntax that, in the current form, conflicts with collection literals. This proposal redesigns playground literals to follow the precedent of #available and #selector.

Thanks to Chris Lattner <https://github.com/lattner> for suggesting this enhancement.

<https://gist.github.com/erica/b377a1abb53414b7a9f2#motivation>Motivation

Color, image, and file literals are currently represented as:

[#Color(colorLiteralRed: red, green: green, blue: blue, alpha: alpha)#]
[#Image(imageLiteral: localResourceNameAsString)#]
[#FileReference(fileReferenceLiteral: localResourceNameAsString)#]
Playground literals present the following features:

They appear within a container designated with [# #] endpoints.
They are marked with a capital camel case role name.
First label arguments use the word literal to punch the construction of each literal item.
There are several issues with this approach:

The enclosing square brackets conflict with collection literals, adding extra work for parsing.
The construction syntax does not follow modern Swift conventions.
The word literal describes the constructed items not the argument being passed to create the literal. It is misplaced in its current use.
<https://gist.github.com/erica/b377a1abb53414b7a9f2#detail-design>Detail Design

Simplifying constructors to octothorpe <https://en.wikipedia.org/wiki/Octothorpe>-delineated identifiers cleans up the language, removes potential grammar conflicts, and follows precedent for other identifiers used in modern Swift. Our proposed identifiers are #colorliteral, #imageliteral, and #fileliteral.

color-literal → #colorliteral(red: unit-floating-point-literal, green: unit-floating-point-literal, blue: unit-floating-point-literal, alpha: unit-floating-point-literal)
unit-floating-point-literal → floating point number greater or equal to zero, less than or equal to one

image-literal → #imageliteral(name: image-resource-name)
image-resource-name → static-string-literal referring to image resource name

file-literal → #fileliteral(resourceName: file-resource-name)
file-resource-name → static-string-literal referring to local resource name
In this design:

Each redesigned identifier uses lower case, to match existing Swift literals.
Arguments use lower camel case labels, as is conventional.
The word literal is added to identifiers denoting each item's role.
The arguments are simplified and standardized to red, green, blue, alpha, imageName, and resourceName.
<https://gist.github.com/erica/b377a1abb53414b7a9f2#alternatives-considered>Alternatives Considered

#resourceliteral may better describe a file resource than #fileliteral.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution


(Erica Sadun) #5

It's certainly beyond the scope of this proposal. I'm not sure if it passes the Lattner test: "Is there a clear, measurable, immediate benefit to Swift developers rather than being of value for its cleverness?" There's also a general macro system that I know keeps coming up on these threads that ??Dave Abrahams?? is working on for Swift 4 or later.

-- Erica

···

On Feb 16, 2016, at 10:31 AM, Daniel Vollmer via swift-evolution <swift-evolution@swift.org> wrote:

On 15 Feb 2016, at 21:16, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Presented for discussion and feedback. Thank you in advance for your thoughts.

-- Erica

Modernizing Playground Literals

[snip]

Ignoring the fact that I think Erica’s proposal is an improvement over the current state, a more general solution would be something like user-defined literals in C++11 (with whatever syntax). A playground could then pre-import the definitions of any literal types it wants to support, without having to change the language / compiler any time a new literal type is added.

I’m not sure whether this use-case is so important (or I’m overlooking something basic) that these items need such special treatment (e.g. #-prefix); couldn’t one just offer global factory functions for the literals in question and treat them specifically in Xcode’s playground UI?

  Daniel.


(TJ Usiyan) #6

I agree that a general literal syntax is beyond the scope of this proposal
but, in my opinion, the "clear, measurable, immediate benefit to Swift"
would be a means to have literal support that might not force you to accept
all of the literal types inhabitants. As it stands, there are many types
which are poorly served by the literal types available. If I want to use a
string as a literal for my type, I must accept all possible strings (or
blow up at runtime). I would gladly put in extra work to allow a literal
syntax for my type that could be compile time checked.

This is not the literal syntax that I want. It is, however, the literal
syntax that is within scope.

+1

···

On Tue, Feb 16, 2016 at 1:45 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

> On Feb 16, 2016, at 10:31 AM, Daniel Vollmer via swift-evolution < > swift-evolution@swift.org> wrote:
>
>
>> On 15 Feb 2016, at 21:16, Erica Sadun via swift-evolution < > swift-evolution@swift.org> wrote:
>>
>> Presented for discussion and feedback. Thank you in advance for your
thoughts.
>>
>> -- Erica
>>
>> Modernizing Playground Literals
>
> [snip]
>
> Ignoring the fact that I think Erica’s proposal is an improvement over
the current state, a more general solution would be something like
user-defined literals in C++11 (with whatever syntax). A playground could
then pre-import the definitions of any literal types it wants to support,
without having to change the language / compiler any time a new literal
type is added.
>
> I’m not sure whether this use-case is so important (or I’m overlooking
something basic) that these items need such special treatment (e.g.
#-prefix); couldn’t one just offer global factory functions for the
literals in question and treat them specifically in Xcode’s playground UI?
>
> Daniel.

It's certainly beyond the scope of this proposal. I'm not sure if it
passes the Lattner test: "Is there a clear, measurable, immediate benefit
to Swift developers rather than being of value for its cleverness?" There's
also a general macro system that I know keeps coming up on these threads
that ??Dave Abrahams?? is working on for Swift 4 or later.

-- Erica

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