From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.8 required=5.0 tests=AWL,DATE_IN_FUTURE_03_06, SPF_FAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 8B004BC69 for ; Wed, 24 Oct 2007 23:33:29 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FADZWH0dSs6cFnWdsb2JhbAA6gSCNAQIBAQsPCIE/ X-IronPort-AV: E=Sophos;i="4.21,326,1188770400"; d="scan'208";a="5067605" Received: from mail-ilca.tepkom.ru (HELO mail.tepkom.ru) ([82.179.167.5]) by mail3-smtp-sop.national.inria.fr with ESMTP; 24 Oct 2007 23:33:28 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.tepkom.ru (Postfix) with ESMTP id 2EA71580C71C; Thu, 25 Oct 2007 01:28:26 +0400 (MSD) X-Virus-Scanned: by amavisd-new-2.4.2 (20060627) (Debian) at tepkom.ru with clamav Received: from mail.tepkom.ru ([127.0.0.1]) by localhost (mail.tepkom.ru [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YNeWlhedyCQ; Thu, 25 Oct 2007 01:28:26 +0400 (MSD) Received: from [192.168.1.7] (ppp91-122-104-125.pppoe.avangard-dsl.ru [91.122.104.125]) by mail.tepkom.ru (Postfix) with ESMTP id 82822580C704; Thu, 25 Oct 2007 01:28:25 +0400 (MSD) Message-ID: <471FF29B.8010409@tepkom.ru> Date: Thu, 25 Oct 2007 01:34:19 +0000 From: Dmitri Boulytchev User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050905) X-Accept-Language: ru-ru, ru MIME-Version: 1.0 To: Jon Harrop Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] type abbreviation is cyclic References: <344522.90449.qm@web82102.mail.mud.yahoo.com> <471F847C.1050609@janestcapital.com> <9d3ec8300710241109ie0d1350v7f0201e635defc4d@mail.gmail.com> <200710242140.21143.jon@ffconsultancy.com> In-Reply-To: <200710242140.21143.jon@ffconsultancy.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam: no; 0.00; abbreviation:01 intensively:01 -rectypes:01 const:01 const:01 -rectypes:01 recursive:01 afaik:01 inference:01 ocaml:01 compiler:01 segfault:01 ocaml:01 indirection:01 polymorphic:01 We intensively use -rectypes option. The "pattern" we've found to be handy is like that: type 'a p = | Add of 'a * ' a | Sub of 'a * 'a | Neg of 'a | Const of int and t = t p (* we need rectypes here *) let map f = function | Add (x, y) -> Add (f x, f y) | Sub (x, y) -> Sub (f x, f y) | Neg x -> Neg (f x) | Const x -> Const x let rec toString x = match map toString x with | Add (a, b) -> a ^ " + " ^ b | Sub (a, b) -> a ^ " - " ^ b | Neg a -> "-" ^ a | Const x -> string_of_int x let rec eval x = match map eval x with | Add (a, b) -> a + b | Sub (a, b) -> a - b | Neg a -> -a | Const x -> x etc. Although this may look useless at a first glance we have some profit since we bother about correct applications of function only when writing map. In this very example it may not be obvious but when the number of "phantom" parameters grows (type ('expr, 'stmt, 'process, 'handler) something = ...) the code becomes much more transparent. We use -rectypes together with recursive modules in a rather large project (>30 000 loc) and all works well. Best regards, Dmitry Boulytchev, St.Petersburg State University. >On Wednesday 24 October 2007 19:09:13 Till Varoquaux wrote: > > >>... >>AFAIK -rectypes doesn't break any of the programs working before but >>if you attend to use it you will probably run in problems with type >>inference (not polymorphic enough). I would recommend steering clear >>of it for anything else than toy programs. >> >> > >You used to be able to get the OCaml compiler to segfault by using -rectypes >inconsistently while compiling. I believe that -rectypes can be useful. For >example, the OCaml implementations of the ray tracer benchmark use it to good >effect to implement the scene tree without an extra level of indirection. I >have never bothered turning it on for any significant projects or during >development though, so I can't say with any certainty whether or not it has a >practical impact on error messages. > > >