caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Polymorphic Variants for big Ast?
@ 2012-10-04 23:15 bob zhang
  2012-10-05  3:19 ` Jacques Carette
  2012-10-05  7:51 ` Pierre-Alexandre Voye
  0 siblings, 2 replies; 5+ messages in thread
From: bob zhang @ 2012-10-04 23:15 UTC (permalink / raw)
  To: Caml List

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

Dear List,
   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?
Many thanks

-- 
Regards
-- Bob

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Polymorphic Variants for big Ast?
  2012-10-04 23:15 [Caml-list] Polymorphic Variants for big Ast? bob zhang
@ 2012-10-05  3:19 ` Jacques Carette
  2012-10-05  3:38   ` bob zhang
  2012-10-05  7:51 ` Pierre-Alexandre Voye
  1 sibling, 1 reply; 5+ messages in thread
From: Jacques Carette @ 2012-10-05  3:19 UTC (permalink / raw)
  To: bob zhang; +Cc: Caml List

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

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.

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.

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

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Polymorphic Variants for big Ast?
  2012-10-05  3:19 ` Jacques Carette
@ 2012-10-05  3:38   ` bob zhang
  2012-10-05 11:33     ` David Rajchenbach-Teller
  0 siblings, 1 reply; 5+ messages in thread
From: bob zhang @ 2012-10-05  3:38 UTC (permalink / raw)
  To: Jacques Carette; +Cc: Caml List

[-- 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 --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Polymorphic Variants for big Ast?
  2012-10-04 23:15 [Caml-list] Polymorphic Variants for big Ast? bob zhang
  2012-10-05  3:19 ` Jacques Carette
@ 2012-10-05  7:51 ` Pierre-Alexandre Voye
  1 sibling, 0 replies; 5+ messages in thread
From: Pierre-Alexandre Voye @ 2012-10-05  7:51 UTC (permalink / raw)
  To: bob zhang; +Cc: Caml List

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

You can take a look on Ocsigen project which implements a HTML5 AST.

2012/10/5 bob zhang <bobzhang1988@gmail.com>

> Dear List,
>    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?
> Many thanks
>
> --
> Regards
> -- Bob
>



-- 
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.org/users/montaigne

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [Caml-list] Polymorphic Variants for big Ast?
  2012-10-05  3:38   ` bob zhang
@ 2012-10-05 11:33     ` David Rajchenbach-Teller
  0 siblings, 0 replies; 5+ messages in thread
From: David Rajchenbach-Teller @ 2012-10-05 11:33 UTC (permalink / raw)
  To: bob zhang; +Cc: Jacques Carette, Caml List

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

For Opa, we used a variant on the technique. We had a rather complex Ast
that was progressively refined through a number of passes.

Each pass could remove or add cases, and we wanted to have type
guarantees that ast nodes did not escape their scope.

To do this, we used something along the lines of

type 'variant Expr =
   | Let of ...
   | ...
   | Variant of 'variant
and 'variant Foo =
   | ...


In which ['variant] was instantiated with a polymorphic variant. This
gave us considerable flexibility and generally avoided the problem of
over-complicated error messages.

You can find the full source code at
https://github.com/MLstate/opalang/blob/master/compiler/opalang/surfaceAst.ml
.

Cheers,
 David


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2012-10-05 11:33 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-04 23:15 [Caml-list] Polymorphic Variants for big Ast? bob zhang
2012-10-05  3:19 ` Jacques Carette
2012-10-05  3:38   ` bob zhang
2012-10-05 11:33     ` David Rajchenbach-Teller
2012-10-05  7:51 ` Pierre-Alexandre Voye

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).