TODO 4.52 KB
Newer Older
POTTIER Francois committed
1
------------------------------------------------------------------------------
POTTIER Francois committed
2

POTTIER Francois committed
3
TODO (REALLY)
POTTIER Francois committed
4

POTTIER Francois committed
5
Better clean up & share code at the three call sites of [bulk].
POTTIER Francois committed
6

POTTIER Francois committed
7
------------------------------------------------------------------------------
POTTIER Francois committed
8

POTTIER Francois committed
9
TODO (PERHAPS)
POTTIER Francois committed
10

POTTIER Francois committed
11 12 13 14
Philip's question: when you compose two transformations formulated as map
visitors, can you deforest? (eliminate the allocation of the intermediate
tree)

POTTIER Francois committed
15 16
Document Jonathan's example where every node in an "expression" carries a type
and the visitor for expressions carries the type down (whereas the visitor for
POTTIER Francois committed
17
types doesn't). https://github.com/FStarLang/kremlin/blob/visitors/src/Ast.ml
POTTIER Francois committed
18

POTTIER Francois committed
19 20
Document hexpr_polymorphic. Make VisitorsHashcons available as a library.

POTTIER Francois committed
21 22 23 24 25
If there is an error, then the warnings are never seen,
  because they are placed in the generated code.
  Can we fix this?
  e.g. type t = A of (int -> int)[@opaque]

POTTIER Francois committed
26 27 28
In fully [polymorphic] mode, perhaps one could allow [@@deriving visitors]
  to be used in an .mli file, producing class types.

POTTIER Francois committed
29 30 31 32 33
In [polymorphic] mode, we could annotate every invocation
  of an external visitor method with its expected (polymorphic) type,
  so as to get better type error messages if this method does not have
  the expected type.

POTTIER Francois committed
34 35
Ideally, a visitor method should be parameterized with visit_'a
  only if 'a appears in the type of some component.
POTTIER Francois committed
36 37 38 39 40 41 42
It would be good if a type parameter ['a] could be declared never-visited,
  so the method or function [visit_'a] would be unneeded.
  Could be useful for phantom type parameters, GADTs, 'bn, etc.
  The problem is, when a nonlocal type constructor is applied,
  we cannot know which parameters are phantom.
  Unless we find a way of declaring that, too?

POTTIER Francois committed
43 44 45 46
Think about enabling [polymorphic] and [fold] together.
That would require letting the user specify the result type
  associated with each type constructor.

POTTIER Francois committed
47 48 49
Implement and document endoreduce?
  Share code by using "Map endo" internally where endo : bool.

POTTIER Francois committed
50 51
Maybe [fold] and [fold2] in VisitorsRuntime should just be aliases
  for [map] and [map2]. The user can use [nude] if that it is not appropriate.
POTTIER Francois committed
52

POTTIER Francois committed
53 54
Once we have that, can we deal with GADTs?

POTTIER Francois committed
55 56
In [fold],
  the build_ methods could take not only the results of the recursive calls,
POTTIER Francois committed
57 58 59 60 61 62 63 64 65
  but also their arguments (for added expressive power). That would be a
  true "recursor" (David Chemouil).

Could we have visitors where a state is explicitly threaded from left to right?
  (David Chemouil.)
For greater generality, maybe we should have monadic visitors.
Currently, the environment monad (a reader monad) is built-in.
Could we let the user choose which monad should be used,
  without breaking compatibility?
POTTIER Francois committed
66

POTTIER Francois committed
67 68
Develop a real test suite, with expected output.
  Check for left-to-right traversal order.
POTTIER Francois committed
69 70 71
  Release the test suite, too?
  Some tests have dependencies on other packages: hashcons, core_bench...
  Run these tests only if these packages are installed, warn otherwise?
POTTIER Francois committed
72 73 74 75

Add [opaque] as an option, carrying a list of types.
  That would be lighter than writing [@opaque] at every occurrence.

POTTIER Francois committed
76
Include an option [except t] to omit the definition of visitor methods for the type [t].
POTTIER Francois committed
77 78 79
  That would allow the user to provide their own implementation,
  (possibly inherited / polymorphic),
  without having to satisfy the type constraints imposed by our implementation.
POTTIER Francois committed
80
  e.g. could generate a [map] visitor where one type (in a family) is rewritten to something completely different
POTTIER Francois committed
81

82 83
Detect and reject existential types and GADTs.

POTTIER Francois committed
84 85 86 87
Could define a fold visitor where the methods receive the names of the types,
data constructors, and record fields that are being visited. (As in
ppx_tools/genlifter.)

POTTIER Francois committed
88 89 90
Develop [@deriving zippers] to produce a type of zippers,
  and add an option for the environment to be a zipper
  that is extended at every recursive call. (Yann Régis-Gianas.)
POTTIER Francois committed
91 92 93 94
  Parameterize the type of zippers by the type of their root
  and allow the constructor Nil only when the root type and
  the current type coincide. (GADT.)
  So that we get n zipper types out of n source types.
POTTIER Francois committed
95

POTTIER Francois committed
96 97
Avoid generating beta-redexes.
  (fun (x, y) -> ...) z should be let (x, y) = z in ...
98
  See [visit_types].
POTTIER Francois committed
99

POTTIER Francois committed
100 101 102
Re-introduce hoisting of closure allocations of the form [self#visit_foo]?
  If so, share them when they have several occurrences.

POTTIER Francois committed
103
Think about generating analyze_ methods
POTTIER Francois committed
104
  which perform a fixed point computation (use Fix)
POTTIER Francois committed
105 106 107
  based only on the type structure
  so as to allow a static analysis of the type structure,
  which could be exploited to optimize runtime traversals.
POTTIER Francois committed
108
  One would have to lose precision at parameterized types, or expand them away.