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.
-Kevin Ballard
···
On Thu, Feb 4, 2016, at 01:40 PM, Brent Royal-Gordon wrote:
> 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.
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
···
On Feb 4, 2016, at 1:49 PM, Kevin Ballard via swift-evolution <swift-evolution@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.
But `#function` is not a structured representation of the function name suitable for debugger use, is it? It's not machine-parseable.
Here's my use case. I know a programmer who, in Objective-C, frequently uses a macro equivalent to this:
He sprinkles these throughout his code and turns them on when he's trying to debug something where he thinks it'd be helpful.
Now, imagine this guy wants to use his `trace()` function with a hypothetical Swift version of yacc, which like all yaccs writes an enormous ball of unreadable code in one big function for efficiency. So he writes a bunch of rules like:
What does `trace()` print? Normally it would print something like "Parser.yyparse()", but wouldn't it be better to have it print "action for rule `expression: expression '+' expression`"?
I think these debug identifiers are best modeled as being split into two sets. #file, #line, #column, and function (whatever it ends up being called) identify a location in source code and are, at least in theory, modifiable. #dsohandle and a hypothetical #mangledfunction (whatever it ends up being called) identify a location in compiled code and are not modifiable. (There might even be a third one of these representing the current offset into the function, as we see in crash reports.)
Even if we don't decide to do this now, I think we're better off choosing a syntax that can support this feature later. A syntax with name-value pairs is clearer anyway, and it also leaves the door open for us to do something like what I'm describing in the future.
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
In being accepted, 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 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.
Swift uses the the following grammar to define line control statements:
line-control-statement → #line
line-control-statement → #lineline-numberfile-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.
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
<setline.md · GitHub 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."
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@swift.org> wrote:
On Feb 4, 2016, at 1:49 PM, Kevin Ballard via swift-evolution <swift-evolution@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.
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
Swift uses the the following grammar to define line control statements:
line-control-statement → #line
line-control-statement → #lineline-numberfile-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.
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
<setline.md · GitHub
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?
···
on Mon Feb 08 2016, Erica Sadun <swift-evolution@swift.org> wrote:
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@swift.org> wrote:
On Feb 4, 2016, at 1:49 PM, Kevin Ballard via swift-evolution >>> <swift-evolution@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.
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?
If so, I'll put it on my "defer" list. Let me know one way or the other.
Basically I have a bunch of dangling to-do's left over from SE-0028 and I'd like to get them closed out.
Where did "make it long" come from? I'm not sure what the benefit is in
using a long identifier.
-Kevin Ballard
···
On Mon, Feb 8, 2016, at 10:09 AM, Erica Sadun wrote:
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.
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.
Okay. Alternative syntax:
/// - Source: <line> <filename>
or
/** - Source: <line> <filename> */
In other words, make it a doc comment. Comments can go almost anywhere, and we already parse doc comments to extract documentation. Hell, in some cases, we might even be able to usefully set a column number with the inline comment syntax.
I completely disagree with this approach. Making the existing feature “more useful” is orthogonal from repainting it. Getting the paint right is a high priority for Swift 3, but making it “more useful” is low priority.
-Chris
···
On Feb 8, 2016, at 10:45 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
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?
I don’t think this is the right word, simply because “reset” implies more than “set” and “context” sounds more general than what we’re describing here.
Where did "make it long" come from? I'm not sure what the benefit is in using a long identifier.
-Kevin Ballard
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.
From this:
···
On Feb 8, 2016, at 2:05 PM, Kevin Ballard <kevin@sb.org> wrote:
On Mon, Feb 8, 2016, at 10:09 AM, Erica Sadun wrote:
Using something like this as the grammar structure makes sense to me, but I’d suggest something more specific (and longer) for this, perhaps:
Fair enough. I suppose as long as it's useless any further changes
won't break much code anyhow ;-)
···
on Thu Feb 11 2016, Chris Lattner <swift-evolution@swift.org> wrote:
On Feb 8, 2016, at 10:45 AM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
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?
I completely disagree with this approach. Making the existing feature
“more useful” is orthogonal from repainting it. Getting the paint
right is a high priority for Swift 3, but making it “more useful” is
low priority.
I don’t think this is the right word, simply because “reset” implies more than “set” and “context” sounds more general than what we’re describing here.
I don’t think this is the right word, simply because “reset” implies more than “set” and “context” sounds more general than what we’re describing here.
I don’t think this is the right word, simply because “reset” implies more than “set” and “context” sounds more general than what we’re describing here.
I don’t think this is the right word, simply because “reset” implies more than “set” and “context” sounds more general than what we’re describing here.
I don’t think this is the right word, simply because “reset” implies more than “set” and “context” sounds more general than what we’re describing here.