From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 68C3C7EDD8 for ; Fri, 5 Oct 2012 05:21:24 +0200 (CEST) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=pra; client-ip=130.113.128.28; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of carette@mcmaster.ca) identity=mailfrom; client-ip=130.113.128.28; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="carette@mcmaster.ca"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@pinegw02.uts.mcmaster.ca) identity=helo; client-ip=130.113.128.28; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="carette@mcmaster.ca"; x-sender="postmaster@pinegw02.uts.mcmaster.ca"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlABAL1RblCCcYAcnGdsb2JhbABFgkuJI69sg2cBAQEBAQgLCQkUJ4IgAQEFeAEQCwQUCRYPCQMCAQIBRQYNAQcBAYgBuEuLPoYJA5tLjVM X-IronPort-AV: E=Sophos;i="4.80,538,1344204000"; d="scan'208,217";a="157959404" Received: from pinegw02.uts.mcmaster.ca ([130.113.128.28]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Oct 2012 05:21:22 +0200 Received: from Gorash7.UTS.McMaster.CA (Gorash7.UTS.McMaster.CA [130.113.196.61]) by pinegw02.uts.mcmaster.ca (8.14.4/8.14.4) with ESMTP id q953JcfB025526; Thu, 4 Oct 2012 23:19:38 -0400 Received: from cgpsrv2.cis.mcmaster.ca (univmail.CIS.McMaster.CA [130.113.64.46]) by Gorash7.UTS.McMaster.CA (8.13.7/8.13.7) with ESMTP id q953JTYn020033; Thu, 4 Oct 2012 23:19:29 -0400 Received: from [99.235.253.243] (account carette@univmail.cis.mcmaster.ca HELO [192.168.2.102]) by cgpsrv2.cis.mcmaster.ca (CommuniGate Pro SMTP 5.2.12) with ESMTPSA id 426404830; Thu, 04 Oct 2012 23:19:29 -0400 Message-ID: <506E51C6.6070607@mcmaster.ca> Date: Thu, 04 Oct 2012 23:19:34 -0400 From: Jacques Carette Organization: McMaster University User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: bob zhang CC: Caml List References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000506030300000201080902" X-PMX-Version-Mac: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.10.5.30615 X-PerlMx-Spam: Gauge=IIIIIIII, Probability=8%, Report=' HTML_NO_HTTP 0.1, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_4000_4999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, NO_URI_FOUND 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __SANE_MSGID 0, __TAG_EXISTS_HTML 0, __USER_AGENT 0' X-Spam-Flag: NO Subject: Re: [Caml-list] Polymorphic Variants for big Ast? This is a multi-part message in MIME format. --------------000506030300000201080902 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------000506030300000201080902 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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
--------------000506030300000201080902--