On Jun 16, 2009, at 05:19 , Simon Peyton-Jones wrote:
(B) data RecTest a where
B :: { arg :: a } -> RecTest a
For what it's worth (considering that I have yet to actually use
GADTs), (A) looks wrong to me because there is type information before
the actual type. (B) looks kinda st
> You're not looking at the latest version of the code. I'm guessing
> you're looking at the stable version instead of the HEAD.
Indeed, I'm looking at the source distribution for 6.10.3, since
that's the reference version I use to test the files.
>> ctypedoc :: { LHsType RdrName }
>> : 'fo
2009/6/18 Niklas Broberg :
> GHC:
>> ctypedoc :: { LHsType RdrName }
>> : 'forall' tv_bndrs '.' ctypedoc
>> | context '=>' ctypedoc
>> | gentypedoc
>
> Notice GHC's recursive call to ctypedoc after the =>. I have no idea
> what the doc suffix on the production is intended to i
Hi all,
I've had a curious bug report [1] for haskell-src-exts, pointing to a
difference in behavior between haskell-src-exts and GHC. Digging
further, it seems to me like GHC is behaving quite strange in this
instance, but since we don't have formal documentation for the
extensions I can't be sur
> hmm, that's annoying. Is it feasible for the extensions field to allow both
> addition and subtraction that override compiler defaults? (How does it work
> in LANGUAGE pragmas -- would NoMonoPatBinds still work in one of them?)
It would only work during the period of deprecation, and would
obv
Duncan Coutts wrote:
In practise, since ghc uses MonoPatBinds by default it'd mean that
people who want to get back to H98 would need to use:
ghc-options: -XNoMonoPatBinds
Because the extensions field is additive, not subtractive. Using the
name MonoPatBinds allows other compilers to implemen
> In general I think there is a reasonable case for special treatment for
> exceptions to H98 that have been accepted for haskell-prime.
I'm not sure I agree with this. I'm not involved in the H' process,
but it was my impression that the general state of affairs was a move
towards a modularizatio
Simon,
Thanks for the quick reply, and also the link. I'll be sure to read
it. I don't know what pre-inlining is; I was testing different
compiler options with acovea, which indicated the performance boost.
When I tried it myself, I noticed the differing value.
I'm pretty sure the affected code
Simon Marlow wrote:
I'm an infrequent etags user, and I never use ctags.
The problem is I do not know whether I should try to improve etags too.
So far I tried to keep them the same they were. The only difference I
know about is that if more tags happen to exist on the same source line
then
John
| When compiled with -fno-pre-inlining, my test program gives a
| different result than compiled without (0.988... :: Double, compared
| to 1.0). It's numerical code, and was originally compiled with
That's entirely unexpected. I am very surprised that turning off pre-inlining
a) affects th
Hello,
I was experimenting with compiler flags trying to tune some
performance and got something unexpected with the -fno-pre-inlining
flag. I was hoping somebody here might be able to clarify an issue
for me.
When compiled with -fno-pre-inlining, my test program gives a
different result than co
On 17/06/2009 10:14, Peter Hercek wrote:
Hi GHC and VI users,
I got frustrated with vi tags not working after some unrelated code is
edited in a source file. Moreover non-exported top level declarations
were not available in vi tags file. Here is an attempt to fix it:
http://www.hck.sk/users/pet
Duncan Coutts wrote:
> Niklas's and my point is
> that the list of language extensions in Language.Haskell.Exceptions
> are differences from H98 so it should be MonoPatBinds to get the
> difference not NoMonoPatBinds to restore H98.
> In practise, since ghc uses MonoPatBinds by default it'd
13 matches
Mail list logo
