<p><em>This new version of the answer tries to take into account the changes
 in the question, and the information exchanged in the comments.</em></p>

<p>This answer assumes that $S$ should be the set of variables that have a
content that is used in some defined fragment of the program, rather
than, at some point in the program, the variables with a content that
will be needed before the end of the program.</p>

<p>For the latter, the usual term is <strong>live</strong> variables, as remarked in a <a href="https://cstheory.stackexchange.com/questions/27393/name-a-set-of-program-variables#comment65551_27393">comment by Klaus Draeger</a>.</p>

<p>The former is a generalisation of the concept of <strong>use</strong>, as appears
in <a href="http://en.wikipedia.org/wiki/Data-flow_analysis" rel="nofollow noreferrer">dataflow analysis</a>, and particularly in such concepts as
<a href="http://en.wikipedia.org/wiki/Use-define_chain" rel="nofollow noreferrer">Use-Define or Use-Definition chains (UD chains)</a>, as well as
Definition-Use chains (DU chains). The concept of <em>use</em> is usually
intended for elementary program statements such as an expression
appearing in an assignment or a function call. Recall that this
originates with analysis and optimization of old Fortran programs in
the late 1960s and in the 1970s, and the was no real concept of a
compound statement at the time in the Fortran language.</p>

<p>But there is no reason not to extend the concept to larger program
fragments that form a meaningful whole. Thus <strong>used variable</strong> or
<strong>used set</strong> seem to be exactly the concepts and terminology that you
are looking for.</p>

<p>Now, there may be a difficulty in defining what is implied in the
expression "is used by". It may just mean: "syntactically appears in",
which is as simple as you can make it. This is indeed purely
syntactic, but rather non satisfactory, because the variable may well
appear only in a statement that changes its value, rather than use the
value it already has. This is too simplistic is is clearly not what
was intended by the creators of the concept.</p>

<p>Then a better definition will state that the occurrence of a variable
must imply that its value is actually used.  But as soon as you say
that, you are no longer in syntax since you must use some of the
meaning of the program fragment to know whether the occurrence of the
variable is for using or for changing its value (or possibly is simply
irrelevant). And when you start using the semantics of the language
construct, there is no clear limit on how much of the semantics you
can use.</p>

<p>The definition given in page 632 of the Dragon Book 1988 is:  </p>

<blockquote>
  <p>We say that a variable is <em>used</em> at a statement $s$ if its $r$-value may be required.</p>
</blockquote>

<p>First one should note the use of <code>if</code> rather than <code>iff</code>, which clearly
indicates that some variables not meeting the condition may end up
being qualified as <em>used</em>. This even reinforced by the <code>may be</code>.</p>

<p>Then, this almost definition does not bring much light on the issue. What does it mean to
<em>be required</em>. Typically, if a variable is an argument to a subprogram
(procedure, function, method, ...), you may think it is required.  But
if further analysis shows that the value of this argument is not
actually used in the subprogram, and the argument is only used to
return a result, the $r$-value of the variable is not required.  Some
may object that this could be handled by an appropriate type system,
which they consider syntax (I do not).  But the fact that a value is
not required may depend on deeper semantic analysis (such as in
example 4 of the question). Furthermore, the evolution of type systems
and type theory tends to allow inclusion in types of most thing you
may want to say or prove about a variable, which would hardly qualify
as syntactic.</p>

<p>Thus the situation is that there is not really an undisputable
syntactic (?) reference definition of "used variable", and it depends
essentially on an arbitrary choice implied by the set of techniques
used to analyze the program and the level of knowledge it brings
regarding actual use of the variable value at run-time.</p>

<p>On the other hand it is possible to give a reference semantic
definition for a set $S$ of <em>used variables</em>:</p>

<blockquote>
  <p>A variable is <em>used</em> in some program fragment iff there is a computation of that program such that the results and effects
     of executing that fragment depend on the value of that variable before execution.</p>
</blockquote>

