My build dies very soon after issuing "make". Here are the last few
lines. Does anyone know what is happening and how to fix it? (The
floating constant of which the error message speaks is
__GHC_PATCHLEVEL__, which is set to 2.20060331.) I have a working GHC
6.4 installed, BTW.
/sec/bin/g
-0300, Robin Bate Boerop wrote:
> My build dies very soon after issuing "make". Here are the last few
> lines. Does anyone know what is happening and how to fix it? (The
> floating constant of which the error message speaks is
> __GHC_PATCHLEVEL__, which is set to 2.2006
tead of "LANGUAGE CPP" in the
pragma, the pragma is ignored. Is this a documentation bug?
To test the problem, one can use "ghc --make testpragma1.hs" and "ghc
--make testpragma2.hs" on the following:
testpragma1.hs
Description: Binary data
testpra
map toLower) over the pragma
> > identifier before comparison with known pragma names?
>
> Currently the lexer looks for them as regexps, e.g.
> "{-#" $whitechar* (LANGUAGE|language) { token ITlanguage_prag }
>
> I've filed a bug for this here:
> http://hackage.haskell.org
Alex, Lennart's suggestion makes me think: Why not make SearchPath
into a preprocessor? It could recognize a .ehs extension, and then do
some very simple preprocessing (adds pragmas according to user's
settings).
--
Robin Bate Boerop
On 22/11/2007, Lennart Augustsson <[EMAIL PROT
ectly then we are good to go!
>
> -Alex-
>
> Robin Bate Boerop wrote:
> > Alex, Lennart's suggestion makes me think: Why not make SearchPath
> > into a preprocessor? It could recognize a .ehs extension, and then do
> > some very simple preprocessing (adds pr
On 19-Apr-05, at 6:34 AM, John Meacham wrote:
This seems to be such a common question, perhaps someone could write up
something on the wiki that goes into more depth on what the issues are
with generalized type synonyms?
I would find this useful. More useful would be an answer not about
type syno
t, no, I haven't verified this by
examining the object code.)
--
Robin Bate Boerop
On 14-Apr-06, at 12:25 PM, Lajos Nagy wrote:
I was just musing the other day about the possibility of allowing
(efficient and transparent) destructive updates in certain
situations. Take the
type is less polymorphic than expected
Quantified type variable `a' escapes
Expected type: a a1 -> b
Inferred type: C a1 -> Int
In the first argument of `($)', namely `f'
In the definition of `g': g x = f $ x
What&
