blob: c12548dfa22c6e448ecd3cf23d94b5157526f28c (
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
|
Things that don't work with aliased data:
* Implicit pass-by-const-reference of record types
* Type states, when the object is in a non-final type state.
- except if the type state is embedded as a variable in the type.
Aliasing within expressions
---------------------------
Forbid potential aliasing/side-effects between subexpressions.
Complex way but accurate way of doing it:
- (1) If a subexpression has a side-effect / modifies state, and
- (2) there's any subexpression that might see/alias that data, and
- (3) the latter subexpression is not guaranteed to always happen before or
always after the former subexpression,
- then compilation must fail with an error.
Note that (3) means that things like `a <- a + 1` work.
Further analysis:
- (1) is trivial.
- (2) needs further specification, but this could be a simple as "all
non-local aliasing".
- (3) is complex, see below.
Subexpression execution ordering analysis:
- Assigning each subexpr to the nearest sequence point to the left that
is in a "group" that is a direct ancestor of the subexpression.
(note that a function call also is a group, i.e. arguments and the
function expression itself are evaluated before expressions that depend
on its return value)
- If at any level, the groups are adjacent (i.e. have an adjacent sequence
point between them), then the subexpressions always happen in a specific
order, otherwise they might not do.
|
