From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 4A3AFBC48 for ; Mon, 18 Apr 2005 22:20:04 +0200 (CEST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3IKK3Ph014677 for ; Mon, 18 Apr 2005 22:20:03 +0200 Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA22118 for ; Mon, 18 Apr 2005 22:20:03 +0200 (MET DST) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id j3IKK25M014670 for ; Mon, 18 Apr 2005 22:20:02 +0200 Received: from frontend3.messagingengine.com (frontend3.internal [10.202.2.152]) by frontend1.messagingengine.com (Postfix) with ESMTP id 20126C77094; Mon, 18 Apr 2005 16:20:00 -0400 (EDT) X-Sasl-enc: Vq57y+QX3Pj7SY+DIiBhbjieOE/NG54HA+kJCce+ek3DsA2T/GvvhdxDpp/N 1113855600 Received: from [172.16.112.115] (burnham.ljcrf.edu [192.231.106.2]) by frontend3.messagingengine.com (Postfix) with ESMTP id 2B64884; Mon, 18 Apr 2005 16:19:59 -0400 (EDT) Date: Mon, 18 Apr 2005 13:19:43 -0700 (PDT) From: Martin Jambon X-X-Sender: martin@localhost To: Markus Mottl Cc: OCaml Subject: Re: [Caml-list] Camlp4: extending syntax of record definitions In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Miltered: at concorde with ID 42641673.001 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at concorde with ID 42641672.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 syntax:01 markus:01 mottl:01 annotations:01 foo:01 foo:01 grammar:01 grammars:01 syntax:01 expr:01 expr:01 copy-paste:01 submodule:01 replacing:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Mon, 18 Apr 2005, Markus Mottl wrote: > Hi, > > I'd like to add annotations to record definitions that allow the automatic > generation of validation functions. Here is a simplified example: > > let float_range lower upper x = lower <= x && x <= upper > let int_positive x = x >= 0 > > type some_record = > { > foo : float validate float_range 1.0 2.0; > bar : int validate int_positive; > } > > The "validate" keyword would essentially allow attaching a function to > each record field, which is called to assert some properties. E.g. the > following function would be automatically generated from the above > type definition: > > let validate__some_record r = > float_range 1.0 2.0 r.foo && > int_positive r.bar > > Not being a camlp4-expert my problem is that I'm not sure how to go about > extending the grammar. What would be the most convenient starting point? > Extending existing grammars, starting one from scratch, etc.? Some rough > outline on what to do would be nice. Thanks in advance! My experience in that field tells me that the more you try to extend existing syntaxic constructs, the more difficult it is. You have to look at pa_o.ml from the Camlp4 distribution first, and see if the rule corresponding to record definitions is public (belongs to a "GLOBAL" entry) or not. If the entry that contains this rule is public, then you can delete the rule and rewrite it, and everything is fine. Otherwise, you have to improvise. Which is the case here: the type_kind entry is not visible from outside. One reasonable solution, in general, if you have a limited time or budget, is to extend str_item (items of a module implementation) with a whole new syntax. Something like: record ('a, 'b) name = { label1 : type1 validate expr1; label2 : type2 validate expr2; ... } For this, you can copy-paste the code for the label_declaration entry and modify it to suit your needs (you will have specify an appropriate priority "LEVEL" for the expressions if you want the ";" to be considered as the end the label_declaration) Besides the type definition, you have to make a way to create fresh records (expr). Here the easiest way is probably to create a labeled function just after the type definition and use that function. However this doesn't prevent the user from creating the record using the usual { ... } syntax, but you can achieve such an effect with a submodule, using "private" record definitions as you can imagine. (replacing the { ... } notation for record exprs would be too difficult because of the "open" directives) You can look at this example (uncommented), which is very similar: http://martin.jambon.free.fr/extend-ocaml-syntax.html#types Martin -- Martin Jambon, PhD http://martin.jambon.free.fr