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
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
|
Old comments broken out from parsedecl.c
How to distinguish class/enum/interface and extract filename
------------------------------------------------------------
How Java does it:
- classes/records have any names
- interfaces end with -able/-ble
How C# does it
- classes/records have any names
- interfaces being with "I"
How Pascal does it:
- all types begin with T
How C does it:
- built-in types end with _t
Possible options:
* Use English-langauge suffixes like Java:
-able/-ble = interface
-er = class (e.g. FileReader)
others = record/struct
* Use Pascal/C#-like prefixes:
I = interface
C = class
others = record/struct
- problems: needs to handle words start with C, e.g. CssRule
* Use case of filename to distinguish:
Uppercase.slul - class with name = filename
lowercase.slul - mixed no-namespace contents
* Use directories:
interfaces/...
classes/...
records/...
* Use file extensions:
*.if.slul - interfaces
*.cl.slul - classes
*.rc.slul - records
*.slul - mixed no-namespace file
Allow putting the full class hierarchy (i.e. incl. subclasses)
in a single file?
Use filenames for namespacing only and allow LRL-like "here"
definitions?
Keywords to use?
- Want to have the same "kind" of word for all of struct/class/interface.
- It's good if they are the same as in other languages.
struct
record
data
state
class
thing
object
interface
abstract
Or, use "class" for all, but have keywords for the subtype:
unique (but that makes it sound like a singleton)
identity
interface
abstract (maybe even it could work like implicit interfaces?)
- can abstract classes of "identity"(like File) and
"non-identity"(like Point) appear as base classes at the same time?
- when is multiple-inheritance fine?
- interfaces are fine, and interfaces have these properties:
- multiple-inheritance allowed
- cannot be constructed
- do not have data
- calling super.do_stuff() is not possible in
implementing classes
- abstract classes:
- multiple-inheritance allowed
- cannot be constructed
- CAN have data, but perhaps require it to be private?
(i.e. not accessible by implementors of the interface)
- if private, then it should only be accessible from
concrete methods... otherwise, it would create a
"feature imparity" between default implentations and
overridden implementations.
- Disallow super.do_stuff().
- Allow three types of methods/functions:
- abstract / unimplemented
- abstract / with default implementation
- concrete and final
- concrete classes:
- perhaps disallow inheritance from concrete classes
(i.e. all concrete classes are final)
Simple solution:
- have records
- have classes (w/o inheritance)
- have traits/interfaces
More useful types
-----------------
- unions/variants/choice
- how to make it possible to access (and pass around) the enum
value BUT ALSO not have to repeat oneself in the declaration?
- perhaps the enum type could be created implicitly.
- or it could be some kind of generic type perhaps?
e.g. if the tail of classes could be allowed to be a
generic parameter.
- enums
- these could have singleton values, like in Java.
Alternative solution with macros(/mixins)
-----------------------------------------
- record, class and enum types
- Macros for type generation (and usage) of more complex types:
- unions (is it possible?)
- interfaces (needs macro for access also)
Solution with unified classes
-----------------------------
- trait Abstract = interface/trait
- trait Data = trait Equal,Copy,HashCode,StableCompare = record
- perhaps record should provide default impls for equal/copy.
- and "trait Data" could
- Closed types?
- Can runtime type information be avoided?
- E.g. in a list of abstract-typed elements.
- Want to avoid in-object RTTI
- Want to avoid fat pointers
(because they would make generic types fat as well)
- but could be optimized with a per-generic-object size flag
(this could also allow for embedded elements,
which would avoid an extra indirection - good!)
- would require one size field per generic param.
- multiplication factor (to obtain offset) is no longer
constant (= it's slower)
- could also allow only {1,8,16,32,64,128} bits
- could allow for String == List of Byte
(or perhaps String.aliased_to_list() and
String.aliased_from_list())
- or perhaps skip the aliasing stuff, as long
as the String and the List is immutable.
- Want to avoid "concretization wrappers"
(because of indirection AND because of lifetime / memory alloc)
- Reference comparison ability:
- same_as operator for all objects?
- or trait SameAs? trait Identity?
- trait SomeAbstractClass = implements that class
- Uppercase filename = implicit class
- An initial line with only enum/record = turns Uppercase filename class
into an enum/record instead of the default of class
Solution with "here" names:
- `class file` at start for classes
- `record file` at start for records
- `trait file` at start for traits/interfaces
- `enum file` at start for enums
Maybe skip the `file` part?
Other necessary attributes:
- public/export
Nested identifiers/namespaces (e.g. directories) and identifier lookup
at the nested levels.
- just skip namespacing? it's often more annoying than it helps
(as an example, consider all the `import` statements in Java source code,
which is often hidden by default in IDE's anyway, and also has a
tendency to result in libraries using generic names for things, which
makes it impossible to known what a Date or ArrayList is without
checking the imports or by mouse-over in the IDE)
|