<p>This is not completely satisfactory, because there are other
parameters that could be considered, and might suggest a different
terminology, though not change the above remarks about syntax and
semantics.</p>

<p>For example, in a sequential context, the above definition is clear,
and refers to the value of the variable before executing the program
(fragment).  However, one may still question what is considered an
effect, what is an impact on execution. Execution time could well be
part of the semantics of a program, or not.  Then, in a parallel
execution context, you would consider more than the initial value of
the variable. But I will ignore this, as the question has not been
considering it (as far as I can see), and I will stick to the
definition above.</p>

<p>The set $S$ thus defined semantically is the most precise
(i.e. minimal) set of variables that can matter in any computation,
though some may not matter in some computation.</p>

<p>But this set is not necessarily computable. It is recursively
enumerable, since a Turing Machine could simulate in parallel all possible
computations, and enumerate all the variables that turn out to be used
effectively (in the sense of our definition) in some computation. But
determining that some variable will not be used in a computation is
undecidable.</p>

<p>The best we can hope for is to exhibit a superset of $S$, such that we
are sure not to miss any relevant variable. This is precisely what is
done by the various techniques that can be called upon to determine
the used variables. But they do not all produce the same result and
the results they give can be more or less precise.</p>

<p>If some program analysis technique $T_i$ produces a set $S_i$ of used
variable, we say that $T_i$ is correct iff $S\subseteq S_i$.</p>

<p>If two techniques $T_1$ and $T_2$ produce respectively the sets $S_1$
and $S_2$, then $T1$ is better, more precise than $T_2$ iff
$S\subseteq S_1\subseteq S_2$.</p>

<p>The only thing that has a precise definition (up to the above caveat)
is the set S, enven though possibly not computable. It is also the
reference for any other set to be considered acceptable in practice, and is the smallest, the most precise of them all.</p>

<p>Hence, the expressions "<em>used set</em>" and "<em>used variable</em>" should be
reserved for that set.</p>

<p>And I suggest that the other sets that are considered in practice,
should use the same name, qualified with the name of the technique
that produced them. If the technique is unique and unnamed, it could
be called the <em>computed use set</em> (what is called <code>SY</code>in the question),
or just <em>used set</em> when there is no ambiguity.</p>

CC BY-SA 3.0
2014-11-13T11:11:49.657Z
I'm not sure this is right, because use-define is about syntax, while the original question is about semantics. For example `x := x; S` uses and defines `x` in the leading statement, but `S` is not semantically affected by this.
Martin Berger
CC BY-SA 3.0
2014-11-13T12:01:24.753Z
@MartinBerger I do adress the issue in my answer. But SoftTimur is not
really clear about it. Even the basic definition of D-U or U-D chains
is actually part of what is pragmatically called static semantics,
though necessarily based on the syntactic representation of the
program. It already requires some algorithmic processing, and there is
no reason to limit that. Why should compiler writers use a weak
definition when stronger ones, based on deeper analysis, can lead to
stronger results and better optimizations. The strict semantics view
is just a limit.
babou
CC BY-SA 3.0
2014-11-13T17:02:43.803Z
Thank you for the comments... Please see my update in OP@MartinBerger @babou
SoftTimur
CC BY-SA 3.0
2014-11-13T10:25:47.927Z
2014-11-14T15:12:05.683Z
2017-04-13T12:32:28.117Z
babou
<p>I am interested in the set of the variables that satisfy the following properties. I would like to find a proper name for them.</p>

<p>We assume that a program $\phi$ has a set of variables $v_0, \ldots, v_n$. I am interested in a subset $S$ of $\{v_0; \ldots; v_n\}$, that informally speaking impacts the execution of the program (i.e., any execution of its statements). For instance</p>

<p>1) For the statement $v_0 := v_1$ that may be executed, $v_1$ impacts the execution of the statement. Thus, $v_1 \in S$ and $v_1 \in SY$.</p>

