I think my point was more along the lines that every *value*, regardless of
whether it's a function or not, can be partial (ignoring primitive types
and such). I can hand you a list where the third Int in it will cause you
to crash if you force it.
In that sense, whether every numeric literal expa
Why are potentially partial literals scarier than the fact that every value
in the language could lead to an exception when forced?
On Tue, Apr 24, 2012 at 5:35 AM, Yitzchak Gale wrote:
> Markus Läll wrote:
> > You do know, that you already *can* have safe Text and ByteString from
> > an overlo
I think it'll be hard to do that without putting Text in base, which I'm
not sure anyone wants to do.
Dan
On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber wrote:
> I would like to default IsString to use the Text instance to avoid
> ambiguous type errors.
> I see defaulting capability is available f
Can't we just have the usual .Internal module convention, where people who
want internals can get at them if they need to, and most people get a
simpler interface? It's amazingly frustrating when you have a library that
does 99% of what you need it to do, except for one tiny internal detail
that th
Yeah, you should absolutely mind the order of the parameters (or more
generally, when the operation isn't commutative), the strictness of the
function's second parameter. In this case, both (&&) and (||) are strict in
their first parameter, but both "short circuit" if the first parameter is
False/T
Isn't gcc just used for its assembler and object file creation, these days,
now that via-C is deprecated? Or are there other parts of it that are
needed?
On Mon, Jun 6, 2011 at 10:47 AM, Malcolm Wallace wrote:
>
> On 6 Jun 2011, at 13:49, Lyndon Maydwell wrote:
>
> > I would be fantastic if XCode
I don't have an answer for you, but you might want to look at what :k does
in ghci, since that needs to parse a type.
On Sat, Apr 23, 2011 at 2:06 PM, Ranjit Jhala wrote:
> Hi all,
>
> can someone give me a hint as to the best way to parse a type from a
> string.
> Ideally, I'd like a function
>
I think what you want is closed type families, as do I and many others :)
Unfortunately we don't have those.
On Mon, Feb 14, 2011 at 10:02 PM, Conal Elliott wrote:
> Yes, it's one things that data families do. Another is introducing *new*
> data types rather than reusing existing ones. - Conal
>
The -march=-i686 issue was fixed in the past couple of days, so I'd just
grab a newer version. Not sure about the 64-bit question, though.
-Dan
On Tue, Feb 1, 2011 at 6:50 AM, Pavel Perikov wrote:
> hi list.
>
> i have to build ghc-7.1.20110125 under mac os x, so i grabbed the stable
> snapshot
So the basic point seems to be: "if you know how to use a tool, you don't
usually curse and swear when you use it. If you don't, you tend to swear a
lot!"
:)
On Mon, Jan 10, 2011 at 5:32 PM, Adam Wick wrote:
> On 01/10/2011 08:52 AM, Malcolm Wallace wrote:
>
>> If I were considering contributin
I fully support this (especially if it lived on github), but we should
probably sort the top contributors to GHC in the past year or so and
consider their opinions on the matter in that order :) I certainly would not
be on that list. A git(hub)-based workflow would however facilitate any
minor cont
I thought GHC's own codegen didn't do any instruction reordering for the
pipeline. I guess that ends up not being much of an issue in practice?
On Sun, Feb 14, 2010 at 12:58 PM, Don Stewart wrote:
> igloo:
> >
> > Hi all,
> >
> > We are planning to remove the -fvia-c way of compiling code
> > (u
I hope it'll be possible :) I heard a general overview of the plugins
infrastructure a few months ago and it sounded like what I'd need, but I was
unable to find a very detailed account of how it works and what specific
information is available to plugins, so maybe I'm just dreaming.
2010/1/27 Ty
You can use -fvia-C and -keep-hc-files but the generated C code is
pretty platform-dependent (at least in terms of word sizes and so
on... it may be possible to port across platforms with the same word
sizes?), and probably won't help you cross-compile. It also doesn't
look much like any c code any
Hi Luca,
Just in case you weren't aware of it, your example didn't actually
contain any STM (beyond the import), just regular Haskell IO-based
concurrency.
But the answer to your question is that there's no synchronization on
writing to a file descriptor, so both threads are "simultaneously"
writ
This isn't necessarily correct, is it? An equality-based (n^2) nub
works "fine" on infinite lists, whereas any O(n log n) sort-based nub
must necessarily evaluate the entire list before being able to return
the value. The original n^2 nub also returns the elements in the order
of their first appear
That looks great! I wonder what about Mac OS leads to such good performance...
Now if only we could get a nice x86_64-producing GHC for Mac OS too, I
could use all my RAM and the extra registers my Mac Pro gives me :)
On Sat, Apr 18, 2009 at 2:39 PM, Dave Bayer wrote:
> I'm a huge fan of the rec
17 matches
Mail list logo
