blob: 0181cf0def4ee92a054089926621be94feaa2407 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
Type determination of subexpressions
====================================
Options:
Outermost expression decides
----------------------------
Determine type from outermost/target expression (LRL/SLUL style),
and determine types inwards.
int i
...
# type is `int` because i (the target type) is int
i = a + b
This is intuitive, but:
* Not all expressions have a target type.
E.g. operands of relational operators a+b<c+d or a+b==c+d
Leftmost subexpression decides
------------------------------
# type is that of `i`, because it is the leftmost subexpression
i = a + b
Type promotion
--------------
C uses this method, but SLUL could be slightly smarter by using the
neither-signed-nor-unsigned types, to avoid promotions to unsigned (or
signed) type.
In SLUL, it could be possible to use type promotion in a smarter way:
1. Combine both the target/result type and the operands when determining
the type promotion.
2. Use neither-signed-nor-unsoined types for operands that are within
that range.
Innermost expression decides
----------------------------
This is what happens with dumb RPN-order expression checking:
# This is (a b +) in RPN order
# So the type would be that of `a`.
a + b
|