<p>2) For the statement $v_0 := v_1 * 0$ that may be executed, $v_1$ impacts the execution of the statement, because if $v_1$  is a string value, the multiplication of string and $0$ raises a type error. Thus, $v_1 \in S$ and $v_1 \in SY$. </p>

<p>3) In the statement "If true Then $v_1$ := 1 Else $v_1$ := $v_2$ End", $v_2$ does NOT impact the execution of the statement, because the else branch of the statement will never be executed; the value of $v_2$ will never be read here. Thus, $v_2 \notin S$, but $v_2 \in SY$.</p>

<p>I will define the semantics properly, but before that I would like to find a proper name for the set $S$ that fits the convention. I am thinking of <code>read variables</code>? <code>input variables</code>? <code>possible input variables</code>? <code>precedent variables</code>? <code>dependancy variables</code>? or <code>supporting variables</code>?</p>

<p>Could anyone help?</p>

<p><strong>Edit 1:</strong></p>

<p>Thanks for all the comments, they are really helpful. I decide to edit the OP to make the question clearer.</p>

<p>Actually, I planed to introduce the notion of a set <code>S</code> about <strong>semantics</strong>, and then another set <code>SY</code> about <strong>syntax</strong> that is always a superset of <code>S</code> (because <code>S</code> is hard to analyse). Then, I will make a static analysis to over-approximate <code>SY</code>, thus it over-approximates also <code>S</code>. My question here is about a consistent terminology about <code>S</code> and <code>SY</code> (for the case of read/input).</p>

<p>I have added the case for <code>SY</code> in the 3 examples above. You mentioned another 2 examples:</p>

<p>4) For "If factorial(3)==6 Then v_1 := 1 Else v_1 := v_2 End" (babou), we have $v_2 \notin S$ and $v_2 \in SY$.</p>

<p>5) For "x := x" (Martin Berger), one understanding is that the value of <code>x</code> is first still read, then be assigned to <code>x</code>, so $x \in S$; another understanding is that the value of <code>x</code> does not impact the execution of this statement, so $x \notin S$. I will be OK with both of them (though personally I prefer the latter), as long as if I give a terminology and a definition to <code>S</code>, it is consistent for all the examples. In any case, based on the syntax, we always have $x \in SY$. </p>

<p>Regarding "live variables" (Klaus Draeger), indeed, as babou understood, I am not concerned about "a point in the program regarding what variables are still be needed to finish execution from that point".</p>

<p>Regarding "use-define or use-definition" (babou), from that web page, my understanding is UD is about syntax, and it is what I am going to do with <code>SY</code> (e.g., see what is on the left-hand/right-hand side of an assignment). If I call <code>SY</code> <strong>used variables</strong>, what should I call <code>S</code>? </p>

CC BY-SA 3.0
2014-11-12T13:20:09.930Z
I suggest "relevant variables"... but to be honest, I don't know what exactly you hoping for.. :)
Danny
CC BY-SA 3.0
2014-11-13T02:18:16.853Z
"relevant variables" is not bad... in this case, I still need to differentiate "read" and "write" (or "input" and "output")... so I would say "read-relevant variable" and "write-relevant variable"?
SoftTimur
CC BY-SA 3.0
2014-11-13T11:46:58.753Z
The terms "effect" and "effect set" are also used.
Martin Berger
CC BY-SA 3.0
2014-11-13T12:44:52.243Z
@MartinBerger The concepts of "effect" and "effect set" seem intended to deal with
side-effects in general (cf Wadler and others), whereas my feeling from the
question is that the OP seems more interested in dependency aspects,
and specifically on variables.
babou
CC BY-SA 3.0
2014-11-13T14:20:41.553Z
Your second example is different from the others in that in a sufficiently strongly-typed language, this would actually not be a legal program. Other than that, what you describe is essentially the set of "live variables" as used in data-flow analysis.
Klaus Draeger
CC BY-SA 3.0
2014-11-13T16:51:28.073Z
I would suggest removing all lines from the program that are deemed "impossible to reach" - this is what modern compilers do anyway. After that, see if the chosen subset of variables matches the set of variables used by the modified program.
Ryan Dougherty
CC BY-SA 3.0
2014-11-13T17:25:11.243Z
If you intend to have other set that you consider similarly, I would
actually tend to use the same name, with a standard qualifier to
distinguish S and SY, since you really have two variants of a unique
concept.  That would seem the best way to make life easy for the
reader. The point is that the real set you would wish to consider is
S, but what you can compute is SY with whatever algorithm in
considered good enough. Semantically, SY is an approximation of S, its information is less precise. But
if this is the only case of such a situation with 2 sets, you can get
away with 2 names.
babou
CC BY-SA 3.0
2014-11-13T17:29:35.177Z
So I call `S` **semantic used variables** and `SY` **syntactic used variables**?
SoftTimur
CC BY-SA 3.0
2014-11-13T17:45:49.917Z
Actually, I would call S *used variables* and add a qualifier for SY.
There is a justification for this: S is uniquely defined by the
semantics of the language considered. But SY is dependent on the
sophistication of your static analysis of the program. The static
analysis may or may not try to evaluate conditions in if statements,
to take a trivial example. So, if you are actually trying to compare
algorithms, you may well have several variants of SY, depending on the
techniques used. So the elementary definition could possibly be
qualified *basic*, and another by the corresponding algorithm.
babou
CC BY-SA 3.0
2014-11-13T18:12:38.983Z
S may not be computable, but it is well defined. If you define some
SY, by whatever means, one correctness property you want is S⊂SY.
And if you have two techniques to compute SY, producing SY1 and SY2,
then technique 1 is better than technique 2 iff S⊂SY1⊂SY2.
babou
CC BY-SA 3.0
2014-11-13T18:40:26.877Z
But when we say "used variables", will people systematically refer to `use-define` and refer to what is syntactic? (I don't know to which extent this term is employed, it is just a question.)
SoftTimur
CC BY-SA 3.0
2014-11-13T21:47:05.273Z
What you call syntactic is unprecise. It is whatever you
do when manipulating the syntax, and could even be full interpretation
if no input is expected. In
http://en.wikipedia.org/wiki/Data-flow_analysis, the word *used* is
used without reference to specific program analysis algorithm, only to
refer to the fact that the value of a variable is being used, and that
is defined by the semantics of the language, i.e. by S.  It can
actually be consistently understood as "used so that it has an
impact". So that, e.g., an integer variable with a value that gets
multiplied by zero does not count.
babou
CC BY-SA 3.0
2014-11-13T23:38:28.123Z
This is getting long for comments, and not so convenient. Maybe you can email your answer, to the address on my personal page.
babou
CC BY-SA 3.0
2014-11-14T08:45:16.817Z
Why don't you simplify your life and invent your own terminology, not forgetting clearly to explain **clearly** how you use the terms? There probably isn't a firmly established way of talking about what you have in mind. I like the phrases syntactic effects and semantic effects.
Martin Berger
<semantics><compilers><denotational-semantics><operational-semantics><program-analysis>
Name a set of program variables
SoftTimur
# Name a set of program variables

(Asked by: username_0 on 2014-11-09)

I am interested in the set of the variables that satisfy the following properties. I would like to find a proper name for them.

We assume that a program $\phi$ has a set of variables $v\_0, \ldots, v\_n$. I am interested in a subset $S$ of $\{v\_0; \ldots; v\_n\}$, that informally speaking impacts the execution of the program (i.e., any execution of its statements). For instance

1) For the statement $v\_0 := v\_1$ that may be executed, $v\_1$ impacts the execution of the statement. Thus, $v\_1 \in S$ and $v\_1 \in SY$.

2) For the statement $v\_0 := v\_1 \* 0$ that may be executed, $v\_1$ impacts the execution of the statement, because if $v\_1$ is a string value, the multiplication of string and $0$ raises a type error. Thus, $v\_1 \in S$ and $v\_1 \in SY$.

