camlp4 scope issue

camlp4 scope issue

[Serge Aleynikov]

Hi,

In the test program below in my understanding the 'y' variable should be
out of scope in the printf statement, but apparently it's not.  The
compiler version is 3.09.3.

$ cat tst.ml
value f z = z + 1;

let x = 1 in do {
   let y = f x in ();
   Printf.printf "y should be out of scope, but it's not: y = %d\n" y
};

$ ocamlc -o tst -pp camlp4r tst.ml
$ ./tst
y should be out of scope, but it's not: y = 2


Any idea why?

-- 
Serge Aleynikov
Routing R&D, IDT Telecom
Tel: +1 (973) 438-3436
Fax: +1 (973) 438-1464

Re: [Caml-list] camlp4 scope issue

[Dmitri Boulytchev]

    That's ok - semicolon does not restict the scope since it plays role
of a binary operation, not a statement delimiter. So in your example

    (); Printf.printf "y should be out of scope, but it's not: y = %d\n" y
   
    is a while scope for let-binding.

    Best regards,
    Dmitri Boulytchev,
    St.Petersburg State University.


> Hi,
>
> In the test program below in my understanding the 'y' variable should be
> out of scope in the printf statement, but apparently it's not.  The
> compiler version is 3.09.3.
>
> $ cat tst.ml
> value f z = z + 1;
>
> let x = 1 in do {
>   let y = f x in ();
>   Printf.printf "y should be out of scope, but it's not: y = %d\n" y
> };
>
> $ ocamlc -o tst -pp camlp4r tst.ml
> $ ./tst
> y should be out of scope, but it's not: y = 2
>
>
> Any idea why?
>

Re: [Caml-list] camlp4 scope issue

[Serge Aleynikov]

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?

Serge

Dmitri Boulytchev wrote:
>     That's ok - semicolon does not restict the scope since it plays role
> of a binary operation, not a statement delimiter. So in your example
> 
>     (); Printf.printf "y should be out of scope, but it's not: y = %d\n" y
>    
>     is a while scope for let-binding.
> 
>     Best regards,
>     Dmitri Boulytchev,
>     St.Petersburg State University.
> 
> 
>> Hi,
>>
>> In the test program below in my understanding the 'y' variable should be
>> out of scope in the printf statement, but apparently it's not.  The
>> compiler version is 3.09.3.
>>
>> $ cat tst.ml
>> value f z = z + 1;
>>
>> let x = 1 in do {
>>   let y = f x in ();
>>   Printf.printf "y should be out of scope, but it's not: y = %d\n" y
>> };
>>
>> $ ocamlc -o tst -pp camlp4r tst.ml
>> $ ./tst
>> y should be out of scope, but it's not: y = 2
>>
>>
>> Any idea why?
>>
> 
> 


-- 
Serge Aleynikov
Routing R&D, IDT Telecom
Tel: +1 (973) 438-3436
Fax: +1 (973) 438-1464

Re: [Caml-list] camlp4 scope issue

[Nicolas Pouillard]

On 10/25/06, Serge Aleynikov <serge@hq.idt.net> 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,

-- 
Nicolas Pouillard

Re: [Caml-list] camlp4 scope issue

[Serge Aleynikov]

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 <serge@hq.idt.net> 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,
> 

Re: [Caml-list] camlp4 scope issue

[Dmitri Boulytchev]

    The revised syntax description you are referring to is quite
informal so I'd rather trust the compiler :)
    You may restict the scope of a binding in a way its usual done in
other languages: by

    do {let y = 1 in a}; b; c;

    in revised or by

    (let y = 1 in a); b; c;

    in  standard syntax.

    BR,
    DB.

> 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?
>
> Serge
>
> Dmitri Boulytchev wrote:
>
>>     That's ok - semicolon does not restict the scope since it plays role
>> of a binary operation, not a statement delimiter. So in your example
>>
>>     (); Printf.printf "y should be out of scope, but it's not: y =
>> %d\n" y
>>        is a while scope for let-binding.
>>
>>     Best regards,
>>     Dmitri Boulytchev,
>>     St.Petersburg State University.
>>
>>
>>> Hi,
>>>
>>> In the test program below in my understanding the 'y' variable
>>> should be
>>> out of scope in the printf statement, but apparently it's not.  The
>>> compiler version is 3.09.3.
>>>
>>> $ cat tst.ml
>>> value f z = z + 1;
>>>
>>> let x = 1 in do {
>>>   let y = f x in ();
>>>   Printf.printf "y should be out of scope, but it's not: y = %d\n" y
>>> };
>>>
>>> $ ocamlc -o tst -pp camlp4r tst.ml
>>> $ ./tst
>>> y should be out of scope, but it's not: y = 2
>>>
>>>
>>> Any idea why?
>>>
>>
>>
>
>

Re: [Caml-list] camlp4 scope issue

[Mike Lin]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

I would like to take this opportunity to plug ocaml+twt. Relieve your
suffering...
http://people.csail.mit.edu/mikelin/ocaml+twt/

On 10/25/06, Dmitri Boulytchev <db@tepkom.ru> wrote:
>
>     The revised syntax description you are referring to is quite
> informal so I'd rather trust the compiler :)
>     You may restict the scope of a binding in a way its usual done in
> other languages: by
>
>     do {let y = 1 in a}; b; c;
>
>     in revised or by
>
>     (let y = 1 in a); b; c;
>
>     in  standard syntax.
>
>     BR,
>     DB.
>
> > 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?
> >
> > Serge
> >
> > Dmitri Boulytchev wrote:
> >
> >>     That's ok - semicolon does not restict the scope since it plays
> role
> >> of a binary operation, not a statement delimiter. So in your example
> >>
> >>     (); Printf.printf "y should be out of scope, but it's not: y =
> >> %d\n" y
> >>        is a while scope for let-binding.
> >>
> >>     Best regards,
> >>     Dmitri Boulytchev,
> >>     St.Petersburg State University.
> >>
> >>
> >>> Hi,
> >>>
> >>> In the test program below in my understanding the 'y' variable
> >>> should be
> >>> out of scope in the printf statement, but apparently it's not.  The
> >>> compiler version is 3.09.3.
> >>>
> >>> $ cat tst.ml
> >>> value f z = z + 1;
> >>>
> >>> let x = 1 in do {
> >>>   let y = f x in ();
> >>>   Printf.printf "y should be out of scope, but it's not: y = %d\n" y
> >>> };
> >>>
> >>> $ ocamlc -o tst -pp camlp4r tst.ml
> >>> $ ./tst
> >>> y should be out of scope, but it's not: y = 2
> >>>
> >>>
> >>> Any idea why?
> >>>
> >>
> >>
> >
> >
>
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 3953 bytes --]