Re: Put Error: before error output
Yitzchak, Sorry, I didn't get what you mean. Do you mean `error` [0] function from Prelude? The discussion is currently not regarding runtime program behavior, nor it is about `error` function. It's rather regarding compiler output message on compilation failure, so it shouldn't get mixed with your program's runtime behavior in any way. See ticket #10021 [1] for examples of what I'm talking about (I'm adding motivation section right now). [0]: http://hackage.haskell.org/package/base-4.7.0.2/docs/Prelude.html#v:error [1]: https://ghc.haskell.org/trac/ghc/ticket/10021#modify On Tue, Jan 27, 2015 at 6:49 PM, Yitzchak Gale g...@sefer.org wrote: -1 There are common idioms that rely on the current behavior, so I think this would break a lot code. Examples: In command line programs, it is very common to use error for printing the usage message. Many programs use error as a general way to exit from pure code with a message. I'm not commenting about whether or not those are good practice, just reporting that they are out there. I would be in favor of this though if it is off by default and is turned on by an option or pragma. But not just -Werror, though, except for messages that would otherwise have been prefixed by Warning, like the current behavior. Thanks, Yitz On Fri, Jan 23, 2015 at 1:04 PM, Konstantine Rybnikov k...@k-bx.com wrote: Hi! I'm bringing this up once again. Can we add Error: in the output of an error in a similar way ghc shows Warning: for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other Warning messages you get, since error is not always shown last on multi-core build. Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Put Error: before error output
Yes, correct. But I think ghci's errors are already distinguishable from `error`, e.g. this: ``` Prelude :set -Wall Prelude :load test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Ok, modules loaded: Main. Prelude let main = asdasdasd interactive:6:12: Not in scope: ‘asdasdasd’ *Main :load test2 [1 of 1] Compiling Main ( test2.hs, interpreted ) test2.hs:1:8: Not in scope: ‘foo’ Failed, modules loaded: none. Prelude error foo *** Exception: foo ``` will change to: ``` Prelude :set -Wall Prelude :load test [1 of 1] Compiling Main ( test.hs, interpreted ) test.hs:1:1: Warning: Top-level binding with no type signature: main :: IO () Ok, modules loaded: Main. Prelude let main = asdasdasd interactive:6:12: Not in scope: ‘asdasdasd’ *Main :load test2 [1 of 1] Compiling Main ( test2.hs, interpreted ) test2.hs:1:8: Error: Not in scope: ‘foo’ Failed, modules loaded: none. Prelude error foo *** Exception: foo ``` Don't think this will cause any trouble (well, except for current tests that check for output, which was mentioned in ticket #10021, but I hope it's not that big of a problem). On Tue, Jan 27, 2015 at 7:05 PM, Brandon Allbery allber...@gmail.com wrote: On Tue, Jan 27, 2015 at 12:02 PM, Konstantine Rybnikov k...@k-bx.com wrote: Sorry, I didn't get what you mean. Do you mean `error` [0] function from Prelude? The discussion is currently not regarding runtime program behavior, nor it is about `error` function. It's rather regarding compiler output message on compilation failure, so it shouldn't get mixed with your program's runtime behavior in any way ...unless using runhaskell/runghc. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: Put Error: before error output
I'd like to try and do both, since this shouldn't be hard and doesn't look like top-priority. On Mon, Jan 26, 2015 at 2:24 PM, Simon Peyton Jones simo...@microsoft.com wrote: There has been quite a long email trail about this. Would someone like to summarise in a Trac ticket feature request? Assuming there's a consensus, would anyone like to offer a patch? Should not hard. There will be an annoying cutover problem, because many regression tests will start failing. Anyone offering the patch would need to include all of those. Of course it'll affect other packages too -- hence the need for consensus. Simon | -Original Message- | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Sven | Panne | Sent: 25 January 2015 11:28 | To: Konstantine Rybnikov | Cc: ghc-devs@haskell.org | Subject: Re: Put Error: before error output | | 2015-01-23 12:55 GMT+01:00 Konstantine Rybnikov k...@k-bx.com: | If warnings will be treated as errors it's fine to have Error: shown | for | them, I think. | | +1 for this, it is how e.g. gcc behaves with -Werror, too. So unless | there is a compelling reason to do things differently (which I don't | see here), I would just follow conventional behavior instead of being | creative. :-) | ___ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: GHC support for the new record package
May I suggest something for a syntax (as an option, sorry if it's silly or
not related)? I really don't like neither @ or # because they seem too
hacky, meanwhile GHC already has an accessor syntax with braces { and },
so, might it be an option to have something like:
```
data Foo = Foo { val :: Int }
data Bar = Bar { foo :: Foo }
main = do
let bar = Bar (Foo 10)
print bar{foo{val}}
let bar' = bar{foo{val}=10}
return ()
```
I think this syntax is 100% understandable for a newbie. Not sure how is
it related to lenses though.
What do you think?
If the level of complaints I received when I stole (#) for use in lens is
any indication, er.. it is in very wide use. It was by far the most
contentious operator I grabbed. ;)
It seems to me that I'd not be in a hurry to both break existing code and
pay a long term syntactic cost when we have options on the table that don't
require either, the magic Field module approach that both Eric and I
appear to have arrived at independently side-steps this issue nicely and
appears to result in a better user experience.
Keep in mind, one source of objections to operator-based sigils is that if
you put an sigil at the start of a lens the tax isn't one character but
two, there is a space you now need to avoid (.#) when chaining these
things. foo.bar vs. #foo . #bar and the latter will always be uglier.
The `import Field (...)` approach results in users never having to pay more
syntactically than with options they have available to them now, and being
class based is even beneficial to folks who don't use Nikita's records.
-Edward
On Fri, Jan 23, 2015 at 5:47 PM, Greg Weber g...@gregweber.info wrote:
If we only add syntax when the language extension is used then we are not
clobbering everyone. # is not that common of an operator. I would much
rather upset a few people by taking that operator back when they opt-in to
turning the extension on than having a worse records implementation.
On Fri, Jan 23, 2015 at 2:23 PM, Edward Kmett ekm...@gmail.com wrote:
On Fri, Jan 23, 2015 at 5:06 PM, Adam Gundry a...@well-typed.com wrote:
Thanks for the feedback, Iavor!
On 23/01/15 19:30, Iavor Diatchki wrote:
2. I would propose that we simplify things further, and provide just
one
class for overloading:
class Field (name :: Symbol)
rec rec'
field field'
| name rec - field
, name rec'- field'
, name rec field' - rec'
, name rec' field - rec
where
field :: Functor f = Proxy name - (field - f field') -
(rec - f rec')
I don't think we need to go into lenses at all, the `field` method
simply provides a functorial
update function similar to `mapM`. Of course, one could use the
`lens`
library to
get more functionality but this is entirely up to the programmer.
When the ORF extension is enabled, GHC should simply generate an
instance of the class,
in a similar way to what the lens library does
3. I like the idea of `#x` desugaring into `field (Proxy :: Proxy x)`,
but I don't like the concrete symbol choice:
- # is a valid operator and a bunch of libraries use it, so it won't
be compatible with existing code.
Ah. I didn't realise that, but assumed it was safe behind -XMagicHash.
Yes, that's no good.
- @x might be a better choice; then you could write things like:
view @x rec
set @x 3rec
over @x (+2) rec
This could work, though it has the downside that we've been informally
using @ for explicit type application for a long time! Does anyone know
what the status of the proposed ExplicitTypeApplication extension is?
I'll confess I've been keen on stealing @foo for the purpose of (Proxy ::
Proxy foo) or (Proxy :: Proxy foo) from the type application stuff for a
long time -- primarily because I remain rather dubious about how well the
type application stuff can work, once you take a type and it goes through a
usage/generalization cycle, the order of the types you can apply gets all
jumbled up, making type application very difficult to actually use. Proxies
on the other hand remain stable. I realize that I'm probably on the losing
side of that debate, however. But I think it is fair to say that that
little bit of dangling syntax will be a bone that is heavily fought over. ;)
- another nice idea (due to Eric Mertens, aka glguy), which allows us
to avoid additional special syntax is as follows:
- instead of using special syntax, reuse the module system
- designate a magic module name (e.g., GHC.Records)
- when the renamer sees a name imported from that module, it
resolves the name by desugaring it into whatever we want
- For example, if `GHC.Records.x` desugars into `field (Proxy ::
Proxy x)`, we could write things like this:
import GHC.Records as R
view R.x rec
set R.x 3rec
over R.x (+2) rec
Interesting; I think Edward
Re: Put Error: before error output
Tuncer, If warnings will be treated as errors it's fine to have Error: shown for them, I think. On Fri, Jan 23, 2015 at 1:14 PM, Tuncer Ayaz tuncer.a...@gmail.com wrote: On Fri, Jan 23, 2015 at 12:04 PM, Konstantine Rybnikov wrote: Hi! I'm bringing this up once again. Can we add Error: in the output of an error in a similar way ghc shows Warning: for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other Warning messages you get, since error is not always shown last on multi-core build. Isn't kind of a compiler convention that Warning: is only prepended if an issue is treated as a warning. I mean, you can enable -Werror and treat all or specific warnings as errors as well. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Put Error: before error output
Hi! I'm bringing this up once again. Can we add Error: in the output of an error in a similar way ghc shows Warning: for warnings? Main reasoning is that, for example, on a build-server, where you have lots of cores to build your program, if you get an error, it gets lost somewhere in the middle of compiler's output in all other Warning messages you get, since error is not always shown last on multi-core build. Thanks. ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
Re: warn-redundant-constraints present as errors
On a slightly unrelated note I should say it would be great to have errors contain word Error:. This is especially nice to have because when you build with -j your error that stops compilation gets lost somewhere in the middle of many warnings (which my projects have, unfortunately). On Thu, Jan 8, 2015 at 11:45 PM, Alan Kim Zimmerman alan.z...@gmail.com wrote: This is a great feature, here is some feedback My syntax highlighter in emacs expects warnings to have the word warning in them. So for the two warnings reported below, the first is highlighted as an error, and the second as a warning Language/Haskell/Refact/Utils/TypeUtils.hs:3036:17: Redundant constraint: SYB.Data t In the type signature for: duplicateDecl :: SYB.Data t = [GHC.LHsBind GHC.Name] - t - GHC.Name - GHC.Name - RefactGhc [GHC.LHsBind GHC.Name] Language/Haskell/Refact/Utils/TypeUtils.hs:3045:7: Warning: Defined but not used: ‘toks This is in a ghci session, and the file loads without problems, so it is indeed a warning. Can we perhaps add the word Warning to the output for Redundant constraints? I also had a situation where it asked me to remove a whole lot of constraints from different functions, I did them in batches, so did not remove them all from the file at once, and at some point I had to add at least one of them back, albeit based on an error message. Regards Alan ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
