[Resending to the list, I used the wrong address. Sorry for the duplicate
copies.]
On 19 dec. 2013, at 05:30, Richard Eisenberg wrote:
> I'd say GHC has it right in this case.
>
> (f a ~ g b) exactly implies (f ~ g) and (a ~ b) if and only if the kinds
> match up. If, say, (f :: k1 -> *), (g
Op 15 jan. 2013, om 18:16 heeft Karel Gardas het
volgende geschreven:
> Well, if you make some board available in DMZ I'm certainly interested to run
> at least configure on it from GHC HEAD to see what we need to hack in order
> to add support for RPi into GHC HEAD.
>
> Unfortunately GHC HE
Op 15 jan. 2013, om 17:36 heeft rocon...@theorem.ca het volgende geschreven:
> Okay, I tried:
>
> SRC_HC_OPTS= -H64m -Rghc-timing -optc-mfloat-abi=hard
> -optc-march=armv6 -optc-mfpu=vfp -optlc=-mattr=+vfp2
> GhcStage1HcOpts= -O -fllvm
> GhcStage2HcOpts= -O0 -fllvm
> GhcLibHcOpt
Op 14 jan. 2013, om 17:30 heeft rocon...@theorem.ca het volgende geschreven:
> On Thu, 10 Jan 2013, Karel Gardas wrote:
>
>>
>> Hmm, are you using Raspbian? I.e. hard-float abi caught my eye in case of
>> ARMv6/ARM11 chip here...
>>
>> I'm afraid LLVM is not well guided in your case so could
Op 8 jan. 2013, om 05:16 heeft rocon...@theorem.ca het volgende geschreven:
> On Thu, 3 Jan 2013, Thijs Alkemade wrote:
>
>> I believe I had the same problem, which disappeared after upgrading llvm
>> from 3.0 to 3.1, and using that instead for ./configure.
>>
>
(Sorry, forgot to CC the list)
Original Message
From: Thijs Alkemade
Sent: Thu Jan 03 10:31:50 CET 2013
To: rocon...@theorem.ca
Subject: Re: Error building ghc on raspberry pi.
rocon...@theorem.ca wrote:
>Some further information it seems that llc is segfaulting:
&g
uous type variable
In the second argument of `_a', namely `_'
In the expression: _a _b _
In an equation for `f': f = _a _b _
---
I think this is a good compromise that gives you named holes and
easily allows you to turn unbound identifiers into holes. What do you
think?
Re
On 4 okt. 2012, at 23:33, Roman Cheplyaka wrote:
> Sounds cool. I would also expect that if you have several occurences of
> the same unbound identifier, then it gets a unified type.
>
We have actually tried to do it this way for a pretty long time. But it's not
as
easy as it sounds. We were
uot;test2.hs:3:16"), but
> | somehow not something like: "In the expression: folder _ x _, In an
> | equation for `test': test x = foldr _ x _". Help with how that is
> | supposed to work would also be appreciated.
>
> That's odd. Every Wanted constr
not trying to figure
out what could fit into it. Also, I was adding it to GHC directly, not using
the GHC API, so our approaches are quite different. But I'm hoping my
experience might help you a little.
Could you show how simplifyTop fails, or show a bit mor
th how that is supposed to work would also be
appreciated.
I'm attaching a patch of all my changes compared to HEAD as of about a week
ago. All my work can also still be found on https://github.com/xnyhps/ghc.
patch.diff.gz
Description: GNU Zip compressed data
Best
that should make
this feature easier to implement later.
Best regards,
Thijs Alkemade
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ork.
I.e. generating constrains when a hole is encountered, so the same
name used multiple times will be inferred correctly. However, these
should propagate differently from implicit parameters and should not
create an error when the constraint is not in the type signature.
Regards,
Thijs
g Main ( Foo.hs, interpreted )
Found a hole at Foo.hs:1:20-21: Integer -> Integer
...
And that's it. It might help IDEs later on, but that is not our goal.
Regards,
Thijs Alkemade
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
ype of this part".
As an update to my problem with Any *: I think I've found the cause.
The holes were inferred independently, not all of them at once (they
are now all passed as name_taus to simplifyInfer), and this was
happening after zonkTopDecls was already done, so all unbound type
On Wed, Jan 25, 2012 at 5:50 PM, Iavor Diatchki
wrote:
> So, whenever GHC infers a type `forall a. P => t` where `a` does not
> appear in `P` or `t`, it knows that the `a` does not matter, so t
> simply defaults it to `Any`.
>
Okay. Thanks for your explanation. But it's still not clear to me in
an idea about what to do to avoid the introduction of
these GHC.Prim.Any * types?
Best regards,
Thijs Alkemade
[1]
http://www.haskell.org/pipermail/glasgow-haskell-users/2012-January/021453.html
[2] https://github.com/xnyhps/ghc/commits/master
___
Glas
On 5 jan. 2012, at 14:08, Sean Leather wrote:
> We're currently looking into so-called expression holes in GHC -- like the
> type goals of Agda -- and we've run into a problem of understanding.
>
> We have defined an expression, call it __ for now, for which we want to find
> the type after a
18 matches
Mail list logo
