0005778: Cannot re-bind "exception False"

(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.

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

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.

Relationships