-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathnotes.txt
70 lines (52 loc) · 3.05 KB
/
notes.txt
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
to compile:
mlton -mlb-path-var 'COMPAT mlton' -default-ann 'allowOrPats true' sources.mlb
IMPORTANT: The pretty printer is contextual.
This means that substitution never actually needs to happen. We know that it's
equivalent to either eagerly substitute values, or to keep them around as a
lookup table with an expression with free variables.
The problem is that substitution is hard, and you can't go back. So the pretty
printer can just take in an un-substituted expression, equipped with its
closure, and then generate the text as needed.
So we never have to actually do substitution, we can just alter the context.
users will be able to enter non-typechecking inputs if we have no type
information...
The first pass (elaboration) is supposed to be contextual, but this duplicates a
lot of annoying code, so I've decided to make it non-contextual.
This means we can't do things like put the context into the Efn, change Eidents
to Econstrs, etc, but this can be done in a later pass.
All function values come equipped with their own reference cell for whether or
not they have been broken. Then, upon breaking a function, that flag will be set
for every copy, including the recursive copies within the special closures for
mutually recursive functions.
This means that breaking functions persists beyond names, but are attached to
the exact function value.
ABSTRACT TYPES
A key issue with abstract types is that the debugger steps into the code of a
function upon invocation.
The code of a function within a module which binds an abstract type has full
knowledge of what the type is, but at the later step in the program, upon
stepping that expression, the type-checker will operate on the premise that it
does not know the implementation of the abstract type, and thus type err.
Normally, problems like this are fixed with the fact that function values
contain their own contexts. However, contexts are not powerful enough to recover
types from opaque ascription. This is because, at function-declaration time, the
program has no idea what types in the scope are later going to be made abstract.
That is something which is only known at ascription time.
So the solution is to modify each valspec to store the known abstract types at
its binding time, and then cause ascription to percolate that information to the
function value itself. So then we can have full knowledge of the proper type,
within the function value itself.
The downside is that we're gonna have to make sure we call a contextual `norm_tyval`
anywhere that might actually rely on what a tyval is.
KNOWN ISSUES:
- It looks like shit
- should probably stop before entering a Let body
- Sources in CM files are processed in linear order, which may not be correct.
For full correctness, they should be processed to determine the dependency
graph, and then an ordering selected from there.
- No support for .mlb files
- Substitution does not work properly for referring to bindings in a module that
is currently being evaluated
- equality types
- update prettysimpledoc
- error handling is not complete (CouldNotFind, Mismatch?)