Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0005778OCamlCamlp4public2012-10-09 12:312013-07-30 10:21
Reporterbeckerb 
Assigned Todim 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionwon't fix 
PlatformOSOS Version
Product Version4.00.1 
Target VersionlaterFixed in Version 
Summary0005778: Cannot re-bind "exception False"
DescriptionRe-binding an exception [font=courier]False[/font] causes an error "Unbound exception constructor" when using Camlp4 with original syntax.

[code]
# module M = struct exception False end;;
module M : sig exception False end
# exception False = M.False;;
Error: Unbound exception constructor
M. False
[/code]

Note the space before [font=courier]False[/font] in the error message.

BTW, there is a possibly related glitch when pretty-printing that exception in revised syntax:
[code]
# exception False;
exception false
[/code]
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0008226)
dim (developer)
2012-10-09 14:54

> Re-binding an exception [font=courier]False[/font] causes an error "Unbound exception constructor" when using Camlp4 with original syntax.

This part is fixed. Commits 12994 and 12995.

I think there are other places where the conversion is not done correctly: for example in "module False = struct end" the space at the beginning of False is kept.

> [code]
> # exception False;
> exception false
> [/code]

It is another problem in the conversion from the Camlp4 Ast to the OCaml Ast.
(0008227)
hongboz (developer)
2012-10-09 16:24

can you pinpoint which printer is buggy? probably it's the toplevel printer (Camlp4Top/Rprint.ml)
(0008228)
hongboz (developer)
2012-10-09 16:27

camlp4>camlp4r -str 'exception False;' -printer o
exception False
Yes, I think it's the Rprint's problem, Rprint's not very useful in my opinion
(0008229)
dim (developer)
2012-10-09 16:42

Actually it is not a printing problem. "False" can be used anywhere in revised syntax and Camlp4Ast2OCaml converts "False" to "false" (because the camlp4 ast uses "True" and "False" instead of "true" and "false", as in revised syntax):

  $ echo 'exception False;' > exn.ml
  $ ocamlc -dparsetree -pp camlp4r exn.ml
  [
    structure_item (exn.ml[1,0+0]..exn.ml[1,0+15])
      Pstr_exception "false"
      []
  ]
(0008230)
hongboz (developer)
2012-10-09 16:55

I see, the compiler does not check in 'Pstr_exception str' str is an uidentifier?

In my branch I keep the original syntax and revised syntax the same, they both use true, false, other syntax also the same, like 'a:=!b ' instead of 'a.val:=b.val', how do you think of it?
(0008946)
furuse (reporter)
2013-03-05 05:51

Today I found the same problem at

   type t = [ `True | `False ]

which `True and `False are translated to ` True and ` False.

When fixing, could you check they are also resolved?
(0008948)
hongboz (developer)
2013-03-05 14:48

This might be a design mistake, in Fan, there is no such translation, like the original syntax, 'true', 'false' are keywords instead. Given that Camlp4 is already deprecated internally, I am not sure such bugs might be fixed in time
(0008949)
frisch (developer)
2013-03-05 16:33

> Given that Camlp4 is already deprecated internally, I am not sure such bugs might be fixed in time

I think this is an over-statement. While there are efforts to move away from Camlp4 (Fan; -ppx and attributes; runtime types), it is fair to believe that Camlp4 will remain alive and used in large code bases for some more months/years.
(0008950)
dim (developer)
2013-03-05 17:10

I already tried to fix this issue, and it is just a nightmare. There are lot of places where the conversion from one way to the other is missing, and we have to be careful not to double convert True and False, i.e. not to end up with: "module false". I'll try to find the courage to give it another try.

I think the best solution would be to remove these kind of conversions but there is a good chance it would break many syntax extensions, which often use revised syntax inside quotations.

The best workaround for now is to avoid using True and False with camlp4...
(0008951)
hongboz (developer)
2013-03-05 17:52

Yes, it's quite tricky, especially in the meta level, and make sure to know that Camlp4 support anti-quotation by two ways: 1. the normal Ant node (this is fine) 2. string mangling via "\\$" prefix ( a place to introduce number of potential bugs)
(0008952)
furuse (reporter)
2013-03-06 07:02

Everyone hates P4 but it is also true that it survives few more years.

If fixing is too hard, how about providing better error message? Is it also too hard to reject creating malformed idents/paths at rebuilding OCaml Parsetree? Currently, the error we get around True and False are so cryptic and need to run camlp4o to see what is happening. This is very cumbersome.
(0008953)
dim (developer)
2013-03-06 10:44

Avoiding " True" and " False" should be feasible. This still means that sometimes we'll get "true" instead of "True" or the opposite.

BTW the printer and the camlp4 ast to ocaml parsetree converter are both mapping true and false independently so the output of camlp4o may be different to what is given to the compiler. [-dparsetree] or [-dsource] should be more helpful.
(0008954)
hongboz (developer)
2013-03-06 14:32

@dim, Maybe it's possible to remove some printers? the pprintast in the parsing directory is written using objects.
(0009758)
doligez (administrator)
2013-07-11 17:58

What is the status of this PR? The status field says "assigned" (which is a flavour of "open"), but the "Fixed in Version" says "4.00.2+dev" (which implies that it is fixed.
(0009788)
dim (developer)
2013-07-16 12:32

It is still open, the "Fixed in Version" was an error.

Actually if nobody objects or want to reassign the issue to himself I'll set the resolution to "won't fix". I don't see any simple fix and since camlp4 is going away I don't think it is worth spending too much time on this.
(0009789)
hongboz (developer)
2013-07-16 13:07

I would suggest a fundamental solution : no conversion table. What do you think?
(0009790)
dim (developer)
2013-07-16 13:26

Well, that would indeed be much simpler, but that would break extensions written using revised syntax quotations, which are quite common.

- Issue History
Date Modified Username Field Change
2012-10-09 12:31 beckerb New Issue
2012-10-09 14:44 dim Assigned To => dim
2012-10-09 14:44 dim Status new => assigned
2012-10-09 14:44 dim Fixed in Version => 4.00.2+dev
2012-10-09 14:54 dim Note Added: 0008226
2012-10-09 16:24 hongboz Note Added: 0008227
2012-10-09 16:27 hongboz Note Added: 0008228
2012-10-09 16:42 dim Note Added: 0008229
2012-10-09 16:55 hongboz Note Added: 0008230
2013-03-05 05:51 furuse Note Added: 0008946
2013-03-05 14:48 hongboz Note Added: 0008948
2013-03-05 16:33 frisch Note Added: 0008949
2013-03-05 17:10 dim Note Added: 0008950
2013-03-05 17:52 hongboz Note Added: 0008951
2013-03-06 07:02 furuse Note Added: 0008952
2013-03-06 10:44 dim Note Added: 0008953
2013-03-06 14:32 hongboz Note Added: 0008954
2013-07-11 17:58 doligez Note Added: 0009758
2013-07-11 17:58 doligez Target Version => 4.01.0+dev
2013-07-16 12:19 dim Fixed in Version 4.00.2+dev =>
2013-07-16 12:19 dim Target Version 4.01.0+dev => later
2013-07-16 12:32 dim Note Added: 0009788
2013-07-16 13:07 hongboz Note Added: 0009789
2013-07-16 13:26 dim Note Added: 0009790
2013-07-30 10:21 dim Status assigned => resolved
2013-07-30 10:21 dim Resolution open => won't fix


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker