Re: [Caml-list] Unboxing: how to do it best?

[Eray Ozkural <examachine@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2619 bytes --]

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,

-- 
Eray Ozkural, PhD candidate.  Comp. Sci. Dept., Bilkent University, Ankara
http://groups.yahoo.com/group/ai-philosophy
http://myspace.com/arizanesil http://myspace.com/malfunct

[-- Attachment #2: Type: text/html, Size: 3787 bytes --]