MantisBT - Issues

0006016: non-recursive type declarations

Mon, 20 May 2013 09:17:43 +0200

All type declarations are by default recursive. This is a problem when one wants to alias a type in a sub-module. The classic solution is to create a "proxy" type:

type t
module M = struct
type tmp = t
type t = tmp
end

At Jane Street we have been using a camlp4 extension to do that automatically when a type is marked with the keyword "nonrec":

type t
module M = struct
type nonrec t = t
end

We believe it could be useful to everybody and it would be better to have it into the language proper, for instance to avoid polluting signatures with useless types everywhere.

0006017: A new format implementation based on GADTs

Sun, 19 May 2013 17:21:15 +0200

I wrote a new implementation of formats unsing GADTs.

It contains modifications of Printf, Format and Scanf standard library
modules, and OCaml typer adaptations (principally in typing/typecore.ml).

In this new implementation, formats are compiled into GADTs trees by
the compiler and are "evaluated" by the printing and scanning functions.
The main advantages are :
* No longer use of Obj.magic in printf.ml, scanf.ml and format.ml.
* Better performances.
* Stronger static verifications of format validity (flag compatibilities, ...).
* Factorisation of format parsing in a single code (for all the stdlib
and the OCaml compiler!) to ensure compatibility.

This new version is "mostly compatible" with the old-one. Differencies are :
* Some inconsistent formats are now statically rejected, like
"%1.1s", "%#s", "%0c" (I had to slightly adapt the testsuite,
principally to comment absud tests which no longer compile, so, obviously,
I did not remove any test which still compile).
* Some bug fixes :
* The semantic of (printf "%{...%}") (from comments of the testsuite).
* The semantic of (scanf "%[^...]@X").
* The '@%' escape syntax, like in (Format.printf "@%d%s" 42 "hello").
* The managment of nested "%{...%}" and "%(...%)".
* Buffer overflows dues to too big padding (or precision).
* ...
* To obtain compatibility of Printf and Format formats, some '@' usages
with an "invalid Format-like syntax" but a "valid Printf-like syntax"
are now accepted by Format printing functions and literally printed.
It is a small disadvantage because it is slightly less convenient to
learn Format "formatting info" syntax by practice, sorry.

Since the OCaml standard library and the OCaml compilers use formats, the
bootstrap is a bit complicated.

I attach two patches (ocaml-4.00.1_new-formats_patch-{1,2}.diff) and
instructions to apply them into "howto-apply-new-formats-patches.txt".
This .txt file can be used (with a slight adaptation from your config.)
as an installation shell-script.

Please do not hesitate to send me any comments or questions about this code.

Benoît Vaugon.

0006013: duplicate locations cause 'unused warnings' to be lost

Fri, 17 May 2013 18:40:53 +0200

The typer considers that either all the identifiers with a given name at a given location are used, or none or them are used.

One consequence is that warnings may not be given for the code generated by camlp4 extensions because the positions are usually duplicated. For instance if you write:

type t = [ `a | `A ] with variants

the generated code will contain

let fold ~a:a_fun ~a:a_fun ... = ... use a_fun twice ...

But no warning will be given. This is a regression compared to 3.12.

0006012: object-like notation for module functions

Fri, 17 May 2013 18:36:29 +0200

I have been recently translating a lot of code from C++ to OCaml, but without using OCaml objects (for my purpose, they trigger errors that are hardly understandable by beginners...). I usually end up translating a lot of calls of the form:

self.meth(args)

to

ClassModule.meth self args

While it is easy to do it using replace-regexp, I was wondering if it would not be worth adding a simple syntax for that, that could also be used in a more general context to reduce the size of code to look like object-oriented code without using objects. The idea is that a common idiom in OCaml is to put all the functions working on a specific type in a module, and thus, if we can associate syntactically an identifier with such a module, we can use some object-oriented notation to access all these functions for this identifier (here, I will use "->" for that).

In the above example, when "self" would be introduced in the context, it would be associated with ClassModule (like a type annotation):

let f (self -> ClassModule) =
...
self->meth1 args;
self->meth2 args;
self->meth3 args;
...

With arrays:

let list_plus_length ( l -> List ) =
let len = l->length in
l-->map (fun i -> i + len) (* --> put "l" as the second argument of List.map *)

Note that it is not purely syntactic, it must be done with the knowledge of scopes, i.e. during typing. An extension would be to associate modules with types, so that type knowledge would trigger the correct use of functions :

