Skip to content
This repository has been archived by the owner on Feb 2, 2023. It is now read-only.

Things to work on

Jump to bottom
yallop edited this page Aug 17, 2016 · 252 revisions

NB: This page is not actively maintained. There is no guarantee that the suggested projects here will be merged upstream when completed. To avoid disappointment, consider contacting the OCaml developers before starting work on anything listed here.

See Getting started for OCaml installation instructions and other important details. Please keep this page updated: if you're working on an issue, edit the Who is working on this field; put your name down as a Mentor if you're willing to act as one; add other projects that you're working on to the list.

FLambda projects

The compiler-hacking label in the flambda repository includes additional suggestions.

Test/benchmark FLambda on existing OCaml programs

  • Expertise: ★☆☆☆☆
  • Time: ★★☆☆☆
  • Mentor: Leo
  • What needs to be done: The FLambda branch adds a whole new optimising phase to the OCaml compiler, intended to improve inlining in particular. It is being actively tested and benchmarked in order for it to be merged upstream in the next couple of weeks (in time for the OCaml 4.03 release). This effort would be greatly helped by testing and benchmarking existing OCaml programs with FLambda and OCaml trunk. Flambda can be found here in the flambda_trunk branch. Any issues or regressions can be reported here.

Support segmentation faults in the FLambda branch

  • Expertise: ★★★★☆

  • Time: ★★☆☆☆

  • Issue: https://github.com/OCamlPro/flambda-task-force/issues/24

  • Mentor: Mark/Leo

  • Who is working on this:

  • See the issue for details.

    It's sometimes useful for debugging purposes to have a way of reliably triggering segfaults. The current approach (coercing 0 to a pointer and then writing to it) is statically detected as an error with the flambda branch, so a new approach is needed.

Bugs & Features

Some bugs and features to work on:

Fix reordering of linker options

  • Expertise: ★★☆☆☆
  • Time: ★★☆☆☆
  • Mantis: http://caml.inria.fr/mantis/view.php?id=7150
  • Mentor:
  • Who is working on this:
  • What needs to be done: When invoking the linker, ocamlopt reorders the user-specified and library-embedded options, changing the order of the library search path. See the Mantis issue for more details.

Toplevel should not swallow exception in installed custom printers

# type t = A | B;;
type t = A | B
# let print_t fmt t = match t with A -> Format.fprintf fmt "A";;
Characters 20-60:
  let print_t fmt t = match t with A -> Format.fprintf fmt "A";;
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Warning 8: this pattern-matching is not exhaustive.
Here is an example of a value that is not matched:
B
val print_t : Format.formatter -> t -> unit = <fun>
# #install_printer print_t;;
# B;;
- : t = <printer print_t raised an exception>

Warn when a let rec function is not recursive

  • Expertise: ★★★☆☆

  • Time: ★★★☆☆

  • Mantis:

  • Mentor:

  • Who is working on this:

  • What needs to be done: Currently, there is no warning when a recursive functions are not invoked recursively. This could lead to difficult to debug behaviors. For example:

    # let foo x = print_int x;;
val foo : int -> unit = <fun>
# let rec loop = function
    | [] -> ()
    | x::xs -> foo (x);; (* Recursive call missed? *)
val loop : int list -> unit = <fun>

The following warning should be displayed:

```ocaml
Warning ??: Recursive function 'loop' is not invoked recursively.
```

There is a range of possibilities for warning about groups of functions bound with 'let rec'. For example, it might be helpful to issue a warning indicating that the following group

    let rec x = fun () -> (x; ())
    and y = fun () -> (z; ())
    and z = fun () -> (y; ())

can be broken up into two cliques:

    let rec x = fun () -> (x; ()) in
    let rec y = fun () -> (z; ())
    and z = fun () -> (y; ())
  • Status: Unused warning is implemented in Warning 39. Suggesting grouping isn't implemented yet.

Allow recursive bindings with _

  • Expertise: ★★★☆☆

  • Time: ★★★☆☆

  • Mantis:

  • Mentor: Leo

  • Who is working on this:

  • What needs to be done: Currently, you cannot use _ in recursive bindings:

    # let rec _ = () and x = 3;;
Characters 8-9:
  let rec _ = () and x = 3;;
          ^
