1
Once a type name has been defined it also prevails over identifiers
2
representing variables, if the compiler is given a choice. This, too, can
3
result in interesting constructions.
5
Assume a function tt(process) expecting an tt(int) exists in a library. We
6
want to use this function to process some tt(int) data values. So in tt(main)
7
tt(process) is declared and called:
12
No problems here. But unfortunately we once decided to `beautify' our
13
code, by throwing in some superfluous parentheses, like so:
15
int process(int (Data));
18
Now we're in trouble. The compiler now generates an error, caused by its
19
rule to let declarations prevail over definitions. tt(Data) now becomes the
20
name of the tt(class Data), and analogous to tt(int (x)) the parameter tt(int
21
(Data)) is parsed as tt(int (*)(Data)): a pointer to a function, expecting a
22
tt(Data) object, returning an tt(int).
24
Here is another example. When, instead of declaring
26
int process(int Data[10]);
28
we declare, e.g., to emphasize the fact that an array is passed to
31
int process(int (Data[10]));
33
the tt(process) function does not expect a pointer to tt(int) values, but
34
a pointer to a function expecting a pointer to tt(Data) elements, returning an
37
To summarize the findings in the `Ambiguity Resolution' section:
39
it() The compiler will try to remove superfluous parentheses;
40
it() But if the parenthesized construction represents a type, it will try
42
it() More in general: when possible the compiler will interpret a
43
syntactic construction as a declaration, rather than as a definition
44
(of an object or variable).
added
removed
yo/classes/existingtypes.yo