type string -> String

let len (s : string) = s->length

Another advantage of such a notation would be that editors could use their knowledge of the module associated with the identifier to propose completions within that module.

Anybody else interested in having such a notation ?

0006015: Negative integer and float literals

Fri, 17 May 2013 18:29:11 +0200

I never understood this behaviour:

# sin -3.14;;
Error: This expression has type float -> float
but an expression was expected of type int

# pred -1;;
Error: This expression has type int -> int
but an expression was expected of type int

If you follow the grammar production of the docs from expr [1] to integer or float literals the above programs should be interpreted correctly. So what is wrong the lexer [4,5] or the docs ?

Either one should be fixed (and I'd prefer the lexer to be fixed).

[1] http://caml.inria.fr/pub/docs/manual-ocaml/expr.html#expr [^]
[2] http://caml.inria.fr/pub/docs/manual-ocaml/lex.html#float-literal [^]
[3] http://caml.inria.fr/pub/docs/manual-ocaml/lex.html#integer-literal [^]
[4] https://github.com/ocaml/ocaml/blob/trunk/parsing/lexer.mll#L246 [^]
[5] https://github.com/ocaml/ocaml/blob/trunk/parsing/lexer.mll#L248 [^]

0006000: Warning 40 ("Constructor or label name out of scope") should be an error

Fri, 17 May 2013 16:07:54 +0200

We have had record disambiguation on trunk now for a few months,
and I think that it would be wise to look again at the issue of
out of scope labels and constructors before the next major
release.

The issue is around the new ability to use a constructor or label
even though that constructor or label is not in scope, as long as
the type information is available.

For example, the following is allowed:

module M = struct
type foo = Foo
end

let x: M.foo = Foo

Note that previously this would be rejected, forcing the user to
write:

let x = M.Foo

Currently, using this feature produces a warning (40 "Constructor
or label name used out of scope"), however I think that it should
be upgraded to a full error.

This was discussed in 0005759, however more issues have emerged
since that discussion, and I think now is a good time to
re-evaluate this descision.

My arguments against allowing out of scope labels and
constructors are as follows:

- It allows references to constructors to be used in files that
contain no reference to the file defining those
constructors. For example, I have already come across the
following code in the wild:

(* types.ml *)
...
module Project = struct
...
type project = {
project_id: string;
...
}
...
end
...

(* data.ml *)
...
open Types
...
module Projects = struct
open Project
module Platform = struct

let project =
{ project_id="platform";
...
}
...
end
...
let all = [ Platform.project; ... ]
...
end

(* gantt.ml *)
...
open Data
...
List.map Projects.all
~f:(fun proj -> ... proj.project_id ...)
...

Note that gantt.ml uses project_id but contains no reference to
types.ml where that label is defined. When a bug occurred, it
was non-trivial to fix due to the difficulty of finding the
appropriate definition of project_id. This bug caused a lot of
confusion among less experienced OCaml programmers, and I think
that it is a very bad idea to allow it.

- It only works "in the presence of type information". This is an
unspecifed criteria that most users will probably find
confusing.

- It doesn't work with GADTs. If the constructor in question is
declared using GADT syntax then it cannot be used out of scope.

- It can't work with exceptions.

- It won't work with "open types" (0005584) or "pattern synonyms"
which may be added to the language in future.

- It will confuse users by adding a small element of structural
typing to an otherwise nominative system. I think that most
users picture variant constructors as named values, and all
named values in OCaml obey the same scoping rules. To suddenly
allow these values to be used as if they were not named values,
but structural values (like the methods in an object) will
confuse people.

In return for these issues, all that we gain is the ability to
refer to out of scope constructors and labels without using a
module name, but only under certain difficult to define
conditions.

Last time that this issue was discussed, it only appeared to be
discussed by 4 people. I think perhaps it would be a good idea
to get wider feedback before including a potentially risky
feature like this in a release.

It is also worth pointing out that it would be easier to add this
feature in the future than to remove it later if it causes
problems.

0005980: Maybe a new warning for M.() notation ?

Fri, 17 May 2013 14:55:01 +0200

While generally useful I think that the M.() notation may sometimes lead to subtle bugs when used as an expression.

Suppose I have M with this signature:

module M : sig
type t
val id : t
val ( + ) : t -> t -> t
...
end

And I code this function:

let f () =
let (id : t) = ... in
let (c : t) = ... in
M.(id + c)

I would like a warning that tells me that in M.(id + c), id is overriding a local variable. Note that a few cases are already covered by current warnings/errors.

1) If the local id not used elsewhere in f you will have (an initially puzzling) unused variable warning -- however that warning doesn't cover pattern matching variables.

2) If M.id was of another type you'd get an (aswell puzzling) type mismatch error.

