blob: df178384f50a515e545f52a1ea7c41591608910c (
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
|
Uppercase or lowercase identifiers?
===================================
Types
-----
Should all types be UpperCase, even builtin ones?
Bool b
Int i
SignedInt si
String s
# etc.
This would be more consistent.
Also, it would allow removal of the concept of builtin types at the parser
level, so builtin types would just be something in the core.slul file. For
example, `Bool` could be an `enum`, and `Int` could be defined by its range.
(And if type inference is implemented, then untyped integers could get the
smallest possible range.)
Enums and None-Values
---------------------
It will be easier to implement `enum`s if they have their own namespace,
in order to have type-scoped values.
One way to do that is with uppercase identifiers for the enum values.
For example:
enum Color
Red
Green
Blue
end
...
Color c = Red
# In past iterations of SLUL/LRL, this would have been:
Color c = .red
Should the builtin types `true`/`false`/`none` be `True`/`False`/`None`?
It would be more consistent.
Bool b = False
?Item it = None
But uppercase True/False opens up for confusing overrides:
Bool false = True
Perhaps disallow identifiers that are different only in letter case?
Identifiers can (and should) still be case sensitive, though.
Constructors
------------
Constructors and enum values are both "type scoped", and hence related.
Uppercase types *could* also be used for constructors:
List l = New
Color c = FromRgb 255 255 0
# uppercase names would also allow custom names, that don't start with
# new/from:
Color c = Rgb 255 255 0
|