Error: Only variables are allowed as left-hand side of `let rec'

    This is because patterns aren't allowed there, only variables. Really _ should be considered a variable in this context.

  • Status:

Add support for [@tailrec] annotations

  • Expertise: ★★★☆☆

  • Time: ★★★☆☆

  • Mantis:

  • Mentor:

  • Who is working on this:

  • What needs to be done: The new [@tailcall] annotation makes it possible to ensure that individual calls are in tail position. However, it's often more convenient to annotation function bindings (e.g. let rec groups) rather than individual calls. For example, we might annotate foldl as follows:

    let rec foldl [@tailrec] = fun op acc -> function
   [] -> acc
 | x :: xs -> try foldl op (op x acc) xs with Not_found -> assert false

    or perhaps

    let rec foldl = fun op acc -> function
   [] -> acc
 | x :: xs -> try foldl op (op x acc) xs with Not_found -> assert false
[@@tailrec]

    The suggested approach is to implement [@tailrec] in terms of [@tailcall].

  • Status:

Insert debug info for %revapply and %apply primitives

  • Expertise: ★★☆☆☆
  • Time: ★★☆☆☆
  • Mantis: 6258
  • Mentor:
  • Who is working on this:
  • What needs to be done: No debug information is inserted for used in backtraces for %revapply and %apply primitives.
  • Status:

Support explicit polymorphic types in value specifications

  • Expertise: ★★★☆☆

  • Time: ★★★☆☆

  • Mantis: None

  • Mentor: Leo

  • Who is working on this:

  • What needs to be done: Add support for the following syntax

    val id: 'a . 'a -> 'a

    which would mean the same as:

    val id: 'a -> 'a

    This should also be the default way to print out value specifications. This proposal should help users to appreciate the difference between the (universally quantified) type variables in value specifications and the (unification) type variables in regular type annotations (e.g. (add : 'a -> 'a)).

  • Status:

Document the -opaque option of ocamlopt and add OCAMLPARAM support

  • Expertise: ★☆☆☆☆
  • Time: ★☆☆☆
  • Mantis: 6955
  • Mentor:
  • Who is working on this:
  • What needs to be done: Add a description of the new -opaque option (added in this pull request) to the OCaml manual and to the ocamlopt man page. Add support for setting this option using the OCAMLPARAM environment variable.
  • Status:

Convert camlp4 extensions to use extension points

  • Expertise: ★★★☆☆
  • Time: ★★★☆☆
  • Mantis: None
  • Mentor:
  • Who is working on this: ???
  • What needs to be done: OCaml 4.02 adds support for extension points as a partial replacement for camlp4. A number of popular camlp4 extensions (e.g. pa_macro) would be very suitable for reimplementation using extension points. Peter Zotov has written a guide to writing extension points which could be a good starting point.
  • Status:

Support extending existing object types

  • Expertise: ★★★☆☆

  • Time: ★★★☆☆

  • Mantis: None

  • Mentor: Leo

  • Who is working on this: ???

  • What needs to be done: Polymorphic variant types can be used to build other polymorphic variant types:

    type foo = [ `A of int | `B of float ]
type bar = [ foo | `C of string ]

    It would be useful to do the same thing with object types:

    type foo = < a: int; b: float >
type bar = < foo; c: string >

    Note that this will only work for exact (closed) object types.

  • Status:

Warnings-as-errors not properly flushed in the toplevel

  • Expertise: ★★☆☆☆

  • Time: ★★☆☆☆

  • Mantis: 6396

  • Mentor:

  • Who is working on this:

  • What needs to be done: If a warning marked as an error is emitted in the top-level by a phrase which also triggers a regular error, then the warning-error will instead be raised for the next phrase. For example,

    $ ocaml -w +A -warn-error +A 
        OCaml version 4.02.0+dev5-2014-04-29

# class c = object   method x = 1   end;;
class c : object method x : int end

# class e = object inherit c  method x = 3 method f = 1 + "x" end;;
Warning 7: the method x is overridden.
Error: This expression has type string but an expression was expected of type
         int

# ();;
Error: Some fatal warnings were triggered (1 occurrences)

  • Status: Fixed by commit 837bcd6.

Name clashes

  • Expertise: ★★☆☆☆
  • Time: ★★☆☆☆
  • Mantis: 1956
  • Mentor: ???
  • Who is working on this: ???
  • What needs to be done: Check all external names have a "caml_" prefix and add C macros for backwards compatibility.
  • Status: Stephen added a list of the remaining name clashes to the mantis issue, and added a patch to stop marshall_flags from being exported.

Archive manipulation tool

  • Expertise: ★★☆☆☆
  • Time: ★★★☆☆
  • Mantis: 2375
  • Mentor: ?
  • Who is working on this:
  • What needs to be done: It would be useful to have a tool that could extract, list, and describe object files (.cmo) within an archive file (.cma), in the spirit of GNU ar.
  • Status:

Improve time printing and parsing functions

Fix documentation of printf's treatment of width specifiers

  • Expertise: ★☆☆☆☆
  • Time: ★★☆☆☆
  • Mantis: 4799
  • Mentor: ???
  • Who is working on this: ???
  • What needs to be done: document printf's treatment of width specifiers for the format specifiers %b, %c and %a. Investigate the interaction of width specifiers with other format specifiers. See the Mantis issue for details.
  • Status:

Give location information for warnings in ocamldoc

  • Expertise: ★☆☆☆☆

  • Time: ★★★☆☆

  • Mantis: 5901

  • Mentor: ???

  • Who is working on this: superbobry

  • What needs to be done: Currently ocamldoc reports warnings for problems such as unresolved cross-references, but does not report the location in the source where the problem occurred:

    $ cat w.ml
(** the function {!bar} is called by {!foo} *)
let bar x = x + 1

(** the function {!foo} calls {!bear} *)
let foo x = bar x
$ ocamldoc w.ml
Warning: Element bear not found

    The ocamldoc code needs to be updated to propagate location information and include it in warning messages.

  • Status: see comments on Mantis.

OCamldoc error location format improvements

  • Expertise: ★☆☆☆☆
  • Time: ★★☆☆☆
  • Mantis: 4518
  • Mentor: Daniel Buenzli
  • Who is working on this: ???
  • What needs to be done: The format in which ocamldoc reports error locations is inconvenient for tools such as Emacs, which parse error messages and navigate to the reported source location. See the Mantis bug for more details.
  • Status:

Integer range patterns

  • Expertise: ?

  • Time: ?

  • Mantis: None

  • Mentor:

  • Who is working on this: dsheets and @thizanne and @mbouaziz

  • What needs to be done: add support for char-style range for integers (int, int32, int64 and nativeint)

    let f = function
  | 0..100 -> true
  | _ -> false

  • Status:

Signatured open command

  • Expertise: ★★★☆☆

  • Time: ★★★☆☆

  • Mantis: None

  • Mentor: Leo

  • Who is working on this: Stephen

  • What needs to be done: Add a version of open which accepts a path and a signature, and only adds the members of the module that are in the signature into the environement.

    module type S = sig val x : int end

module M = struct let x = 3 let y = 4 end

open (M : S)

(* Only M.x has been added to the environment as x *)

  • Status: There is a patch (signatured-open) that allows the above code. However, it does not yet take account of changes in the ordering of module items, so code such as

    module type S = sig val y : int val x : int end

module M = struct let x = 3 let y = 4 end

open (M : S)

let z = x - y

    is not handled correctly (and can result in a segmentation fault).

Shrinkwrap optimisation for native code

  • Expertise: ★★★★☆
  • Time: ★★☆☆☆
  • Mantis:
  • Mentor: Stephen
  • Who is working on this: Stephen?
  • What needs to be done: Prologue/epilogue code need only be inserted around the parts of a function's body that actually use the stack. This would make the common case of caml_apply{1,2,3,N} a bit shorter.
  • Status:

"Junior Jobs"

The Mantis bug tracker contains a list of tasks that are resolvable by people unfamiliar with OCaml internals. These are listed under the tag junior job.

Large projects

Here's a list of larger compiler-related projects. We've outlined what needs to be done, and welcome contributions.

Add a "with" syntax for patterns

Value specifications in structures

Document the compiler

OPAM bulk logs

See OPAM bulk logs

Code reviews

A number of existing pull requests, some from earlier compiler hacking sessions, are awaiting code review. The core developers have limited time for thoroughly reviewing every proposal, so an "external" review is likely to increase the chances and speed of a proposal being accepted and merged.

There are a few dozen open requests at the GitHub OCaml repository.

More

Clone this wiki locally