I think that failing to have such a warning by default somehow renders all M.(e), where e binds local variables quite brittle and suspicious.

Thanks,

Daniel

0005982: caml_leave_blocking section and errno corruption

Tue, 14 May 2013 18:04:35 +0200

This is a widespread idiom for writing C stubs:

enter_blocking_section();
retcode = select(maxfd + 1, &read, &write, &except, tvp);
leave_blocking_section();
if (retcode == -1) uerror("select", Nothing);

Here [uerror] uses the global variable [errno]. The problem is that [leave_blocking_section] can run arbitrary code and so modify [errno]. It can run signal handlers for instance. Attached is an example of program where the call to select is expected to fail with EINTR but instead fails with EROFS.

Obviously bindings should be written this way:

enter_blocking_section();
retcode = select(maxfd + 1, &read, &write, &except, tvp);
saved_errno = errno;
leave_blocking_section();
if (retcode == -1) unix_error(saved_errno, "select", Nothing);

But since this is very common I propose that [leave_blocking_section] saves and restores [errno].

0006014: Existentials not allowed with 'let and'

Tue, 14 May 2013 15:20:44 +0200

Given

type t = T : 'a -> t

the following is accepted:

let T x = T 3 in ()

but a slight variant using 'let and' (or 'let rec and') is rejected:

let T x = T 3 and () = () in ()

with the message:

Error: Unexpected existential

0005874: Improve error message for polymorphic variant

Fri, 10 May 2013 16:50:12 +0200

Polymorphic variant is really a nice feature, but it's not widely used due to a not very instructive error message (I guess). In most cases, some errors are caused by a typo(the variant name typed wrong, or the arity lost), I think it may not be too hard to give some suggestions instead of a very large error string which may scared the users
Thanks!

0005910: assembler complains of invalid code

Fri, 10 May 2013 08:33:27 +0200

Running 'opam install ocamlnet' the build always stops due to errors in the generated assmbler code.
The computer is a raspberrypi with a patched ocaml compiler.

root@raspberrypi:~# ocamlc -v
The OCaml compiler, version 4.00.1
Standard library directory: /root/.opam/4.00.1+raspberrypi/lib/ocaml

root@raspberrypi:~# uname -a
Linux raspberrypi 3.2.27+ 0000250 PREEMPT Thu Oct 18 19:03:02 BST 2012 armv6l GNU/Linux

