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

Misc.Fatal_error when using "%apply" for more arguments. #6151

Closed
vicuna opened this issue Aug 30, 2013 · 4 comments
Closed

Misc.Fatal_error when using "%apply" for more arguments. #6151

vicuna opened this issue Aug 30, 2013 · 4 comments

Comments

@vicuna
Copy link

vicuna commented Aug 30, 2013

Original bug ID: 6151
Reporter: @Drup
Status: closed (set by @mshinwell on 2016-12-06T22:08:01Z)
Resolution: won't fix
Priority: low
Severity: minor
Version: 4.00.1
Target version: later
Category: back end (clambda to assembly)
Related to: #7408
Monitored by: @Drup

Bug description

I'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.

File attachments

@vicuna
Copy link
Author

vicuna commented Aug 30, 2013

Comment author: meyer

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.

@vicuna
Copy link
Author

vicuna commented Sep 6, 2013

Comment author: @Drup

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.

@vicuna
Copy link
Author

vicuna commented Sep 11, 2013

Comment author: @damiendoligez

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.

@vicuna
Copy link
Author

vicuna commented Dec 6, 2016

Comment author: @mshinwell

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.

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

1 participant