Re: [Caml-list] Polymorphic Variants for big Ast?

[bob zhang <bobzhang1988@gmail.com>]

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

Greetings,

On Thu, Oct 4, 2012 at 11:19 PM, Jacques Carette <carette@mcmaster.ca>wrote:

>  On 04/10/2012 7:15 PM, bob zhang wrote:
>
>    Has anyone have the experience using polymorphic variant for a big
> Ast?
>   The benefit I can think of is  open recursion, global namespace(not in a
> module). Did anyone give a try?
>
>
> I have -- mostly because I needed subtying, since the language I was
> modelling had a kind of subtyping that polymorphic variants could track
> 'for free'.
>
> It works.  But it can be a real pain too: depending on your use cases, you
> may need a fair amount of annotations (casts).  And if you make a mistake,
> the error messages are truly frightening, especially when you have an AST
> with 4 mutually recursive parts, totaling about 25 cases, and the mistake
> is 3 or 4 levels deep -- the error messages can go on for pages and pages.
> Buried in there will be the information you need to fix the mistake, but
> finding it can be extremely challenging.
>
> Thanks for your warning,  that's really helpful

> I would say: use it only if you really really need what polymorphic
> variants 'buy' you, else stay away.  In my original code, I have rewritten
> most of it to use normal variants (except for one case) and use explicit
> open recursion (i.e. extra type variable + tying the knot) to get the job
> done.  The error messages are sane now.
>
> I am considering change Camlp4 Ast node into  Polymorphic Variants(I know
it's hard, suppose I could make it) The problem with normal Algebraic Data
Type to me is that I have to use functors to abstract over types, and
functors are really intrusive, you need to write a large amount of
signatures everywhere.

To make things much worse, * the ADT depends on the qualified module
names *which
makes the bootstrapping system fragile. So I think polymorphic variant may
fit this area nicely.
   As you said, the error message is something I worried about. How about
performance issues?

> Note that I don't think the error messages were incorrect in any way (I am
> sure they were not).  It might have been possible to have made them
> friendlier / more precise, but I am not even sure of that.
>
> Jacques
>



-- 
Regards
-- Bob

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