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=0.8 required=5.0 tests=AWL,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 61E78BBAF for ; Tue, 6 Oct 2009 17:24:10 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8DACv+ykpQRFuwWWdsb2JhbACabgEWFbgchCoEgVM X-IronPort-AV: E=Sophos;i="4.44,513,1249250400"; d="scan'208";a="35785152" Received: from furbychan.cocan.org ([80.68.91.176]) by mail3-smtp-sop.national.inria.fr with ESMTP; 06 Oct 2009 17:24:10 +0200 Received: from rich by furbychan.cocan.org with local (Exim 4.63) (envelope-from ) id 1MvBtU-0005CN-Mo; Tue, 06 Oct 2009 16:24:04 +0100 Date: Tue, 6 Oct 2009 16:24:04 +0100 To: David Allsopp Cc: 'Jon Harrop' , caml-list@yquem.inria.fr Subject: Re: [Caml-list] Constructors are not functions Message-ID: <20091006152404.GA19326@annexia.org> References: <4ACB319A.1080608@wanadoo.fr> <003901ca4682$d47f8460$7d7e8d20$@metastack.com> <200910061415.48065.jon@ffconsultancy.com> <005501ca468d$dc9b51a0$95d1f4e0$@metastack.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005501ca468d$dc9b51a0$95d1f4e0$@metastack.com> User-Agent: Mutt/1.5.13 (2006-08-11) From: Richard Jones X-Spam: no; 0.00; constructors:01 0100,:01 camlp:01 cmi:01 cmi:01 camlp:01 ocaml:01 2009:98 devil:98 wrote:01 caml-list:01 functions:01 int:01 int:01 defined:02 On Tue, Oct 06, 2009 at 03:04:02PM +0100, David Allsopp wrote: > That's not the case at all - there'd be no reason not to interpret > [bar] as [fun x y -> Bar(x, y)] for [Bar of int * int]. What would be > hairy in camlp4 would be having to read .cmi files to deal with types > defined outside your source file, but that's still not impossible... The devil is in the details. I had a look at this, and because you don't have access to the command line (eg. -I parameters) you can't easily find the *.cmi files you need. That is assuming it was easy to parse the command line (hard to do it reliably) or that you could look inside *.cmi files (the format is undocumented and release-specific). It would be so nice to have a macro tool which was aware of types, but that tool isn't camlp4. There are probably theoretical problems with this, but having a "give_me_the_type_of (ocaml_subexpression)" function would be awesome indeed. Rich. -- Richard Jones Red Hat