Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006151OCamlback end (clambda to assembly)public2013-08-30 18:262016-12-07 10:46
Assigned To 
StatusclosedResolutionwon't fix 
PlatformOSOS Version
Product Version4.00.1 
Target VersionlaterFixed in Version 
Summary0006151: Misc.Fatal_error when using "%apply" for more arguments.
DescriptionI'm not really sure this is really a bug or "working as intended" but the joined file doesn't compile with the following message :

>> Fatal error: Cmmgen.transl_prim_3
Fatal error: exception Misc.Fatal_error

It does of course compile (and give the expected result with the signature :
('a -> 'b) -> 'a -> 'b

Also, and this is probably a bigger issue, the first line alone compile just fine as long as ap2 is not used.
TagsNo tags attached.
Attached Files? file icon [^] (83 bytes) 2013-08-30 18:26 [Show Content]

- Relationships
related to 0007408resolvednojebar Compile-time fatal error when we write external definitions with wrong signatures 

-  Notes
meyer (developer)
2013-08-31 00:50

I think it's reasonable to assume that all the builtins have fixed signature that match the one declared as data type. We should close this PR as variable arity %apply is a bad idea. On other hand "lambda" intermediate language supports only simple single argument apply.
drup (reporter)
2013-09-06 02:22

The fact that this code don't compile is fine, but the error reporting should be clearer and a type check should be done at the definition, not as the use.
doligez (administrator)
2013-09-11 22:22

By using external, you are giving up your right to static type checking, so in my opinion you should be happy to get an error at compile-time and not a segment violation at run-time.

That said, if there is a simple way of giving a better error message, I'm in favor of implementing it.
shinwell (developer)
2016-12-06 23:07

I think there are many higher-priority items on the agenda. Furthermore, use of % primitives outside the compiler distribution is not to be encouraged---if you play with fire, you should expect to get burnt occasionally. Closing this issue; please submit a patch via Github if you feel strongly enough.

- Issue History
Date Modified Username Field Change
2013-08-30 18:26 drup New Issue
2013-08-30 18:26 drup File Added:
2013-08-31 00:50 meyer Note Added: 0010279
2013-08-31 00:51 meyer Status new => closed
2013-08-31 00:51 meyer Assigned To => meyer
2013-08-31 00:51 meyer Resolution open => fixed
2013-09-06 02:22 drup Note Added: 0010317
2013-09-06 02:22 drup Status closed => feedback
2013-09-06 02:22 drup Resolution fixed => reopened
2013-09-11 22:22 doligez Note Added: 0010340
2014-01-21 14:01 doligez Assigned To meyer =>
2014-01-21 14:53 doligez Priority normal => low
2014-01-21 14:53 doligez Status feedback => confirmed
2014-01-21 14:53 doligez Target Version => later
2016-12-06 23:07 shinwell Note Added: 0016685
2016-12-06 23:08 shinwell Status confirmed => closed
2016-12-06 23:08 shinwell Resolution reopened => won't fix
2016-12-07 10:46 xleroy Relationship added related to 0007408
2017-02-23 16:35 doligez Category OCaml backend (code generation) => Back end (clambda to assembly)
2017-02-23 16:44 doligez Category Back end (clambda to assembly) => back end (clambda to assembly)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker