Oops. Resending to list:
---
Right, same goes for every type error in that case though. (We also
ban -fdefer-type-errors in the hackage server, FYI, so it's not like
it can affect released code very much anyway.)
In light of this discussion I've made this change in
It actually can affect what code compiles with -fdefer-type-errors, but I
don't feel terribly strongly about that.
-Edward
On Tue, Jan 14, 2014 at 12:23 PM, Joachim Breitner wrote:
> Hi,
>
> heh, I wanted to throw in the same argument: If its just more elaborate
> error messages, why do we n
On Tue, Jan 14, 2014 at 12:14 PM, Austin Seipp wrote:
> If it's turned into a 'warning', my idea was just to turn -XTypeHoles
> to -Wtype-holes and turn it on by default, so this can be switched
> off.
... which, I might add, is rather the same for *all* warnings, so it's
really more of a bikeshe
The program is still rejected with an error if _ occurs on the RHS,
it's just a matter of what the compiler says in this specific case.
$ cat test.hs
module Main (main) where
test :: a -> a
test a = _
main = print $ test (10 :: Int)
$ ./inplace/bin/ghc-stage2 test.hs
[1 of 1] Compiling Main
Stupid question: is it really only better error messages? What about being
allowed to use _ on the RHS?
On Tue, Jan 14, 2014 at 6:23 PM, Joachim Breitner
wrote:
> Hi,
>
> heh, I wanted to throw in the same argument: If its just more elaborate
> error messages, why do we need a flag for it? So co
Hi,
heh, I wanted to throw in the same argument: If its just more elaborate
error messages, why do we need a flag for it? So count that as +1 from
me.
Greetings,
Joachim
Am Dienstag, den 14.01.2014, 11:12 -0600 schrieb Austin Seipp:
> I'm actually more in favor of Richard's proposal of just rem
I'm actually more in favor of Richard's proposal of just removing the
flag to be honest, now that he mentioned it. And it's not like it's
much more code.
In any case, as Duncan informed me we'll have a Cabal release anyway,
so I'll work on sorting this out and enabling it.
On Tue, Jan 14, 2014 at
On Tue, 2014-01-14 at 17:44 +0100, Johan Tibell wrote:
> I can make another cabal release if needed, if someone submits a pull
> request with the right fix (i.e. add TypedHoles with TypeHoles as a
> synonym.)
Thanks Johan, or I'm happy to do it.
Duncan
> On Tue, Jan 14, 2014 at 5:33 PM, Austin S
I can make another cabal release if needed, if someone submits a pull
request with the right fix (i.e. add TypedHoles with TypeHoles as a
synonym.)
On Tue, Jan 14, 2014 at 5:33 PM, Austin Seipp wrote:
> At the very least, Type(d)Holes would never appear explicitly since it
> would be enabled by
Perhaps I'm being silly, but if the extended errors are enabled by default, and
they seem to cause no problems, does the feature even need a name? The release
notes could say something like "extended type information is produced for
out-of-scope variables beginning with an underscore" or similar
At the very least, Type(d)Holes would never appear explicitly since it
would be enabled by default. But it might be turned off (but I don't
know who would do that for the most part.) Cabal at least might still
need an update.
In any case, Herbert basically summed it up: the time window is kind
of
Hi,
On 2014-01-14 at 17:14:51 +0100, David Luposchainsky wrote:
> On 14.01.2014 17:07, Austin Seipp wrote:
>> We probably won't change the name right now however. It's already
>> been put into Cabal (as a recognized extension,) so the name has
>> propagated a slight bit. We can however give it a n
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14.01.2014 17:07, Austin Seipp wrote:
> We probably won't change the name right now however. It's already
> been put into Cabal (as a recognized extension,) so the name has
> propagated a slight bit. We can however give it a new name and
> deprecate
Hi all,
As a follow up to these, Simon and I discussed it in a call today, and
we're actually both in favor of enabling TypeHoles by default. The
reasoning is as stated: it provides more useful error messages and
doesn't cause any programs to fail to work. It's strictly a
development aide when you
Hi Merijn,
Let me suggest the Fail type family in
http://www.haskell.org/pipermail/haskell-cafe/2013-November/111549.html
--
Adam
On Tue, Jan 14, 2014 at 8:56 AM, Merijn Verstraaten
wrote:
> I was trying to fix one of my closed type families examples for the new
> syntax, and run into an unfor
You can of course produce an infinite set of vacuous constraints using
the Symbol type (or any two non-equal types). For example, here you
could use:
Restrict a (a ': as) = ("Error" ~ "Oops! Tried to apply a restricted type!")
Erik
On Tue, Jan 14, 2014 at 2:56 PM, Merijn Verstraaten
wrote:
I was trying to fix one of my closed type families examples for the new syntax,
and run into an unfortunate issue. Due to a kind error in my code one of my
constraints was being silently discarded (see ticket:
https://ghc.haskell.org/trac/ghc/ticket/8669)
The main reason I resorted to this (in
I'd like to repeat the suggestion to use cabal. It's very well suited
for simple programs. In addition, you get the ability to specify
dependencies, you can upload to hackage, etc.
Erik
On Mon, Jan 13, 2014 at 11:10 PM, Christian Brolin wrote:
> Thanks, but it is not a complicated build process.
18 matches
Mail list logo
