Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Newer
Older
100644 187 lines (101 sloc) 6.149 kb
fccc685 Initial open-source release
MLstate authored
1 TODO 16.07.2009: update! and what is this pprinter_._ml?
2
3 Note :
4 ------
5
6 Aiborne.Mathieu jeudi 18 juin 2009, 12:56:55 (UTC+0100)
7
8 This continues the refactoring of Mikolaj of qml-framework
9
10 Journal :
11 ---------
12
13 qml_base was a big bad blob
14 the typer is very jalous and not friendly at all about leting an other typer to be here. (bad if we want a HM(X) typer on day...)
15
16 So, let's refactore a bit !
17
18 qml_base.ml and ast.ml are now splitted in to several modules
19
20 This modules are not intented to be open, but to be used like the ocaml library :
21
22 List.fold_left .... much better than open List !!
23
24 So, use it in the same way :
25
26 QmlAstCons.ident ...
27
28 Since opa has very common modules, the modules are named prefixed with Qml...
29
30
31 qmlAst is the defintion of the qml ast
32 Everymodule depends on it.
33
34 The work of having it separatly has allready be done by miko : thanks :)
35
36
37 It could possibly contain also common interfaces for the future implementations
38 (like typer, dbGen, etc...)
39
40 it has no mli file because it define mostly only type (avoid duplication)
41
42 After that, there is all the qmlAst* family
43 They implements specific tools and must be short, simple, and with a strong mli
44
45 +++ jeudi 18 juin 2009, 14:18:46 (UTC+0100)
46
47 in the all the modules trx, there are direct call to FreshInt, depending directly on the representation of the ast. default.trx use ExprIdent as well.
48
49 a better approach is to use qmlAstCons systematicly in the all the parser trx
50
51 some files seams to be unused, it is comlicated to understand e.g. what comment is used ? comment.trx seams not to be
52
53 qml_parser and qmlMainParser have a lot of conflicted productions ....
54
55 but qml_parser seems not to be used : will be removed
56
57
58 +++ jeudi 18 juin 2009, 22:15:33 (UTC+0100)
59
60 Trx_qml_gen is contains Constructor and things with grammar
61
62 one part will be reported in qmlAstCons
63 the other part is a TODO !
64
65 it is also very weird that it provides some "to_string" features, but depends on qmlPrinters !
66
67
68 +++ vendredi 19 juin 2009, 00:14:02 (UTC+0100)
69
70 QmlPrinters : contain a (try-to-be-)parsable printer for qml, and an other one, more debug-friendly adding some annotation in the printed string (not parsable) like annotation or instance of types, ...
71
72 About monomorph !
73
74 It would be good that it is shared between all the differents typer (or not ?)
75
76 But it needs something like a TypeEnv.t
77 maybe then it is specific for any typer ?
78
79 But, there is an other thing about TypeEnv :
80
81 all the people who need a typer needs to know public interface about how to use it (so, at least, an API is public an the same for all differents typer (use a simple functor), and need some high level function, like : check-file ~output:"myfile.qmli" (or something like it)
82
83 There are severals possiblities, but which one is good ?
84
85 TypeEnv can be the same, shared in interface between typer, and with a public interface.
86
87 Then, it means that TypeScheme are the same everywhere (that is not so good, because I don't agree with the type of TypeScheme in the actual typer..., and would like to implement an other version of the typer with an other type for typescheme)
88
89 Possibly, we define an interface for a TypeEnv what is it, and what it is supposed to do --
90
91 then, monomorph is a functor of a TypeEnv
92
93 so, TypeEnv should contains some function like
94 TypeScheme.to_ty , and can abstract the type TypeScheme
95
96 In that way, we will be able to use the same monomorph if we write an HM(X) version of the typer
97
98 Don't call me a functor-man if you don't propose a simplier solution (but keeping the flexibility)
99
100 in fact, there is an other problem with it, and a functor is then not so good, you'll see it in the next part :
101
102 ---
103
104 So, know, we arrived at the typer ...
105
106 What should be do in order that we could have as much typer as me want, sharing all what can be, and having specificities they want....
107
108
109 1) A interface with public types
110
111 without that, it is impossible to change all the code that use several typer (call-code, like qml2ocaml, qmlToplevel, etc...)
112
113
114 2) We want to keep the high level functions (like output_keep_code) for each typer (so, we need a functor from the implementation to a high level ModuleTyper
115
116
117 That corresponds to the module MakeAstTyper that was in ast.ml before airborne.
118
119
120 3) Since the typevar are strongly incrusted in the AST, the typers must at least start from it (possibly redefine an private ast with other TypeVar in intern)
121
122 That could be a problem because for example, I disagree with the key managment in the old TypeVar version, so, I've modified it, and it could possibly change the behavior of other typer... Beware
123
124 Having a parametric type for the types would be difficult, and complexify the fact that we could change the typer dynamicly
125
126 4) what do we want about mixity use ?
127
128 should it be possible to type a NewVal with a typer, and an other one with an other Typer ??
129
130 if yes, then TypeEnv must be common. (that simplify the life of monomorph, but then we have the problem of fixed-implemented-TypeScheme
131
132
133 the typer needs some hack in the TypeEnv, hard to let it public ...
134
135
136 So maybe, implement a typer is something like :
137 implement an instance of TypeEnv, and the typer what does go together
138 (* *)
139
140
141 about TypeScheme :
142 ------------------
143
144 I am quite scary because the side effect on TypeVar could have an effect an TypeScheme (for example, if we call unify on a ty from a TypeScheme, it compromise its integrity)
145
146 so, maybe the way to do it properly would be such a thing like :
147
148 module TypeScheme :
149 sig
150 type t
151 val public : t -> TypeVar.t list * ty
152
153 ....
154 end
155
156
157
158 about annotation : maybe we could get in mind that it could be functionnal ?
159
160
161 QmlPrinters
162 Qml_base
163 Typer
164 Typer_new_subtyping_rules
165 QmlMainParser
166 Ast
167 MetaAst
168 Lambda_lifting
169 Monomorph
170 Trx_qml_gen
171 DbGenByPass
172 DbGenHelpers
173 DbGen_private
174 Schema_private
175 QmlDbGen
176
177
178
179 TODO : no time for it (too much things at one time)
180 BUT MUST BE DONE !!
181 ---------------------------------------------------
182
183 unify the module qmlAstCons and the same part of it in trx_qml_gen
184
185 dont let appear any AST Constructor in the parser trx, use only constructor from qmlAstCons
186
Something went wrong with that request. Please try again.