blob: 2e9609aec07bc5a0e2844ee9cb031adc41e5d33e (
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
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
|
const vs. data vs. alias
========================
Use cases
---------
There are two use-cases for "constants":
1. Avoiding repetitions of the same value
2. De-coupling values (implementation) from declarations (interface)
Point 1 is almost always desirable.
Point 2 is only sometimes desirable. "Constants" that can change in later
versions can be a problem for several reasons:
- The value can't be used in public definitions.
- Can't be used in compile-time constants.
- Can't be optimized at compile-time.
Some language therefore have both:
- C: "#define" vs "static const"
- C++/C23: "constexpr" vs "const"
But there are actually three cases:
- "data": a constant that is allocated in a module, and whose value is
only known at load-time.
- "const": a constant allocated in a module, but known by the users of
the module. Cannot ever change, so it can be used as a compile-time
constant. I don't know of any language that has this. (Maybe Pascal?)
- "alias": a constant that is inlined wherever it is used
In SLUL
-------
SLUL *could* infer this depending on whether the constant *value* is public
(available in the interface). It *could* also be inferred for "local
variables", which could be converted to global data and/or simple compile-time
aliases, if the data is found to be compile-time constant.
Or, in order to clarify how it works, there could be two different keywords.
Which keywords to use?
Keywords for "open"/"public"/"available"/"frozen" constants
- frozen
- frozen data
- closed - confusing
- open - confusing
- alias - makes it sounds like it would be evaluated multiple times
- copyme
- copyable
- permanent - and change the "closed" keyword to "permanent"?
Keywords for "non-public"/"changable"/"unfrozen" constants.
- data
- upgradable
- updatable
- updateable
I think the same keyword should be used for data and types (structs/enums)
(e.g. what is currently called "closed", but perhaps should be renamed
to "frozen" for clarity).
BUT: there are very few cases where it would make sense to put non-frozen
data in the interface, and in that case, I think it would have to be versioned
anyway. So perhaps it is better to only allow frozen data in the interface?
And using frozen data/types should really be the exception, when one is
100% sure that it will NEVER have to be changed.
|
