blob: 9bdcae4dde5ebf18c884167dbc332a4c003c68f5 (
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
|
Typescopes / type identifiers
=============================
SLUL has type scopes:
# The identifer `new` is looked up in the namespace of the `List` type
List l = new
Typescope lookup is triggered by specific identifiers:
new
new_...
from_...
Alternative Syntaxes
--------------------
Could have `.typeident` (like past iterations of SLUL/LRL):
List l = .new
Color c = .rgb 255 255 0
Could have uppercase names (see also uppercase_lowercase.txt):
List l = New
Color c = Rgb 255 255 0
With the current syntax, for comparison:
List l = new
Color c = from_rgb 255 255 0
When should typescopes be used?
-------------------------------
Type scopes can be powerful and simplify code BUT they could also be confusing
in some cases, if the definition and initialisation are "far apart" (or in
different files/modules even):
SomeSetType sst
...
# This is a constructor for `SomeSetType`. It is NOT a `List`!
sst = [ 1 2 ]
One alternative solution could be to allow explicit constructor calls:
SomeSetType sst
sst = SomeSetType [ 1 2 ]
# This *could* also allow type inference. But is that a good idea?
# It can lead to *more* code in some cases:
if use_color
# "Color." appears twice, but would only have appeared once
# with an ordinary definition and typescopes.
c = Color.from_rgb 255 0 0
else
c = Color.from_rgb 127 127 127
end
# With typescopes, for comparison:
Color c
if use_color
c = from_rgb 255 0 0
else
c = from_rgb 127 127 127
end
|
