Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Camlp4 incorrectly expands a quotation containing an 'assert false' expression. #5839

Closed
vicuna opened this issue Dec 2, 2012 · 5 comments
Closed
Assignees

Comments

@vicuna
Copy link

vicuna commented Dec 2, 2012

Original bug ID: 5839
Reporter: pveber
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2015-12-11T18:08:26Z)
Resolution: not fixable
Priority: normal
Severity: major
Version: 4.00.0
Category: -for Camlp4 use https://github.com/ocaml/camlp4/issues

Bug description

Summary: attached to this bug report is a tiny syntax extension which leads to a typing error in "compilation mode" on a simple example. However, when using camlp4 to generate an .ml file in the same setting, the generated program is correct.

In more details: the syntax extension expands a record-like type declaration to a module type in a signature and to a module in a structure. There is only one function in the generated module. While its signature is correct in the module type, the generated implementation is wrongly typed and produces a 'signature mismatch' error when compiled.

However, when I generate the ml file with camlp4 first, the generated file is correct and there is no problem when compiled.

Steps to reproduce

run 'make strange' to see the compilation error.

then run 'make expected' to see the generated file (called expected.ml) and see that it is interpreted by the toplevel without any problem.

File attachments

@vicuna
Copy link
Author

vicuna commented Dec 2, 2012

Comment author: pveber

Just one remark,

changing line 15

value input () = assert $`bool:false$;

by

value input () = failwith "";

or

value input () = failwith $`str:""$;

solves the problem. So the issue seems related to the use of assert.

@vicuna
Copy link
Author

vicuna commented Dec 2, 2012

Comment author: @gasche

This is not a Camlp4 bug but an oddity in the semantics of "assert false".

OCaml recognizes two different syntactic constructors:

  • assert false (that generates the parstree Pexp_assertfalse)
  • assert foo (for foo <> false) (Pexp_assert (...))

The first has type 'a, the second has type unit. You can check this with:

fun x -> assert x;;

  • : bool -> unit =

Now your code actually produces the second construction, rather than the first, because of the antiquotation indirection (which prevents the parser from recognizing the special case). The expression has type unit and therefore the module doesn't type-check.

Now if you print the Camlp4 output to a file, you get "assert false" which is re-parsed into the special-case construct.

This is not a problem with Camlp4 itself, but rather with assert.

(The option -dparsetree is fairly useful in debugging those problems: you get to see a dump of the OCaml parsetree after the camlp4 preprocessing step. I was reminded of the difference by comparing the output of -dparsetree for the two ways to compile your file.)

@vicuna
Copy link
Author

vicuna commented Dec 3, 2012

Comment author: @bobzhang

we may give a warning for this case

@vicuna
Copy link
Author

vicuna commented Dec 3, 2012

Comment author: pveber

Thanks Gabriel for the explanation, I wasn't aware of this peculiarity. Sorry for wasting your time!

@vicuna
Copy link
Author

vicuna commented Dec 3, 2012

Comment author: @alainfrisch

A typical example where writing correct Camlp4 code requires expert knowledge about OCaml's AST, even though Camlp4 tries hard to hide this AST from you.

Well, in this case, I would have expected Camlp4 to try to fix this weird behavior of OCaml syntax, by having a single node for "assert", mapping to the correct one according to whether the argument turns out to be "False" or not. This would introduce some "discontinuity", but this might be less surprising for the user.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants