On Sat, Jan 15, 2011 at 2:38 PM, Guillaume Yziquel
<guillaume.yziquel@citycable.ch> wrote:
If you do not care about having the annotation available at runtime
instead of being something static (after all, MPI datatypes are
available at runtime), you could go for encapsulating type information
in first class modules representing datatypes.
Then, for instance, given a datatype, you may wish to construct the
datatype of an array of such types. Such a function needs to know
details about the way OCaml boxes or unboxes different kinds of arrays,
and it can be done (though rather awkwardly in my case).
So first-class modules encapsulating datatype information seems to me a
worthwile option and the only solution I could come with to mimic what
would be done in C++ with traits.
Hi Guillaume,
That's a good idea.
Theoretically a functor transforms programs. Radical program rewriting would be just the thing to do with a functor, but I'd rather have it in the compiler.
After all program-transformation is what an optimization pass is essentially. There is absolutely nothing wrong with doing it in a high-level way, as long as it doesn't introduce runtime overhead.
Has anyone designed a cool compiler like that? :)
As for 'annotating type definitions', where would you put the line as to
what 'annotating' means? Using type-conv-like Camlp4 processing?
I haven't thought much about the implementation, except verifying that it's just an extension of the present kinds of unboxing in the runtime.
What I would like is something like (thinking of a typical simulation datatype):
type cvector4 = ][ (complex * complex * complex * complex)
where ][ would be a "type operator" enforcing a flattened representation of the type expression it is applied to. It would just change the layout so it would be equivalent to the same type without the unboxing op.
Preprocessing might be one way to implement it, but i don't think it's an easy implementation at any rate.
Just a small idea that I couldn't let slip from my mind.
But as to avoiding pointer chasing, I think there's no workaround to the
way OCaml handles memory. The only solution I can come of is the
obvious: use arrays or bigarrays and smart datatypes.
Smart datatypes is OK, I think you could substitute many datatypes with such a thing, but I'm not sure how easy that would be to do in real-world programming?
Best,