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.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr 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 029D2BC68; Wed, 25 Oct 2006 18:35:35 +0200 (CEST) Received: from mail.corp.idt.net (mail.corp.idt.net [169.132.25.53]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id k9PGZXnZ029276; Wed, 25 Oct 2006 18:35:34 +0200 Received: from [169.132.9.113] (account saleyn HELO [169.132.9.113]) by mail.corp.idt.net (CommuniGate Pro SMTP 4.2.10) with ESMTP id 182010154; Wed, 25 Oct 2006 12:35:27 -0400 Message-ID: <453F924E.5020006@hq.idt.net> Date: Wed, 25 Oct 2006 12:35:26 -0400 From: Serge Aleynikov User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Nicolas Pouillard Cc: caml-list@inria.fr Subject: Re: [Caml-list] camlp4 scope issue References: <453F8464.3000808@hq.idt.net> <453FBE38.3030602@tepkom.ru> <453F8AF8.4090306@hq.idt.net> In-Reply-To: Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 453F9255.005 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; camlp:01 syntax:01 iterative:01 syntax:01 bug:01 expr:01 expr:01 notations:01 foo:01 semantics:01 ocaml:01 6.2:98 wrote:01 wrote:01 caml-list:01 Ugh! Thank you for clarifying this, as it was driving me insane in trying to figure out what the revised construct was *supposed to do* rather than what it *did*. Not sure if this is a proper place to ask, but would it be possible to document this feature? Frankly, in presence of the << value ...; >> construct, I don't see the benefit behind << let ... ; >> inside the << do { ... } >> clause other than causing confusion. Though I realize that people might have a different view of this... Regards, Serge -- Serge Aleynikov Routing R&D, IDT Telecom Tel: +1 (973) 438-3436 Fax: +1 (973) 438-1464 Nicolas Pouillard wrote: > On 10/25/06, Serge Aleynikov wrote: >> Perhaps I am misunderstanding the meaning of ";" in the revised syntax, >> however, the 6.2 chapter >> (http://caml.inria.fr/pub/docs/manual-camlp4/manual007.html) says that: >> >> do { e1; e2; e3; e4 } >> >> is an iterative sequence of expressions, whereas "let ... in" is >> reserved for local constructs. >> >> If so, wouldn't the scope of y in >> >> let y = 1 in do { a; b; c }; >> >> be different from: >> >> let y = 1 in a; b; c; >> >> Or else how to we indicate in the *revised syntax* the boundary of the >> "let ... in" scope? > > It's not a bug it's a feature :) > > But a not documented one. > > Inside a << do { ... } >> you can use << let var = expr1; expr2 >> > like << let var = expr1 in expr2 >>. > > The main goal is to facilitate imperative coding inside a << do {} >>: > > do { > let x = 42; > do_that_on x; > let y = x + 2; > play_with y; > } > > That's nice but undocumented :( > > Without such a syntax the regular one will make you nest do { ... } > notations. > > do { > foo 1; > let x = 43 in do { > bar x; > }; > (* x should be out of the scope *) > } > > Alas << let ... in >> and << let ... ; >> have the same semantics > inside a << do { ... } >> what I regret because << let ... in >> is > not local anymore. > > In plain OCaml it's different since << ; >> is a binary operator so > you must see << let a = () in a; a >> like << let a = () in (a; a) >>. > > Hope this helps... > > Best regards, >