2012/5/31 Iavor Diatchki :
> Hello,
>
> the notion of a functional dependency is well established, and it was used
> well before it was introduced to Haskell (for example, take a look
> at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
> redefine it lightly.
Indeed, GHC's
Thanks!
I just read your article. I think your proposal is rational, useful and so
brilliant!
The new yield/await style would make writing conduits much easier.
Thank you again for taking so much time for this problem!
On 2012/05/29, at 22:14, Michael Snoyman wrote:
> OK, after thinking on thi
Hello,
the notion of a functional dependency is well established, and it was used
well before it was introduced to Haskell (for example, take a look at
http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to
redefine it lightly.
Note that placing a functional dependency constraint
Sorry for the delayed response -- I've had exams the past few days.
On Sun, May 27, 2012 at 8:21 PM, Eugene Kirpichov wrote:
> A lot of people have done this :) eg from me: google up a fairly recent
> thread from me about processing streams and perhaps the keyword "timeplot"
> (writing from a d
On Wed, May 30, 2012 at 8:30 PM, Jonathan Geddes
wrote:
> I had hoped that compiling Haskell to C with -fvia-C (or would it be just
> -C?) would allow Haskell to run in new, uncharted territory such as Android
> (with NDK), IOS, Google's NaCl, etc. But today I learned that GHC's C
> backend has be
Welcome to issue 229 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers the
week of May 20 to 26, 2012.
Quotes of the Week
* Peaker: Harrop taught me that I am a team of experts
* applicative: Even if no one else understands m
I love Haskell. It is my absolute favorite language. But I have a very hard
time finding places where I can actually use it!
I had hoped that compiling Haskell to C with -fvia-C (or would it be just
-C?) would allow Haskell to run in new, uncharted territory such as Android
(with NDK), IOS, Google
Hi Antoine and Roman,
On Wed, May 30, 2012 at 4:14 PM, Antoine Latter wrote:
> We changed how 'try' handled errors in some cases in between 3.1.1 and
> 3.1.2. I'll take a look at this.
>
> Antoine
>
Thanks for confirming -- I tried 3.1.2 and got the same result as Matthias.
And Roman, thanks fo
* Matthias Hörmann [2012-05-30 21:36:13+0200]
> And my question about this is made up of two parts
>
> 1. Why doesn't it print my "unexpected" message but instead says unknown
> parse error
> 2. Why is the location in the text off (I would expect it to fail at column
> 6 (first character beyond t
On Wed, May 30, 2012 at 4:18 PM, Kevin Charter wrote:
> On Wed, May 30, 2012 at 3:11 PM, Kevin Charter wrote:
>>
>> What version of parsec 3 are you using? In version 3.1.1, I get (using
>> Text.Parsec.String instead of Text.Parsec.Text):
>
>
> Ah, answered my own question. I gather you're using
On Wed, May 30, 2012 at 3:11 PM, Kevin Charter wrote:
> What version of parsec 3 are you using? In version 3.1.1, I get (using
> Text.Parsec.String instead of Text.Parsec.Text):
>
Ah, answered my own question. I gather you're using 3.1.2, since it's the
first and so far only version with the Tex
Hi Matthias,
On Wed, May 30, 2012 at 1:36 PM, Matthias Hörmann wrote:
> parseTest (do; r1 <- anyOf ["Hello", "Hallo", "Foo", "HallofFame"]; r2 <-
> string "bla"; return (r1, r2)) "Hallofbla"
>
> which prints this:
>
> parse error at (line 1, column 8):unknown parse error
>
> And my question about
Hello,
I disagree with your example.
> 1. Check that an instance is consistent with itself. For example, this
> should be rejected:
>
> instance C a b
>
> because it allows C Int Bool and C Int Char which violate the functional
> dependency.
Functional dependencies are not used to pick types, t
I recently started writing my first application at work in Haskell and it
deals with a lot of parsing.
Among other things I often have to check for a lot of alternatives for
fixed strings (parsing natural
language text and people have a lot of ways to abbreviate the same thing in
labels). So far I
Hello,
On Wed, Jul 7, 2010 at 2:14 PM, Simon Peyton-Jones wrote:
> We can’t permit overlap for type families because it is *unsound *to do
> so (ie you can break “well typed programs don’t go wrong”). But if it’s
> unsound for type families, it would not be surprising if it was unsound for
> fun
Hi haskell-cafe
In my current project I'm working with type representations created with
PolyTypeable, and it turns out that given two type representations I need
to find out if they are unifiable.
I've looked at polytypeable-utils and see that they have some functions for
substituting/applying/fr
16 matches
Mail list logo
