Commit 22750666 authored by POTTIER Francois's avatar POTTIER Francois


parent 3d8100cc
......@@ -2,10 +2,22 @@
Allow & document @constructor for sum types and record types.
beware of capture: code in @build can see some private variables
Document @build for sum types and record types.
Careful not to mis-spell it.
Unify the [body] functions for sums and records?
Also hoist the [body] functions for tuples and opaque types, for clarity.
Document hexpr_polymorphic.
Add a pointer to
mapreduce can serve to collect locations
create a new opam package visitorshashcons?
......@@ -44,15 +56,6 @@ Maybe [fold] and [fold2] in VisitorsRuntime should just be aliases
Once we have that, can we deal with GADTs?
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.
In [fold],
the build_ methods could take not only the results of the recursive calls,
but also their arguments (for added expressive power).
......@@ -85,16 +88,6 @@ Avoid generating beta-redexes.
Re-introduce hoisting of closure allocations of the form [self#visit_foo]?
If so, share them when they have several occurrences.
[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.
Implement a way of deferring visitor generation.
(inserting user code between the type definition and the visitor class)
(or, more generally, generating a visitor for a pre-existing type)
Do something about ~path?
It seems connected to nested modules.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment