[swift-evolution] [Discussion]: Renaming #line, the line control statement

[Dave Abrahams]

on Mon Feb 08 2016, Erica Sadun <swift-evolution at swift.org> wrote:

> I'm going to throw this out there so I can get this off my
> things-to-do list. This proposal puts forth `resetfilecontext` to
> match Brent's "reset" with Chris's well-specified long symbol: it
> describes what the command does and is unlikely to overlap with any
> future identifiers.
>
> Feedback solicited. 
>
> -- E, who is casting her eye on a few other bike sheds and would like
> this one to be painted purple and done
>
> Disambiguating Line Control Statements from Debugging Identifiers
>
> Proposal: TBD
> Author(s): Erica Sadun <http://github.com/erica>
> Status: TBD
> Review manager: TBD
>  <https://gist.github.com/erica/8decc791e1319987eadd#introduction>Introduction
>
> In being accepted, Swift Evolution SE-0028
> (https://github.com/apple/swift-evolution/blob/master/proposals/0028-modernizing-debug-identifiers.md
> <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 within a file and acts as part of a line
> control statement. This proposal nominates #resetfilecontext to
> replace #line for file and line syntactic source control.
>
>  <https://gist.github.com/erica/8decc791e1319987eadd#motivation>Motivation
>
> Swift uses the the following grammar to define line control statements:
>
> 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 uses by
> requiring #line (the control statement) to appear at the first
> column. This is a stop-gap solution best remedied by renaming #line.
>
> The core team was not satisfied with the 'first token on a line'
> whitespace behavior required for overloading #line. Chris Lattner
> requested 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." Chris also requested a well-specified long symbol,
> adding:
>
> The existing #line feature exists for a very specific purpose: it is
> generated by source generation tools (e.g. gyb), and they are designed
> to change how compiler diagnostics and debug information are
> emitted. Changing the function/symbol on the debugger isn’t something
> that is obviously good, because the debugger has a structured notion
> of the current frame which is a highly symbolic AST representation of
> the function. A text string is probably not sufficient, and may not be
> necessary for all cases. The important point though is that any
> discussion about adding it should be motivated by a concrete use-case,
> and what problem is being solved.
> The discussion took place on-line in the [Discussion]: Renaming #line,
> the line control statement thread.
>
>  <https://gist.github.com/erica/8decc791e1319987eadd#detailed-design>Detailed design
>
> line-control-statement → #resetfilecontext
> line-control-statement → #resetfilecontext line-number file-name
> line-number → A decimal integer greater than zero
> file-name → static-string-literal­
>  <https://gist.github.com/erica/8decc791e1319987eadd#alternatives-considered>Alternatives
> considered
>
> Several alternatives were put forward, of which #setline was the most
> popular. This failed the "make it specific and long" (and presumably
> avoid future naming conflicts) request.
>
> A more flexible grammar was suggested, however, as Kevin Ballard
> pointed out, "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."

+1 for the idea, but...

I don't think we should make this change without also making the feature
useful for things like gyb, which has to use its own home-brew line
directive machinery because #line is AFAIK currently useless for any
known application.  The way it currently works you can only put the
directive at grammatical boundaries in the program where #if would also
work.  For #if this is a feature, but for #resetfilecontext it's a bug.

Isn't it the case that making this feature useful would require a lot
more than the simple syntactic shuffle being proposed here?

> A variety of other keywords were put forward in the discussion and can
> be found in the online discussion.
>
>> On Feb 4, 2016, at 4:06 PM, Chris Lattner via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> 
>>> 
>>> On Feb 4, 2016, at 1:49 PM, Kevin Ballard via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> 
>>> I don't think we can support arbitrary replacements for #function,
>>> since it's perfectly reasonable for people to write code that
>>> expects the format of #function to match what Swift generates.
>>> 
>>> With a theoretical #sourcecontext (or whatever the proposed name
>>> is) that vends different properties for different representations,
>>> it's reasonable to have a property that's explicitly intended to be
>>> a human-readable description of the function and therefore suitable
>>> for letting the description be overridden. But in that case, I'd
>>> suggest adding an @attribute to override the human-readable name
>>> for the function instead of using a #directive. Two reasons why:
>>> 
>>> 1. It's reasonable to expect that the description of the function
>>> remains constant for the entire function, which means it shouldn't
>>> be possible to change the function description halfway through the
>>> function, and
>>> 2. Unlike file/line, the function context is a stack, and when the
>>> function ends, the parent context takes over (e.g. if you have
>>> nested functions or closures in a function). And allowing
>>> #set-style directives to override the function description seems
>>> like it would be confusing; does it replace the current info, or
>>> push new info that has to be popped by another directive, or what?
>>> Restricting this kind of overriding to an @attribute on the
>>> function declaration eliminates this confusion.
>> 
>> I agree, and I’d add one more point: you didn’t mention a use case.
>> 
>> The existing #line (and I tend to agree with Kevin’s upthread
>> commentary about #setline) feature exists for a very specific
>> purpose: it is generated by source generation tools (e.g. gyb), and
>> they are designed to change how compiler diagnostics and *debug
>> information* are emitted.  Changing the function/symbol on the
>> debugger isn’t something that is obviously good, because the
>> debugger has a structured notion of the current frame which is a
>> highly symbolic AST representation of the function.  A text string
>> is probably not sufficient, and may not be necessary for all cases.
>> The important point though is that any discussion about adding it
>> should be motivated by a concrete use-case, and what problem is
>> being solved.
>> 
>> -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
> https://lists.swift.org/mailman/listinfo/swift-evolution

-- 
-Dave