TODO 4.14 KB
Newer Older
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
1
------------------------------------------------------------------------------
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
2

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
3
TODO (REALLY)
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
4

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
5
------------------------------------------------------------------------------
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
6

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
7
TODO (PERHAPS)
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
8

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
9 10 11 12 13
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's avatar
TODO.  
POTTIER Francois committed
14 15 16
In fully [polymorphic] mode, perhaps one could allow [@@deriving visitors]
  to be used in an .mli file, producing class types.

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
17 18 19 20 21
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's avatar
TODO.  
POTTIER Francois committed
22 23
Ideally, a visitor method should be parameterized with visit_'a
  only if 'a appears in the type of some component.
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
24 25 26 27 28 29 30
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's avatar
TODO.  
POTTIER Francois committed
31 32 33 34
Think about enabling [polymorphic] and [fold] together.
That would require letting the user specify the result type
  associated with each type constructor.

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
35 36 37
Implement and document endoreduce?
  Share code by using "Map endo" internally where endo : bool.

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
38 39
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's avatar
TODO.  
POTTIER Francois committed
40

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
41 42 43 44
Once we have that, can we deal with GADTs?

Add an annotation to rename a visitor method. (Reuben Rowe.)

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
45 46 47 48 49 50 51
Ancestors should be not just class names,
  but class expressions (e.g. a class name applied to some arguments).
Then, one should also have the ability of parameterizing
  the generated visitor with value arguments.
This could be used to define visit_hash_consed once and for all,
  in a clean way, as a base class that could be inherited,
  taking the memoization table as an argument.
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
52
  See hexpr_polymorphic.ml.
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
53

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
54 55 56 57
In [fold],
  the build_ methods could take not only the results of the recursive calls,
  but also their arguments (for added expressive power).

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
58 59
Develop a real test suite, with expected output.
  Check for left-to-right traversal order.
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
60 61 62
  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's avatar
TODO.  
POTTIER Francois committed
63 64 65 66

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

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
67
Include an option [except t] to omit the definition of visitor methods for the type [t].
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
68 69 70
  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's avatar
TODO.  
POTTIER Francois committed
71
  e.g. could generate a [map] visitor where one type (in a family) is rewritten to something completely different
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
72

73 74
Detect and reject existential types and GADTs.

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
75 76 77 78
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's avatar
TODO.  
POTTIER Francois committed
79 80
Avoid generating beta-redexes.
  (fun (x, y) -> ...) z should be let (x, y) = z in ...
81
  See [visit_types].
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
82

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
83 84 85
Re-introduce hoisting of closure allocations of the form [self#visit_foo]?
  If so, share them when they have several occurrences.

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
86 87 88 89 90 91
[variety] could be a list.
  But then, one would need to replace <variety> with variety in
    [ancestors] and in [name] (if present).
  Somewhat tricky, as we would need to produce not one settings
    record, but several of them.

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
92 93
Implement a way of deferring visitor generation.
  (inserting user code between the type definition and the visitor class)
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
94
  (or, more generally, generating a visitor for a pre-existing type)
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
95

POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
96 97
Do something about ~path?
  It seems connected to nested modules.
POTTIER Francois's avatar
TODO.  
POTTIER Francois committed
98 99 100 101 102 103

Think about generating analyze_ methods
  which perform a bottom-up computation (at most once; memoized)
  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.