Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner: igloo
Type: feature request| Status: new
Priority: normal | Milestone: 7.8.1
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
+---
Changes (by igloo):
* milestone: 7.6.2 => 7.8.1
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner: igloo
Type: feature request| Status: new
Priority: normal | Milestone: 7.6.2
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Os: Unknown/Multiple | Architecture: Unknown/Multiple
Failure: None/Unknown | Difficulty: Unknown
Testcase: | Blockedby:
Blocking: |Related:
+---
Changes (by igloo):
* difficulty: => Unknown
Comment:
The main problem I find with "-XFoo" is that you can't easily select it
just by double clicking on it. That means that if you want to put it into
a LANGUAGE pragma then you have to manually select everything apart from
the X.
What do people think about allowing "-X Foo" as a command-line flag, and
then using that form in error messages?
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner: igloo
Type: feature request| Status: new
Priority: normal | Milestone: 7.6.1
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by igloo):
* milestone: 7.4.1 => 7.6.1
Comment:
punting
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner: igloo
Type: feature request| Status: new
Priority: normal | Milestone: 7.4.1
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by igloo):
* owner: => igloo
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner:
Type: feature request| Status: new
Priority: normal | Milestone: 7.4.1
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by igloo):
* status: infoneeded => new
* milestone: 7.2.1 => 7.4.1
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner:
Type: feature request| Status: infoneeded
Priority: normal | Milestone: 7.0.1
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Comment(by simonpj):
I liked the "`-X`" in error messages because it's a ''brief''.
2-character, way of saying that you can use a flag or a `LANGUAGE` pragma.
But I'm happy to adopt whatever convention our users want!
Simon
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner:
Type: feature request| Status: infoneeded
Priority: normal | Milestone: 7.0.1
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Testcase: | Blockedby:
Difficulty: | Os: Unknown/Multiple
Blocking: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by michalt):
* cc: michal.terep...@… (added)
* status: new => infoneeded
Comment:
To be honest -X error messages are a bit annoying at times. But
what
output exactly do we want? For instance now GHC reports something
like this:
{{{
`Foo' has no constructors (-XEmptyDataDecls permits this)
}}}
maybe removing -X would be better?
{{{
`Foo' has no constructors (EmptyDataDecls permits this)
}}}
or
{{{
`Foo' has no constructors (-XEmptyDataDecls/EmptyDataDecls permits this)
}}}
or even
{{{
`Foo' has no constructors (-XEmptyDataDecls/LANGUAGE EmptyDataDecls
permits this)
}}}
Personally I think simply removing -X would be both readable and easy to
paste
(I usually specify the extensions in LANGUAGE pragmas and not as a command
line
arguments). On the other hand the last one is easiest for pasting but
quite a
bit longer and somewhat less readable. Any opinions?
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner:
Type: feature request| Status: reopened
Priority: normal | Milestone: 6.14 branch
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by igloo):
* milestone: => 6.14 branch
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner:
Type: feature request| Status: reopened
Priority: normal | Milestone:
Component: Compiler (Parser) |Version: 6.10.4
Resolution: | Keywords: language pragma extensions
error message warning
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by eflister):
* status: closed => reopened
* resolution: wontfix =>
Comment:
Replying to [comment:4 igloo]:
you could still fix the error message. from OP:
the ghc error message indicating that an extension should be added should
print out a message that would make for easy cut and paste without
modification into *either* one's language pragma or command line -X
extension args.
what about accepting -Extension flags (without the X) at the command line?
how is that X helping anyone?
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
+---
Reporter: eflister | Owner:
Type: feature request| Status: closed
Priority: normal | Milestone:
Component: Compiler (Parser) |Version: 6.10.4
Resolution: wontfix| Keywords: language pragma extensions
error message warning
Difficulty: | Os: Unknown/Multiple
Testcase: | Architecture: Unknown/Multiple
Failure: None/Unknown |
+---
Changes (by igloo):
* status: new => closed
* failure: => None/Unknown
* resolution: => wontfix
Comment:
I agree with Duncan: If GHC accepted
{{{
{-# LANGUAGE -XFoo #-}
}}}
then people would start using it, and then the code would not be portable.
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--+-
Reporter: eflister | Owner:
Type: feature request | Status:
new
Priority: normal| Milestone:
Component: Compiler (Parser) |Version:
6.10.4
Severity: trivial | Resolution:
Keywords: language pragma extensions error message warning | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
--+-
Comment (by duncan):
Replying to [comment:2 eflister]:
> not to be annoying, but i don't understand why it's not ok for ghc to
accept (with a warning) a SUPERSET of the official syntax.
At first you'd expect that accepting a superset would not cause any
problems. However what happens is that people will start using that new
syntax and then suddenly those packages/programs cannot be used with the
tools that stick to the official syntax.
> that doesn't change the standard and it doesn't imply that any other
compiler has to do anything different.
It doesn't change the official standard but it does change the de-facto
standard, and other compilers and tools will have to change to keep up so
that they can continue to process all code that people write.
> a warning would be the best user interaction -- "i know what you meant
to say, and i'm doing it, you should just know that what you said isn't
portable, and here's how to fix it. would you like me to fix it for you?"
Certainly a nice error message is good however I would suggest that it be
"i know what you meant to say, here's how to fix it." (and perhaps an IDE
could also do "would you like me to fix it for you?"). Also accepting the
program has a low benefit and a non-trivial cost.
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--+-
Reporter: eflister | Owner:
Type: feature request | Status:
new
Priority: normal| Milestone:
Component: Compiler (Parser) |Version:
6.10.4
Severity: trivial | Resolution:
Keywords: language pragma extensions error message warning | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
--+-
Comment (by eflister):
not to be annoying, but i don't understand why it's not ok for ghc to
accept (with a warning) a SUPERSET of the official syntax. that doesn't
change the standard and it doesn't imply that any other compiler has to do
anything different. a warning would be the best user interaction -- "i
know what you meant to say, and i'm doing it, you should just know that
what you said isn't portable, and here's how to fix it. would you like me
to fix it for you?"
--
Ticket URL:
GHC
Re: [GHC] #3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-} pragmas/extensions
#3647: unify handling and error messages for -X vs. {-#LANGUAGE ...#-}
pragmas/extensions
--+-
Reporter: eflister | Owner:
Type: feature request | Status:
new
Priority: normal| Milestone:
Component: Compiler (Parser) |Version:
6.10.4
Severity: trivial | Resolution:
Keywords: language pragma extensions error message warning | Testcase:
Os: Unknown/Multiple | Architecture:
Unknown/Multiple
--+-
Comment (by duncan):
By all means improve the error message but please do not extend the
LANGUAGE pragma syntax. It means every other compiler and tool that has to
know about the pragma must also be extended (and in a rather quirky way).
Standards are a good thing! :-)
Perhaps we can get ghc's error messages to suggest LANGUAGE pragmas rather
than the ghc -XBlah style.
--
Ticket URL:
GHC
