-
Notifications
You must be signed in to change notification settings - Fork 680
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
Constraint language: add a positive way to automatically enable flags #7293
Comments
Flags are toggled from the "outside". The only thing you can do "inside" is to check that configuration is valid. For example, one can try to compile on Windows with
I don't understand what you mean by "occurs positively / negatively". |
To point to related ideas: I proposed sometime in the past for these cases to augment the cabal flag definition syntax to change the Different platforms tend to have different preferred default configurations; that feature would help with that aspect The other aspect of being able to express a Prolog-ish
or variant of this inspired by Python's
(the example above assumes a new logic operator to denote logical implication to keep the example more obvious) |
@phadej wrote:
The spec says something else:
So flags can be forced by constraints. Atm, only indirectly ("negatively"), by producing contraditions from specific flag assignments. But we could as well force them directly ("positively".
Sorry, this is logic speak. In |
I guess I meant "inside as positively. Consider an example
this is most likely nonsense. We force flag toggling because of some effect that flag will have. So what Herbert says: having a way to express I don't think we need to allow flags (or EDIT: One could translate
into
But this is not exactly the same. I'm worried that |
I suppose having But flags and package-names (like e.g.
So the double-negation of a flag-proposition is allowed, but not the flag-proposition itself...
It is logically equivalent, but with the new The current translation is this (or logically equivalent):
which is quite some obfuscation. If
|
Yes. Maybe. I once again forgot to not participate in Cabal development. Have fun! (unsubscribing) (EDIT: to clarify, and don't make decisions on Cabal anymore, so feel free to ignore my comments) |
If I want to enable a flag based on some conditions, I have to do hackery like (N) [1]:
I'd rather be able to state this positively, e.g. (P):
It seems like (N) isn't understood by
stack
[2].In general, it seems that logic isn't first-class in the cabal language. Some propositions can only occur negatively, it seems (like
flag
,os
,true
,false
). Positive occurrence seems to be reserved tobuild-depends
propositions (and maybe some few more).For a start, why cannot
false
occur positively?, to allow me to write:(That's not my ultimate goal, of course.)
[1] haskell-hvr/regex-posix@13c28e9#r47401775
[2] commercialhaskell/stack#5404
The text was updated successfully, but these errors were encountered: