[Discussion]: Renaming #line, the line control statement


(Erica Sadun) #1

Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md) overloads
the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

Best, -- E


(Jonathan Tang) #2

The primary use for the existing #line directive is for generated code like
parser/lexer generators, right? If so, how about #sourceline, since it
represents the line number in the original source code? I'm also fine with
#setline, but don't like #linenumber because it's not clear what the
difference is between it and #line.

Actually, it'd also be used to reset the line number back to the generated
code, right? In that case, #sourceline seems awkward, and maybe I'll just
go with +1 to #setline.

···

On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution < swift-evolution@swift.org> wrote:

Swift Evolution SE-0028 (
https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md)
overloads
the use of #line to mean both an identifier that maps to a calling site's
line number with a file and acts as part of a line control statement with
the following grammar:

line-control-statement → #line­
line-control-statement → #line­line-number
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>
­file-name
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name>
­
line-number → A decimal integer greater than zero
file-name → static-string-literal
<https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal>
­

The accepted implementation of SE-0028 disambiguates the two by requiring
#line (the control statement) to appear at the first column for the time
being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first
token on a line” whitespace behavior that #line will be getting, and would
like someone to start a discussion about renaming the old #line directive
to something more specific and tailored to its purpose. Once that name
and syntax is settled, we can rename the directive and remove the
whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit
other suggestions.

Best, -- E

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


(Brent Royal-Gordon) #3

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.

···

--
Brent Royal-Gordon
Architechies


(Sean Heber) #4

I like that reasoning. I'd suggest even simpler and go with #source since it also can include a file name.

l8r
Sean

···

Sent from my iPad

On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift-evolution@swift.org> wrote:

The primary use for the existing #line directive is for generated code like parser/lexer generators, right? If so, how about #sourceline, since it represents the line number in the original source code? I'm also fine with #setline, but don't like #linenumber because it's not clear what the difference is between it and #line.

Actually, it'd also be used to reset the line number back to the generated code, right? In that case, #sourceline seems awkward, and maybe I'll just go with +1 to #setline.

On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:
Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md) overloads
the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

Best, -- E

_______________________________________________
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


(Ben Rimmington) #5

#pragma line [line-number] [file-name]

-- Ben

···

On 4 Feb 2016, at 01:24, Erica Sadun via swift-evolution <swift-evolution@swift.org> wrote:

Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md) overloads
the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.


(Lily Ballard) #6

I'm in favor of #setline. It has as nice match to #line because #setline
changes the value that #line returns.

-Kevin Ballard

#source is already earmarked for future directions.

I'm thinking #setline and #sourceline are both good.

I like that reasoning. I'd suggest even simpler and go with #source
since it also can include a file name.

l8r Sean

Sent from my iPad

The primary use for the existing #line directive is for generated
code like parser/lexer generators, right? If so, how about
#sourceline, since it represents the line number in the original
source code? I'm also fine with #setline, but don't like
#linenumber because it's not clear what the difference is between it
and #line.

Actually, it'd also be used to reset the line number back to the
generated code, right? In that case, #sourceline seems awkward, and
maybe I'll just go with +1 to #setline.

Swift Evolution SE-0028
(https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md)
overloads the use of #line to mean both an identifier that maps to
a calling site's line number with a file and acts as part of a line
control statement with the following grammar:

*line-control-statement *→ #line­ *line-control-statement *→ #line­*line-number[1]­**file-
name[2]­* *line-number *→ A decimal integer greater than zero *file-
name *→ *static-string-literal[3]­*

The accepted implementation of SE-0028 disambiguates the two by
requiring #line (the control statement) to appear at the first
column for the time being. This is a stop-gap solution best
remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic
“first token on a line” whitespace behavior that #line will be
getting, and would like someone to start a discussion about
renaming the old #line directive to something more specific and
tailored to its purpose. Once that name and syntax is settled, we
can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to
solicit other suggestions.

Best, -- E

_______________________________________________

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

Links:

  1. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number
  2. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
  3. https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

···

On Wed, Feb 3, 2016, at 06:19 PM, Erica Sadun via swift-evolution wrote:

On Feb 3, 2016, at 6:58 PM, Sean Heber <sean@fifthace.com> wrote:
On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift- >> evolution@swift.org> wrote:

On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift- >>> evolution@swift.org> wrote:


(Greg Parker) #7

I like something that has a verb. We don't expect humans to write this directive, so we should optimize to prevent accidental use of this where you really wanted #line. #setline is better than #sourceline by that metric.

···

On Feb 3, 2016, at 6:54 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

I'm in favor of #setline. It has as nice match to #line because #setline changes the value that #line returns.

-Kevin Ballard

On Wed, Feb 3, 2016, at 06:19 PM, Erica Sadun via swift-evolution wrote:

#source is already earmarked for future directions.

I'm thinking #setline and #sourceline are both good.

On Feb 3, 2016, at 6:58 PM, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:

I like that reasoning. I'd suggest even simpler and go with #source since it also can include a file name.

l8r
Sean

Sent from my iPad

On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The primary use for the existing #line directive is for generated code like parser/lexer generators, right? If so, how about #sourceline, since it represents the line number in the original source code? I'm also fine with #setline, but don't like #linenumber because it's not clear what the difference is between it and #line.

Actually, it'd also be used to reset the line number back to the generated code, right? In that case, #sourceline seems awkward, and maybe I'll just go with +1 to #setline.

On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md) overloads
the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

Best, -- E

_______________________________________________
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

_______________________________________________
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


(Erica Sadun) #8

#source is already earmarked for future directions.

I'm thinking #setline and #sourceline are both good.

···

On Feb 3, 2016, at 6:58 PM, Sean Heber <sean@fifthace.com> wrote:

I like that reasoning. I'd suggest even simpler and go with #source since it also can include a file name.

l8r
Sean

Sent from my iPad

On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The primary use for the existing #line directive is for generated code like parser/lexer generators, right? If so, how about #sourceline, since it represents the line number in the original source code? I'm also fine with #setline, but don't like #linenumber because it's not clear what the difference is between it and #line.

Actually, it'd also be used to reset the line number back to the generated code, right? In that case, #sourceline seems awkward, and maybe I'll just go with +1 to #setline.

On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md) overloads
the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

Best, -- E

_______________________________________________
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


(Jacob Bandes-Storch) #9

Is it true that this feature is only for the purpose of debug symbols /
compiler message locations? If so, what about including the word "debug",
such as #debugline ?

···

On Wed, Feb 3, 2016 at 7:29 PM Brent Royal-Gordon via swift-evolution < swift-evolution@swift.org> wrote:

> line-control-statement → #line­
> line-control-statement → #line­line-number­file-name­
> line-number → A decimal integer greater than zero
> file-name → static-string-literal­
>
> The accepted implementation of SE-0028 disambiguates the two by
requiring #line (the control statement) to appear at the first column for
the time being. This is a stop-gap solution best remedied by renaming #line.
>
> Chris Lattner writes, "The core team isn’t thrilled with the magic
“first token on a line” whitespace behavior that #line will be getting, and
would like someone to start a discussion about renaming the old #line
directive to something more specific and tailored to its purpose. Once
that name and syntax is settled, we can rename the directive and remove the
whitespace rule."
>
> I'd recommend #setline or #linenumber. Starting this thread to solicit
other suggestions.

I don't love the way the current format has two unlabeled parameters in an
arbitrary order. Maybe something more like this?

        #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things
the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever
parameters, so if, for instance, you were writing a parser generator, you
could set #function to the name of the rule a particular piece of code came
from.

--
Brent Royal-Gordon
Architechies

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


(Erica Sadun) #10

I like the idea of generalizing this a lot more than just going with #setline, which is otherwise currently the most popular response in this thread.

-- E

···

On Feb 3, 2016, at 8:29 PM, Brent Royal-Gordon <brent@architechies.com> wrote:

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.


(Jean-Daniel) #11

+1 for using a verb. We don’t need that statement to be short, we just need it to avoid any potential future conflict and so we can make it explicit.

#setline or #setlocation as it does not just change the line, but may change the filename too.

···

Le 4 févr. 2016 à 04:13, Greg Parker via swift-evolution <swift-evolution@swift.org> a écrit :

I like something that has a verb. We don't expect humans to write this directive, so we should optimize to prevent accidental use of this where you really wanted #line. #setline is better than #sourceline by that metric.

On Feb 3, 2016, at 6:54 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

I'm in favor of #setline. It has as nice match to #line because #setline changes the value that #line returns.

-Kevin Ballard

On Wed, Feb 3, 2016, at 06:19 PM, Erica Sadun via swift-evolution wrote:

#source is already earmarked for future directions.

I'm thinking #setline and #sourceline are both good.

On Feb 3, 2016, at 6:58 PM, Sean Heber <sean@fifthace.com <mailto:sean@fifthace.com>> wrote:

I like that reasoning. I'd suggest even simpler and go with #source since it also can include a file name.

l8r
Sean

Sent from my iPad

On Feb 3, 2016, at 7:32 PM, Jonathan Tang via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

The primary use for the existing #line directive is for generated code like parser/lexer generators, right? If so, how about #sourceline, since it represents the line number in the original source code? I'm also fine with #setline, but don't like #linenumber because it's not clear what the difference is between it and #line.

Actually, it'd also be used to reset the line number back to the generated code, right? In that case, #sourceline seems awkward, and maybe I'll just go with +1 to #setline.

On Wed, Feb 3, 2016 at 5:24 PM, Erica Sadun via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
Swift Evolution SE-0028 (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md) overloads
the use of #line to mean both an identifier that maps to a calling site's line number with a file and acts as part of a line control statement with the following grammar:

line-control-statement → #line­
<>line-control-statement → #line­line-number <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/line-number>­file-name <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/Statements.html#//apple_ref/swift/grammar/file-name
<>line-number → A decimal integer greater than zero
<>file-name → static-string-literal <https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/LexicalStructure.html#//apple_ref/swift/grammar/static-string-literal

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

Best, -- E

_______________________________________________
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

_______________________________________________
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

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


(Chris Lattner) #12

Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:

#setsyntacticsourcelocation

or something. :-)

-Chris

···

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.


(Adrian Prantl) #13

Is compatibility with the C preprocessor and other preprocessors that emit #line directives a non-goal for Swift?
I guess we probably don’t want to encourage (ab-)use of the C preprocessor and one could easily translate #line directives to Swift’s syntax by preprocessing the preprocessor output with sed, but I’m curious.

-- adrian

···

On Feb 4, 2016, at 9:31 AM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.

Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:

#setsyntacticsourcelocation

or something. :slight_smile:


(Erica Sadun) #14

What do you feel about something more like:

syntactic-context-statement → #setsyntaxcontext
syntactic-context-statement → #setsyntaxcontext syntactic-control-assignments
syntactic-control-assignments → syntactic-control-assignments, syntactic-control-assignment
syntactic-control-assignments → syntactic-control-assignment
syntactic-control-assignment → line = line-number
syntactic-control-assignment → file = file-name
syntactic-control-assignment → column = column-number
syntactic-control-assignment → function = function-name
syntactic-control-assignment → dsohandle = dsohandle-name

-- E

···

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

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

line-control-statement → #line­
line-control-statement → #line ­line-number­ file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.

Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:

#setsyntacticsourcelocation

or something. :slight_smile:

-Chris


(Dave Abrahams) #15

What does “syntactic” communicate that isn't already in

     #setsourcelocation

?

ommitting-needless-words-ly y'rs,

···

on Thu Feb 04 2016, Chris Lattner <swift-evolution@swift.org> wrote:

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution >> <swift-evolution@swift.org> wrote:

line-control-statement → #line­
line-control-statement → #line­line-number­file-name­

line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by
requiring #line (the control statement) to appear at the first
column for the time being. This is a stop-gap solution best
remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic
“first token on a line” whitespace behavior that #line will be
getting, and would like someone to start a discussion about
renaming the old #line directive to something more specific and
tailored to its purpose. Once that name and syntax is settled, we
can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters
in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are
things the compiler changes automatically, but that might be a silly
reason.)

Perhaps this could even let you set any combination of the #whatever
parameters, so if, for instance, you were writing a parser
generator, you could set #function to the name of the rule a
particular piece of code came from.

Using something like this as the grammar structure makes sense to me,
but I’d suggest something more specific (and longer) for this,
perhaps:

#setsyntacticsourcelocation

or something. :slight_smile:

--
-Dave


(Chris Lattner) #16

What do you feel about something more like:

syntactic-context-statement → #setsyntaxcontext
syntactic-context-statement → #setsyntaxcontext syntactic-control-assignments
syntactic-control-assignments → syntactic-control-assignments, syntactic-control-assignment
syntactic-control-assignments → syntactic-control-assignment
syntactic-control-assignment → line = line-number
syntactic-control-assignment → file = file-name
syntactic-control-assignment → column = column-number
syntactic-control-assignment → function = function-name
syntactic-control-assignment → dsohandle = dsohandle-name

Something like this makes sense to me, but only file and line can really be set by this construct.

-Chris

···

On Feb 4, 2016, at 9:46 AM, Erica Sadun <erica@ericasadun.com> wrote:

-- E

On Feb 4, 2016, at 10:31 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

line-control-statement → #line­
line-control-statement → #line ­line-number­ file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.

Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:

#setsyntacticsourcelocation

or something. :-)

-Chris


(Erica Sadun) #17

How about this then?

syntactic-context-statement → #setsyntaxcontext
syntactic-context-statement → #setsyntaxcontext syntactic-control-assignments
syntactic-control-assignments → syntactic-control-assignments, syntactic-control-assignment
syntactic-control-assignments → syntactic-control-assignment
syntactic-control-assignment → line = line-number
syntactic-control-assignment → file = file-name

* It offers a specific identifier that's unlikely to conflict with future keywords
* It enables the grammar to expand for future syntactic control assignments
* It adds labels so dropped arguments and arbitrary order are easily disambiguated (thanks BRG)

I know Brent prefers reset to set (#resetsyntaxcontext to #setsyntaxcontext), and wanted to punch that point again here.

-- E

···

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

On Feb 4, 2016, at 9:46 AM, Erica Sadun <erica@ericasadun.com <mailto:erica@ericasadun.com>> wrote:

What do you feel about something more like:

syntactic-context-statement → #setsyntaxcontext
syntactic-context-statement → #setsyntaxcontext syntactic-control-assignments
syntactic-control-assignments → syntactic-control-assignments, syntactic-control-assignment
syntactic-control-assignments → syntactic-control-assignment
syntactic-control-assignment → line = line-number
syntactic-control-assignment → file = file-name
syntactic-control-assignment → column = column-number
syntactic-control-assignment → function = function-name
syntactic-control-assignment → dsohandle = dsohandle-name

Something like this makes sense to me, but only file and line can really be set by this construct.

-Chris

-- E

On Feb 4, 2016, at 10:31 AM, Chris Lattner <clattner@apple.com <mailto:clattner@apple.com>> wrote:

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

line-control-statement → #line­
line-control-statement → #line ­line-number­ file-name­
line-number → A decimal integer greater than zero
file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by requiring #line (the control statement) to appear at the first column for the time being. This is a stop-gap solution best remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the magic “first token on a line” whitespace behavior that #line will be getting, and would like someone to start a discussion about renaming the old #line directive to something more specific and tailored to its purpose. Once that name and syntax is settled, we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to solicit other suggestions.

I don't love the way the current format has two unlabeled parameters in an arbitrary order. Maybe something more like this?

  #reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are things the compiler changes automatically, but that might be a silly reason.)

Perhaps this could even let you set any combination of the #whatever parameters, so if, for instance, you were writing a parser generator, you could set #function to the name of the rule a particular piece of code came from.

Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:

#setsyntacticsourcelocation

or something. :slight_smile:

-Chris


(Chris Lattner) #18

It is a non-goal. “clang -E” generates a ton of weird forms that we don’t want or need to support.

-Chris

···

On Feb 4, 2016, at 10:38 AM, Adrian Prantl <aprantl@apple.com> wrote:

#setsyntacticsourcelocation

or something. :-)

Is compatibility with the C preprocessor and other preprocessors that emit #line directives a non-goal for Swift?
I guess we probably don’t want to encourage (ab-)use of the C preprocessor and one could easily translate #line directives to Swift’s syntax by preprocessing the preprocessor output with sed, but I’m curious.


(Lily Ballard) #19

I think you're seriously over-designing here.

This feature isn't something end users are going to use. And it's not
something that will ever reasonably apply to anything except #file and
#line. This feature is only ever intended to be used by tools that auto-
generate source files. The most important concerns here really should
just be that whatever we use is trivial to generate correctly by even
the simplest of tools and is readable. And since this won't ever apply
to anything beyond #file and #line, there's no need to try to generalize
this feature at all.