3) In the statement "If true Then $v\_1$ := 1 Else $v\_1$ := $v\_2$ End", $v\_2$ does NOT impact the execution of the statement, because the else branch of the statement will never be executed; the value of $v\_2$ will never be read here. Thus, $v\_2 \notin S$, but $v\_2 \in SY$.

I will define the semantics properly, but before that I would like to find a proper name for the set $S$ that fits the convention. I am thinking of `read variables`? `input variables`? `possible input variables`? `precedent variables`? `dependancy variables`? or `supporting variables`?

Could anyone help?

**Edit 1:**

Thanks for all the comments, they are really helpful. I decide to edit the OP to make the question clearer.

Actually, I planed to introduce the notion of a set `S` about **semantics**, and then another set `SY` about **syntax** that is always a superset of `S` (because `S` is hard to analyse). Then, I will make a static analysis to over-approximate `SY`, thus it over-approximates also `S`. My question here is about a consistent terminology about `S` and `SY` (for the case of read/input).

I have added the case for `SY` in the 3 examples above. You mentioned another 2 examples:

4) For "If factorial(3)==6 Then v\_1 := 1 Else v\_1 := v\_2 End" (username_3), we have $v\_2 \notin S$ and $v\_2 \in SY$.

5) For "x := x" (username_2), one understanding is that the value of `x` is first still read, then be assigned to `x`, so $x \in S$; another understanding is that the value of `x` does not impact the execution of this statement, so $x \notin S$. I will be OK with both of them (though personally I prefer the latter), as long as if I give a terminology and a definition to `S`, it is consistent for all the examples. In any case, based on the syntax, we always have $x \in SY$.

Regarding "live variables" (username_4), indeed, as username_3 understood, I am not concerned about "a point in the program regarding what variables are still be needed to finish execution from that point".

Regarding "use-define or use-definition" (username_3), from that web page, my understanding is UD is about syntax, and it is what I am going to do with `SY` (e.g., see what is on the left-hand/right-hand side of an assignment). If I call `SY` **used variables**, what should I call `S`?

**Tags:** semantics, compilers, denotational-semantics, operational-semantics, program-analysis

