[Caml-list] ocamlc 4.03 -> 4.04: change in meaning of -i

[Caml-list] ocamlc 4.03 -> 4.04: change in meaning of -i

[Timothy Bourke]

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

I just noticed a change in the behaviour of ocamlc that adversely 
affects a tool I maintain.

In 4.03.0 (and earlier), the -i option only applies to the .ml files 
that follow it on the command line.

In 4.04.0 (and later), the -i option applies to all .ml files on the 
command line.

Is this change in behaviour intentional?

Tim.

Longer explanation
==================

Given two files.

  a.ml:
    let f x = x + 1

  b.ml:
    open A
    let g x = f x

1. In 4.03.0 (and earlier), typing either
     ocamlc a.ml -i b.ml
   or
     ocamlc -c a.ml; ocamlc a.ml -i b.ml

   prints
     val g : int -> int

   and generates
     a.cmi
     a.cmo

2. In 4.04.0 (and later), typing
     ocamlc a.ml -i b.ml

   prints
     val f : int -> int
     File "b.ml", line 1, characters 5-6:
     Error: Unbound module A    

   and does not generate anything.

3. In 4.04.0 (and later), typing
     ocamlc -c a.ml; ocamlc a.ml -i b.ml

   prints
     val f : int -> int
     val g : int -> int

   and generates
     a.cmi
     a.cmo


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

RE: [Caml-list] ocamlc 4.03 -> 4.04: change in meaning of -i

[David Allsopp]

Timothy Bourke wrote:
> Sent: 08 July 2017 15:08
> To: caml-list@inria.fr
> Subject: [Caml-list] ocamlc 4.03 -> 4.04: change in meaning of -i
> 
> I just noticed a change in the behaviour of ocamlc that adversely
> affects a tool I maintain.
> 
> In 4.03.0 (and earlier), the -i option only applies to the .ml files
> that follow it on the command line.
> 
> In 4.04.0 (and later), the -i option applies to all .ml files on the
> command line.
> 
> Is this change in behaviour intentional?

This behaviour is a consequence of GPR#464 (in particular https://github.com/ocaml/ocaml/commit/4dc3efe) and intentional.

Prior to 4.04.0, at the point of processing a.ml in `ocamlc a.ml -i b.ml` the compiler assumes it is linking (since that is the default operation) and so generates a.cmo and a.cmi. Once it sees the `-i` it discovers that it's supposed to be dumping interfaces and so prints the interface of b.ml - this works because by fluke it compiled a.ml previously. Prior to 4.04.0, if instead you had run `ocamlc -i a.ml b.ml` (with no a.cmi built) you would have got the same error and the same output.

PR#6475/GPR#464 took the decision that the command line arguments should be fully interpreted before doing anything, hence in 4.04.0+ `ocamlc a.ml -i b.ml` and `ocamlc -i a.ml b.ml` are the same command and interpreted as the latter (the change is marked as breaking as a result).

HTH,


David


> 
> Tim.
> 
> Longer explanation
> ==================
> 
> Given two files.
> 
>   a.ml:
>     let f x = x + 1
> 
>   b.ml:
>     open A
>     let g x = f x
> 
> 1. In 4.03.0 (and earlier), typing either
>      ocamlc a.ml -i b.ml
>    or
>      ocamlc -c a.ml; ocamlc a.ml -i b.ml
> 
>    prints
>      val g : int -> int
> 
>    and generates
>      a.cmi
>      a.cmo
> 
> 2. In 4.04.0 (and later), typing
>      ocamlc a.ml -i b.ml
> 
>    prints
>      val f : int -> int
>      File "b.ml", line 1, characters 5-6:
>      Error: Unbound module A
> 
>    and does not generate anything.
> 
> 3. In 4.04.0 (and later), typing
>      ocamlc -c a.ml; ocamlc a.ml -i b.ml
> 
>    prints
>      val f : int -> int
>      val g : int -> int
> 
>    and generates
>      a.cmi
>      a.cmo

Re: [Caml-list] ocamlc 4.03 -> 4.04: change in meaning of -i

[Timothy Bourke]

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

Thanks for your response.

* David Allsopp [2017-07-09 09:47 +0000]:
> Timothy Bourke wrote:
> > Is this change in behaviour intentional?
> 
> This behaviour is a consequence of GPR#464 (in particular https://github.com/ocaml/ocaml/commit/4dc3efe) and intentional.

That commit message is indeed quite clear. I got lost in the other 
ones that were more concerned with .c files.
 
> Prior to 4.04.0, at the point of processing a.ml in `ocamlc a.ml -i b.ml` the compiler assumes it is linking (since that is the default operation) and so generates a.cmo and a.cmi. Once it sees the `-i` it discovers that it's supposed to be dumping interfaces and so prints the interface of b.ml - this works because by fluke it compiled a.ml previously. Prior to 4.04.0, if instead you had run `ocamlc -i a.ml b.ml` (with no a.cmi built) you would have got the same error and the same output.

I wouldn't have said that it worked by fluke. This design seemed 
reasonable to me (since the order of files is already significant), 
though I admit that it's "trickier" than the new approach.
 
> PR#6475/GPR#464 took the decision that the command line arguments should be fully interpreted before doing anything, hence in 4.04.0+ `ocamlc a.ml -i b.ml` and `ocamlc -i a.ml b.ml` are the same command and interpreted as the latter (the change is marked as breaking as a result).

OK. Well, I will have to rethink my tool then.

To give a bit more background, the problem concerns the checklistings 
LaTeX package (https://www.ctan.org/pkg/checklistings) which allows 
for compiling code snippets extracted from LaTeX documents. For OCaml 
listings, it is normal to pass the -i option so that the types 
inferred for a code snippet can be displayed in a document. It is also 
normal for later code snippets to depend on earlier ones. The -i 
option, however, does not generate the .cmi file required to compile 
later snippets. My solution was thus to rely on the previous behaviour 
of ocamlc.

Would it be reasonable to have a means of both compiling and showing 
the inferred types? For instance, by passing both -c and -i?

Tim.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]