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.