> **Comments:**
> **username_1**: I suggest "relevant variables"... but to be honest, I don't know what exactly you hoping for.. :)  
> **username_0**: "relevant variables" is not bad... in this case, I still need to differentiate "read" and "write" (or "input" and "output")... so I would say "read-relevant variable" and "write-relevant variable"?  
> **username_2**: The terms "effect" and "effect set" are also used.  
> **username_3**: @MartinBerger The concepts of "effect" and "effect set" seem intended to deal with side-effects in general (cf Wadler and others), whereas my feeling from the question is that the OP seems more interested in dependency aspects, and specifically on variables.  
> **username_4**: Your second example is different from the others in that in a sufficiently strongly-typed language, this would actually not be a legal program. Other than that, what you describe is essentially the set of "live variables" as used in data-flow analysis.  
> **username_5**: I would suggest removing all lines from the program that are deemed "impossible to reach" - this is what modern compilers do anyway. After that, see if the chosen subset of variables matches the set of variables used by the modified program.  
> **username_3**: If you intend to have other set that you consider similarly, I would actually tend to use the same name, with a standard qualifier to distinguish S and SY, since you really have two variants of a unique concept.  That would seem the best way to make life easy for the reader. The point is that the real set you would wish to consider is S, but what you can compute is SY with whatever algorithm in considered good enough. Semantically, SY is an approximation of S, its information is less precise. But if this is the only case of such a situation with 2 sets, you can get away with 2 names.  
> **username_0**: So I call `S` **semantic used variables** and `SY` **syntactic used variables**?  
> **username_3**: Actually, I would call S *used variables* and add a qualifier for SY. There is a justification for this: S is uniquely defined by the semantics of the language considered. But SY is dependent on the sophistication of your static analysis of the program. The static analysis may or may not try to evaluate conditions in if statements, to take a trivial example. So, if you are actually trying to compare algorithms, you may well have several variants of SY, depending on the techniques used. So the elementary definition could possibly be qualified *basic*, and another by the corresponding algorithm.  
> **username_3**: S may not be computable, but it is well defined. If you define some SY, by whatever means, one correctness property you want is S⊂SY. And if you have two techniques to compute SY, producing SY1 and SY2, then technique 1 is better than technique 2 iff S⊂SY1⊂SY2.  
> **username_0**: But when we say "used variables", will people systematically refer to `use-define` and refer to what is syntactic? (I don't know to which extent this term is employed, it is just a question.)  
> **username_3**: What you call syntactic is unprecise. It is whatever you do when manipulating the syntax, and could even be full interpretation if no input is expected. In http://en.wikipedia.org/wiki/Data-flow_analysis, the word *used* is used without reference to specific program analysis algorithm, only to refer to the fact that the value of a variable is being used, and that is defined by the semantics of the language, i.e. by S.  It can actually be consistently understood as "used so that it has an impact". So that, e.g., an integer variable with a value that gets multiplied by zero does not count.  
> **username_3**: This is getting long for comments, and not so convenient. Maybe you can email your answer, to the address on my personal page.  
> **username_2**: Why don't you simplify your life and invent your own terminology, not forgetting clearly to explain **clearly** how you use the terms? There probably isn't a firmly established way of talking about what you have in mind. I like the phrases syntactic effects and semantic effects.  

---

## 1 answers

### Answer by username_3 on 2014-11-13. Score: 2 | Accepted answer

*This new version of the answer tries to take into account the changes
in the question, and the information exchanged in the comments.*

This answer assumes that $S$ should be the set of variables that have a
content that is used in some defined fragment of the program, rather
than, at some point in the program, the variables with a content that
will be needed before the end of the program.

For the latter, the usual term is **live** variables, as remarked in a [comment by username_4](https://cstheory.stackexchange.com/questions/27393/name-a-set-of-program-variables#comment65551_27393).

The former is a generalisation of the concept of **use**, as appears
in [dataflow analysis](http://en.wikipedia.org/wiki/Data-flow_analysis), and particularly in such concepts as
[Use-Define or Use-Definition chains (UD chains)](http://en.wikipedia.org/wiki/Use-define_chain), as well as
Definition-Use chains (DU chains). The concept of *use* is usually
intended for elementary program statements such as an expression
appearing in an assignment or a function call. Recall that this
originates with analysis and optimization of old Fortran programs in
the late 1960s and in the 1970s, and the was no real concept of a
compound statement at the time in the Fortran language.

But there is no reason not to extend the concept to larger program
fragments that form a meaningful whole. Thus **used variable** or
**used set** seem to be exactly the concepts and terminology that you
are looking for.

Now, there may be a difficulty in defining what is implied in the
expression "is used by". It may just mean: "syntactically appears in",
which is as simple as you can make it. This is indeed purely
syntactic, but rather non satisfactory, because the variable may well
appear only in a statement that changes its value, rather than use the
value it already has. This is too simplistic is is clearly not what
was intended by the creators of the concept.

Then a better definition will state that the occurrence of a variable
must imply that its value is actually used. But as soon as you say
that, you are no longer in syntax since you must use some of the
meaning of the program fragment to know whether the occurrence of the
variable is for using or for changing its value (or possibly is simply
irrelevant). And when you start using the semantics of the language
construct, there is no clear limit on how much of the semantics you
can use.

The definition given in page 632 of the Dragon Book 1988 is:

> We say that a variable is *used* at a statement $s$ if its $r$-value may be required.

First one should note the use of `if` rather than `iff`, which clearly
indicates that some variables not meeting the condition may end up
being qualified as *used*. This even reinforced by the `may be`.

Then, this almost definition does not bring much light on the issue. What does it mean to
*be required*. Typically, if a variable is an argument to a subprogram
(procedure, function, method, ...), you may think it is required. But
if further analysis shows that the value of this argument is not
actually used in the subprogram, and the argument is only used to
return a result, the $r$-value of the variable is not required. Some
may object that this could be handled by an appropriate type system,
which they consider syntax (I do not). But the fact that a value is
not required may depend on deeper semantic analysis (such as in
example 4 of the question). Furthermore, the evolution of type systems
and type theory tends to allow inclusion in types of most thing you
may want to say or prove about a variable, which would hardly qualify
as syntactic.

Thus the situation is that there is not really an undisputable
syntactic (?) reference definition of "used variable", and it depends
essentially on an arbitrary choice implied by the set of techniques
used to analyze the program and the level of knowledge it brings
regarding actual use of the variable value at run-time.

On the other hand it is possible to give a reference semantic
definition for a set $S$ of *used variables*:

> A variable is *used* in some program fragment iff there is a computation of that program such that the results and effects
> of executing that fragment depend on the value of that variable before execution.

This is not completely satisfactory, because there are other
parameters that could be considered, and might suggest a different
terminology, though not change the above remarks about syntax and
semantics.

For example, in a sequential context, the above definition is clear,
and refers to the value of the variable before executing the program
(fragment). However, one may still question what is considered an
effect, what is an impact on execution. Execution time could well be
part of the semantics of a program, or not. Then, in a parallel
execution context, you would consider more than the initial value of
the variable. But I will ignore this, as the question has not been
considering it (as far as I can see), and I will stick to the
definition above.

The set $S$ thus defined semantically is the most precise
(i.e. minimal) set of variables that can matter in any computation,
though some may not matter in some computation.

But this set is not necessarily computable. It is recursively
enumerable, since a Turing Machine could simulate in parallel all possible
computations, and enumerate all the variables that turn out to be used
effectively (in the sense of our definition) in some computation. But
determining that some variable will not be used in a computation is
undecidable.

The best we can hope for is to exhibit a superset of $S$, such that we
are sure not to miss any relevant variable. This is precisely what is
done by the various techniques that can be called upon to determine
the used variables. But they do not all produce the same result and
the results they give can be more or less precise.

If some program analysis technique $T\_i$ produces a set $S\_i$ of used
variable, we say that $T\_i$ is correct iff $S\subseteq S\_i$.

If two techniques $T\_1$ and $T\_2$ produce respectively the sets $S\_1$
and $S\_2$, then $T1$ is better, more precise than $T\_2$ iff
$S\subseteq S\_1\subseteq S\_2$.

The only thing that has a precise definition (up to the above caveat)
is the set S, enven though possibly not computable. It is also the
reference for any other set to be considered acceptable in practice, and is the smallest, the most precise of them all.

Hence, the expressions "*used set*" and "*used variable*" should be
reserved for that set.

And I suggest that the other sets that are considered in practice,
should use the same name, qualified with the name of the technique
that produced them. If the technique is unique and unnamed, it could
be called the *computed use set* (what is called `SY`in the question),
or just *used set* when there is no ambiguity.

> **Comments:**
> **username_2**: I'm not sure this is right, because use-define is about syntax, while the original question is about semantics. For example `x := x; S` uses and defines `x` in the leading statement, but `S` is not semantically affected by this.  
> **username_3**: @MartinBerger I do adress the issue in my answer. But username_0 is not really clear about it. Even the basic definition of D-U or U-D chains is actually part of what is pragmatically called static semantics, though necessarily based on the syntactic representation of the program. It already requires some algorithmic processing, and there is no reason to limit that. Why should compiler writers use a weak definition when stronger ones, based on deeper analysis, can lead to stronger results and better optimizations. The strict semantics view is just a limit.  
> **username_0**: Thank you for the comments... Please see my update in OP@MartinBerger @username_3  

---

