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
182
183
184
185
|
Separate interface.slul file
----------------------------
Maybe split main.slul of libraries into several parts:
interface.slul (compiler-generated)
imports.lst (see section below. this contains the full impl deps)
sources.lst (see section below)
submodules.lst (see section below)
But there are pros and cons of this.
It's can be nice to have all deps listed in on place.
Probably the interface.slul file could be generated?
- yes: interface_depends (by checking decls)
- yes: slul version (by checking language features used in decsl)
- yes: decls themselves (copied verbatim, so they need explicit since-versions)
Separate files for lists
------------------------
First idea:
imports.lst
sources.lst
submodules.lst
Second version:
imports.index
sources.index
submodules.index
(and in submodules!)
File extension of the imports file:
* Could be expanded to `.list` but `sources.list` is already in use by Debian.
* Perhaps it should be `.index`?
* Should it really be `.lst`? It actually contains tuples of (hash, typename)
on the form `HASH<space>TYPENAME<newline>`.
* Could `.dsv` work even with a space as the separator?
* `.spsv` for space-separated-values
* `.map` for mapping? But it's also used for various "game map" formats.
* `.imp` for imports
* `.kval` for key-value
* `.h2n` for hash-to-name or `.h2t` for hash-to-type
* `.kspv` for key-space-value
* `.hspt` for hash-space-type
* `.hst` for hash-space-type
Language versioning
-------------------
* Target version (not allowed to use more recent features)
* Best-practices version (not allowed to use deprecated features <= this version).
Actually, this is not necessarily a version.
There could be many such best practices (or even strict policies that
ban most features of the language)
Intuitive and foolproof imports
-------------------------------
Having separate interface_depends, since-versions, api-hashes, etc.
is non-intuitive. Can it be improved?
Import hashes to types?
This way, types could be moved between modules. And modules could be an
implementation detail of the execution environment.
imports
hnPpootRHH27AjBXD6Xoo9V_gzEWwpw8XnRXcTQrvlk SomeType
Obviously, the hash itself is "un-userfriendly" but it is an opaque blob
that one would just copy-paste?
Also, the imports could be generated by some tool.
Security: The type name MUST match the one that is being imported.
To import with another name:
hnPpootRHH27AjBXD6Xoo9V_gzEWwpw8XnRXcTQrvlk SomeType St
Should the hash be of the type or the module?
Having hashes of the module would make it easier to see that two imports
come from the same module. Also, it removes a pitfall when importing from
a module where some types have common names, that also appear in other modules.
Also, in that case, the import list should be sorted.
(On the other hand, it also makes it harder to split modules, but maybe there
could be some directive that could be added in both the original and the new
module to indicate that a split has occurred)
Source inclusion
----------------
Include SomeClass.slul and model/Point.slul:
sources
SomeClass
model/Point
Include submodules
submodules
gui
cli
backend
Should submodules be allowed to have imports?
+ limits auditing effort when "risky" stuff is imported.
+ reduces risk of merge conflicts
- multiple files to check (but if there's a submodules.lst file, then it's
easy to just grep for imports.lst)
The source list should probably NOT be allowed to contain paths that belong
to submodules.
Which format to use?
--------------------
ini
+ simple
+ good tooling support
? does it support keys without values?
- needs special chars []
- two comment symbols ; and #
- not all parsers support # comments
- inflexible (only sections and key=value)
keywords with indented contents
+ simple
+ intuitive
- custom format / non-standard / no tooling
custom extensible format:
list of THING
ITEM1
ITEM2
...
list of OTHERTHING
ITEM1
ITEM2
...
section of SECTIONNAME
KEY1 = VALUE1
KEY2 = VALUE2
separate config/lists.
config file for things list name, version, etc. (could be optional)
the lists go into separate files, and could be managed by a CLI tool or IDE.
imports.lst for dependencies.
sources.lst for sources.
submodules.lst for submodules (directories with a sources.list
and/or submodules.lst file)
--> Probably separate config/lists is the best solution.
Auto-generated module interface files
-------------------------------------
This could be really nice, if generated by the compiler when compiling
a library. Some safeguards (e.g. in-line hashes in the source code)
could be used to avoid accidental API/ABI breakage.
But, this also means that the interface file is a generated file.
The distinction between source and generated files matter in many
FLOSS distributions. See the next idea :D
Use central repo to add interfaces
----------------------------------
This is a very much alternative solution ;)
This could even involve a GUI (in addition to a REST API) in the package
repository, where package authors/maintainers can define the versions, and
the types/functions that are added in each version.
But it leads to much centralization, and there's no automatic backup
outside of the package repository. Unless of course, the package/version
metadata is stored in a forkable GIT repository (which is a nice thing
anyway).
|
