Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

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

Option to disable -principal mode #5561

Closed
vicuna opened this issue Mar 27, 2012 · 19 comments
Closed

Option to disable -principal mode #5561

vicuna opened this issue Mar 27, 2012 · 19 comments

Comments

@vicuna
Copy link

vicuna commented Mar 27, 2012

Original bug ID: 5561
Reporter: @alainfrisch
Status: confirmed (set by @damiendoligez on 2013-12-05T14:39:06Z)
Resolution: open
Priority: low
Severity: feature
Category: typing

Bug description

It would be convenient to add a -noprincipal flag to the compiler. With OMake for instance, it would make it easy to add -principal to OCAMLFLAGS globally for the project, and then append -noprincipal to OCAMLFLAGS for some directories.

@vicuna
Copy link
Author

vicuna commented Mar 27, 2012

Comment author: @gasche

So you would call ocamlc -principal -noprincipal or ocamlc -noprincipal -principal, and expect it to disable principality checks? That looks a little weird to me (I like to think that command-line arguments are declarative rather than imperative).

@vicuna
Copy link
Author

vicuna commented Mar 27, 2012

Comment author: @alainfrisch

The last option would take precedence, as for warnings. I find it quite convenient to be able to define a "OCAMLFLAGS" globally, and adapt it locally for specific files or directories, by appending some extra options.

@vicuna
Copy link
Author

vicuna commented Mar 29, 2012

Comment author: @protz

What about an optional parameter after -principal?

  • -principal ? current behavior
  • -principal yes ? current behavior
  • -principal no ? overrides any previous values for the argument.

That sounds like a valid use-case for a big codebase.

@vicuna
Copy link
Author

vicuna commented Mar 29, 2012

Comment author: @gasche

Regarding the interface, I rather prefer Alain's proposal.

The change would however raise the question of doing this for other options: -norectypes, -nostrict-sequence, -stdlib, -assert, -nounsafe... (But we already have -nolabels and -labels that (if I understand correctly) do are not inverse one of another.)

I'm not sure the case for warning makes for a good precedent (no pun intended), but if it's decided to add -noprincipal I really don't see why we shouldn't have -norectypes as well.

@vicuna
Copy link
Author

vicuna commented Mar 29, 2012

Comment author: @alainfrisch

-rectypes is quite viral: if you compile a module with it, you need to compile all other modules that depend on it with -rectypes as well. So it's rather unlikely that -rectypes would be the default for a big project, with some "-norectypes" exceptions.

I also don't expect -unsafe to be the default for a big code base. It could be turned on for performance-critical and carefully verified code (but in my experience, it has a rather low impact, so I'm not even sure it is used at all).

A -nostrict-sequence would probably make sense.

@mshinwell
Copy link
Contributor

@alainfrisch Given there has been no progress on this issue for 8 years, would you like to perhaps implement the flag (I agree that positional precedence seems fine, but watch out for OCAMLPARAM) or close this issue?

@gasche
Copy link
Member

gasche commented Apr 20, 2020

The original feature request sounds like a good newcomer job, marking it as such.

@mshinwell
Copy link
Contributor

There's no point in spending newcomer time on features people don't actually want, though. (I'm not certain that is the case for this one, but it seems likely...)

@gasche
Copy link
Member

gasche commented Apr 21, 2020

There is a tension here: things that are very important to a core developer are not useful "newcomer jobs" either because they get done quickly. It is actually useful for onboarding new people to have issues or feature requests that are not urgently important, and also not too difficult or controversial.

@alainfrisch
Copy link
Contributor

FWIW, I don't really care about the feature any more, and I'm certainly not against closing it. Re-assigning to @gasche to let you decide whether it's good to keep this open as a "newcomer job".

@alainfrisch alainfrisch assigned gasche and unassigned alainfrisch Jun 3, 2020
@damiendoligez
Copy link
Member

In general, it would be good to have every flag come in pairs to disable/enable. That makes it easier to do all kinds of build-system hacks, and it also makes it easier to change the default later.

The newcomer job could be to identify the flags that don't have their negative, and to add all the missing ones. It's not so trivial because of the OCAMLPARAM business.

@github-actions
Copy link

github-actions bot commented Aug 3, 2022

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Aug 3, 2022
@damiendoligez
Copy link
Member

Still a good "first issue".

@shindere
Copy link
Contributor

shindere commented Sep 13, 2022 via email

@gasche
Copy link
Member

gasche commented Sep 13, 2022

I think a function returning the two options in a list would be a good first step.

@shindere
Copy link
Contributor

shindere commented Sep 13, 2022 via email

@gasche
Copy link
Member

gasche commented Sep 13, 2022

I don't understand your remark about the help text. We generate the options, so we could choose for example to always set the help text of the -no-... option to "(negation of the option ...)" or something.

Currently we show for example:

  -principal  Check principality of type inference
  -no-principal  Do not check principality of type inference (default)

I think we could have a function generating exactly that, possibly by taking the two help descriptions in arguments (... but (default) could be added programmatically). If we decide to use a different convention to advertise these options, maybe we can still implementing it as a functional helper. I would first try to decide the output we want, and only then think about the implmentation.

@shindere
Copy link
Contributor

shindere commented Oct 11, 2022 via email

@dra27
Copy link
Member

dra27 commented Oct 21, 2022

Just to link it in, I think the original issue was addressed in 2016 in #514

@ocaml ocaml locked and limited conversation to collaborators Jan 26, 2023
@Octachron Octachron converted this issue into discussion #11966 Jan 26, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests

7 participants