result from 'opam install --debug ocamlnet 2> opam.err'
root@raspberrypi:~# tail opam.err -n30
...
make[1]: Leaving directory `/root/.opam/4.00.1+raspberrypi/build/ocamlnet.3.6.0/src/netmech-scram'
make[1]: Entering directory `/root/.opam/4.00.1+raspberrypi/build/ocamlnet.3.6.0/src/netmech-scram'
ocamlfind ocamlopt -I ../../src/netsys -I ../../src/netstring -I ../../src/netgssapi -package "cryptokit unix" -c netmech_scram.ml
make[1]: Leaving directory `/root/.opam/4.00.1+raspberrypi/build/ocamlnet.3.6.0/src/netmech-scram'
### stderr ###
...[truncated]
Warning 11: this match case is unused.
File "nethttpd_services.ml", line 1118, characters 4-5:
Warning 11: this match case is unused.
/tmp/camlasm26c358.s: Assembler messages:
/tmp/camlasm26c358.s:9540: Error: shift expression is too large
/tmp/camlasm26c358.s:9632: Error: shift expression is too large
File "netmech_scram.ml", line 1:
Error: Assembler error, input left in file /tmp/camlasm26c358.s
make[1]: *** [netmech_scram.cmx] Fel 2
make: *** [opt] Fel 2

[17247] 17247 unlocking /root/.opam/4.00.1+raspberrypi/lock
'opam install --debug eliom' failed.

0006011: Signatures with private types can make modules less constrained

Wed, 08 May 2013 16:13:12 +0200

The following code behaves in a very unintuitive way that seems like a bug:

---------
module FA (U : sig end) : sig type t = private int end = struct type t = int end
module FB (U : sig end) = FA (U)
(* module FB (U : sig end) : sig type t = private int end = FA (U) *)
module M : sig type t = private int end = FB (struct end)
---------

It will fail with:

----------
File "foo.ml", line 4, characters 42-57:
Error: Signature mismatch:
Modules do not match:
sig type t end
is not included in
sig type t = private int end
Type declarations do not match:
type t
is not included in
type t = private int
File "foo.ml", line 4, characters 20-35: Expected declaration
File "foo.ml", line 1, characters 35-50: Actual declaration
EXIT STATUS 2
----------

However, using the commented-out definition of functor FB instead of the previous one will make the file pass the type checker. This is weird, because adding a signature should make a module more constrained, not less so.

It seems that without "type t = private int" acting as a reminder in the definition of FB, the compiler will forget about it and treat type t as fully abstract from then on, even though it shouldn't be.

0006006: Cannot "ocamlopt" the expression "x mod 1" on ARM

Wed, 08 May 2013 15:25:35 +0200

When I tried to compile ocamlnet on a Pandaboard the compiler failed with the messages

...
/tmp/camlasm0de67d.s: Assembler messages:
/tmp/camlasm0de67d.s:9339: Error: shift expression is too large -- `mov r0,r1,lsl#32'
/tmp/camlasm0de67d.s:9431: Error: shift expression is too large -- `mov r4,r5,lsl#32'
File "netmech_scram.ml", line 1:
Error: Assembler error, input left in file /tmp/camlasm0de67d.s
make[1]: *** [netmech_scram.cmx] Fehler 2
make: *** [opt] Fehler 2

0005994: Error: shift expression is too large

Wed, 08 May 2013 15:25:21 +0200

When trying to compile another project (the Haxe language compiler), Ocaml produces invalid assembly and compilation fails.

This is on a Raspberry Pi, compiled on the pi. I compiled Ocaml myself. Haxe is being built with ocamlopt.

Exact error:
ocamlopt -g -I libs/extlib -I libs/extc -I libs/neko -I libs/javalib -I libs/ziplib -I libs/swflib -I libs/xml-light -I libs/ttflib -c main.ml
/tmp/camlasmb25bdd.s: Assembler messages:
/tmp/camlasmb25bdd.s:26774: Error: shift expression is too large -- `mov r6,r7,lsl#32'

0006010: Big_int.extract_big_int does not handle negative numbers properly

Wed, 08 May 2013 10:44:38 +0200

This bug has been originally reported in Debian by Drake Wilson at:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707127 [^]

Big_int.extract_big_int does not handle negative numbers properly.

This function seems to assume that unrepresented prefix regions of
bits in a Big_int.big_int are always zero, but this is not so for
negative numbers. The documentation explicitly states that a two's
complement representation is used for those, but see the transcript
with comments inline.

0006009: Format.{pp_print_opt, pp_print_list, pp_print_text}

Tue, 07 May 2013 19:37:49 +0200

Ok, this time I got too tired of copy pasting that code.

First an option pretty printer.

(** [pp_print_opt pp_none pp_v ppf o] prints the optional value v. [pp_v] is used if [o] is [Some],
[pp_none] if [o] is [None] (default prints nothing). *)

let pp_print_opt ?(pp_none = fun ppf () -> ()) pp_v ppf = function
| None -> pp_none ppf ()
| Some v -> pp_v ppf v

Then a list pretty printer.

(** [pp_print_list pp_sep pp_v ppf l] prints the list [l]. [pp_v] is used on the elements of [l] and
each element is separated by a call to [pp_sep] (defaults to {!pp_print_cut}). Does nothing on
empty lists. *)

let rec pp_print_list ?(pp_sep = Format.pp_print_cut) pp_v ppf = function
| [] -> ()
| v :: vs ->
pp_v ppf v; if vs <> [] then (pp_sep ppf (); pp_print_list ~pp_sep pp_v ppf vs)

Then a string printer that hints newlines and spaces with Format's functions.

(** [pp_print_text ?nl ppf s] prints [s] with spaces and newlines respectively printed with
{!pp_print_space} and {!pp_force_newline}. *)