To that end, since the precedent here is for the compiler directive
#line, I repeat my +1 for #setline. It has the verb, which Greg Parker
rightly points out is a good idea, and it's the simplest solution that
happens to be the closest to the existing precedent (which will help
because any tools that generate these directives for multiple languages,
or for multiple versions of Swift, only have to include/omit the word
"set" instead of generating two completely different directives, and
similarly it becomes trivial to take tools that generate #line
directives and fix up the output with something like `tool | sed
's/^#line\b/#setline/').

-Kevin Ballard

···

On Thu, Feb 4, 2016, at 09:55 AM, Erica Sadun via swift-evolution wrote:

How about this then?

syntactic-context-statement → #setsyntaxcontext syntactic-context-
statement → #setsyntaxcontext syntactic-control-assignments syntactic-control-
assignments → syntactic-control-assignments, syntactic-control-
assignment

syntactic-control-assignments → syntactic-control-assignment syntactic-control-
assignment → line = line-number syntactic-control-assignment → file =
file-name

* It offers a specific identifier that's unlikely to conflict with
  future keywords
* It enables the grammar to expand for future syntactic control
  assignments
* It adds labels so dropped arguments and arbitrary order are easily
  disambiguated (thanks BRG)

I know Brent prefers reset to set (#resetsyntaxcontext to
#setsyntaxcontext), and wanted to punch that point again here.

-- E

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

On Feb 4, 2016, at 9:46 AM, Erica Sadun <erica@ericasadun.com> >>> wrote:

What do you feel about something more like:

syntactic-context-statement → #setsyntaxcontext syntactic-context-
statement → #setsyntaxcontext syntactic-control-assignments syntactic-control-
assignments → syntactic-control-assignments, syntactic-control-
assignment

syntactic-control-assignments → syntactic-control-assignment syntactic-control-
assignment → line = line-number syntactic-control-assignment → file
= file-name syntactic-control-assignment → column = column-number
syntactic-control-assignment → function = function-name syntactic-control-
assignment → dsohandle = dsohandle-name

Something like this makes sense to me, but only file and line can
really be set by this construct.

-Chris

-- E

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

On Feb 3, 2016, at 7:29 PM, Brent Royal-Gordon via swift-evolution >>>>> <swift-evolution@swift.org> wrote:

line-control-statement → #line­ line-control-statement → #line
­line-number­ file-name­ line-number → A decimal integer greater
than zero file-name → static-string-literal­

The accepted implementation of SE-0028 disambiguates the two by
requiring #line (the control statement) to appear at the first
column for the time being. This is a stop-gap solution best
remedied by renaming #line.

Chris Lattner writes, "The core team isn’t thrilled with the
magic “first token on a line” whitespace behavior that #line will
be getting, and would like someone to start a discussion about
renaming the old #line directive to something more specific and
tailored to its purpose. Once that name and syntax is settled,
we can rename the directive and remove the whitespace rule."

I'd recommend #setline or #linenumber. Starting this thread to
solicit other suggestions.

I don't love the way the current format has two unlabeled
parameters in an arbitrary order. Maybe something more like this?

#reset line=50, file="foo.swift"

(I have a soft preference for "reset" over "set" because these are
things the compiler changes automatically, but that might be a
silly reason.)

Perhaps this could even let you set any combination of the
#whatever parameters, so if, for instance, you were writing a
parser generator, you could set #function to the name of the rule
a particular piece of code came from.

Using something like this as the grammar structure makes sense to
me, but I’d suggest something more specific (and longer) for this,
perhaps:

#setsyntacticsourcelocation

or something. :slight_smile:

-Chris

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


(Brent Royal-Gordon) #20

And it's not something that will ever reasonably apply to anything except #file and #line.

Why not `#function`, at least? `#function` is a human-readable indication of the surrounding unit of code. It's not intended to be used to look things up in the compiled file. If you're generating code from a definition somewhere, shouldn't `#function` properly reference that definition, not whatever random garbage your generator spat out because it was easier to structure the generated code that way?

Certainly `#dsoHandle` and the hypothetical `#mangledName`, which refer to locations in compiled code and can be used to look code up at runtime, shouldn't be settable, but I think all of the things that point to source code locations ought to be fair game.

···

--
Brent Royal-Gordon
Architechies