let pp_print_text ppf s = (* hint spaces and new lines with Format's funs *)
let len = String.length s in
let left = ref 0 in
let right = ref 0 in
let flush () =
Format.pp_print_string ppf (String.sub s !left (!right - !left));
incr right; left := !right;
in
while (!right <> len) do
if s.[!right] = '\n' then (flush (); Format.pp_force_newline ppf ()) else
if s.[!right] = ' ' then (flush (); Format.pp_print_space ppf ()) else
incr right
done;
if !left <> len then flush ()

0005407: Inline submodules, single-page HTML

Tue, 07 May 2013 14:35:44 +0200

Would it be possible to have the two following options:

1. keep the documentation of submodules on the same HTML page as the parent module (or compilation unit)

2. produce a single HTML page instead of about one per source file (implies option (1))

Both would make search easier, especially when the modules or submodules are many and small.

0006008: Document the behaviour of #4915

Tue, 07 May 2013 11:01:58 +0200

The manual doesn't document the {%backend: %} directive.

0006007: Type-checker rejects cyclic type abbreviation even though -rectypes is activated

Mon, 06 May 2013 14:28:37 +0200

This problem concerns ocamlc -rectypes. If I define a cyclic type
abbreviation foo as follows, it is accepted:

type 'a foo = 'a foo list (* accepted *)

However, I wish to abstract away the type list, so I place this
definition in the body of a functor, which expects list as an
argument. Then, the definition is rejected by ocaml 4.00.1:

module M (X : sig type 'a list end) = struct
type 'a foo = 'a foo X.list
(* accepted by ocaml 3.11.2; rejected by ocaml 4.00.1 *)
end

Is this a bug or is there a good reason to reject this definition?
Thanks!
Francois.

0005343: ocaml -rectypes is unsound wrt module subtyping

Mon, 06 May 2013 11:35:12 +0200

The following example should not be accepted...

module M : sig
type 'a t
type u = u t and v = v t
val f : int -> u
val g : v -> bool
end = struct
type 'a t = 'a
type u = int and v = bool
let f x = x
let g x = x
end;;

# let h x = M.g (M.f x);;
val h : int -> bool =
# h 3;;
- : bool =

0006004: Type information does not flow to "inherit" parameters

Sat, 04 May 2013 03:45:17 +0200

If we compile the following with -principal:

======================================================================
type t = A
type s = A

class f (_ : t) = object end

let _ = new f A (* ok *)

class g = object
inherit f A (* -> this type-based constructor disambiguation is not principal. *)
end
======================================================================

we get a warning 18, but only on the second occurrence of "f A". Is it normal?

0006005: Obj.magic with recursive modules

Fri, 03 May 2013 16:41:40 +0200

It seems that consistency of module type constraints is not checked. It is then possible to write Obj.magic by converting a module type to an implementation:

let magic : type a b. a -> b = fun x ->
let module M = struct
module type A = sig type t = X of a end
type u = X of b
module type B = A with type t = u
module rec M : B = M
end in
let M.X x = M.M.X x in
x

0006002: An easier way to avoid elided printing of values

Thu, 02 May 2013 13:34:35 +0200

A minor thing, this.

We have #print_depth and #print_length but one has to choose arbitrary values like 1000 to give to them (can't even use max_int because it's in a directive).

It would be nice to either hack the parser to allow max_int as a 'token' within integer-argumented directives, or alternatively add #print_all as a directive asking OCaml to never elide the output in any way (in other words, to ignore the values of print_length and print_depth).

0006003: simple references sometimes slow

Wed, 01 May 2013 15:20:10 +0200

The following two code samples show inefficiency in dealing with references.

I believe that the first example is more likely to appear in a real world code. I have a feeling that it may not be hard to fix.

The second example is more synthetic. I understand the reason and I don't have a clear idea how it could be solved.

0005985: Unexpected interaction between variance and GADTs

Tue, 30 Apr 2013 07:29:51 +0200

The following program

type _ t = T : 'a -> 'a s t

is accepted if s is covariant (e.g. type 'a s = 'a), contravariant (e.g. type 'a s = 'a -> unit) or invariant (e.g. type 'a s = 'a -> 'a), but rejected if s is "bivariant" (e.g. type 'a s = int):

# type 'a s = int;;
type 'a s = int
# type _ t = T : 'a -> 'a s t ;;
Characters 4-27:
type _ t = T : 'a -> 'a s t ;;
^^^^^^^^^^^^^^^^^^^^^^^
Error: In this definition, a type variable has a variance that
is not reflected by its occurrence in type parameters.

However, if s is abstracted then the program is accepted, even if s is instantiated with a bivariant constructor:

# include
(functor (S : sig type 'a s end) ->
struct
include S
type _ t = T : 'a -> 'a s t
end)
(struct type 'a s = int end)
;;
type 'a s = int
type _ t = T : 'a -> 'a s t
#