#844: panic on conflicting patterns in TH splice
-+--
Reporter: guest |Owner:
Type: bug | Status: new
Priority: normal|Milestone:
It happens all the time to me that GHC doesn't die properly on windows.
Every so often I have to kill a few straggling ghc processes. They
all spin consuming 100% CPU when this happens.
-- Lennart
On Aug 2, 2006, at 10:09 , Bulat Ziganshin wrote:
Hello GHC,
Wednesday, August 2,
#844: panic on conflicting patterns in TH splice
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
#844: panic on conflicting patterns in TH splice
---+
Reporter: guest | Owner:
Type: bug | Status: new
Priority: normal| Milestone:
I'm not doubting that it's genuine -- but can anyone make a reproducible
test case?
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Lennart Augustsson
| Sent: 04 August 2006 13:47
| To: Bulat Ziganshin
| Cc: GHC;
But as long as it's Haskell code consuming all those CPU cycles,
it can't be all bad? :)
If any of you are running into this while invoking ghci.exe,
you may want to play with using ghc.exe --interactive instead
to see if that improves matters. Not using ghci.exe avoids
a layer of
#845: irrefutable pattern matching on unboxed tuple causes panic
--+-
Reporter: Jason McCarty [EMAIL PROTECTED] |Owner:
Type: bug| Status: new
#821: implicit parameters and type synonyms
-+--
Reporter: [EMAIL PROTECTED] | Owner:
Type: support request | Status: closed
Priority: normal | Milestone:
I just realised I sent the following only to [EMAIL PROTECTED], not
glasgow-hasell-users:
Simon Marlow wrote:
Just a quick note to say thanks for all the offers of help on 6.4.3 -
it's very encouraging to see so many people willing to offer their time
and machines.
The state of play so far:
Hi Simon,
I'll set up ssh access to a dual processor FreeBSD box. It should be
ready by later today (I'll send a note).
Best,
Greg
On Aug 4, 2006, at 8:08 AM, Simon Marlow wrote:
I just realised I sent the following only to [EMAIL PROTECTED], not
glasgow-hasell-users:
Simon Marlow wrote:
As for the subject under discussion (thread local state), I am
personally sceptical about it. Why do we need it? Are we talking
about safety or just convenience/API elegance? I've never
encountered a situation where I've needed thread local state,
(but this does not necessarily make it
On 04.08 17:29, Frederik Eaton wrote:
might, in Adrian Hey and Einar Karttunen's world, become:
newMain host environment program_args
network_config locale terminal_settings
stdin stdout stderr = do
hPutStrLn stdout (defaultEncoding locale) Hello world
Actually I have
what's the difference between data and co-data
exactly? or between inductive data types and
co-inductive data types? can you give me some
reference points that explain these?
(read 56)::Integer
does it in fact pass the type (Integer) to the
function (read)? I guess what we want is for the
Imam Tashdid ul Alam wrote:
what's the difference between data and co-data
exactly? or between inductive data types and
co-inductive data types?
In Haskell there is no such difference, as inductive and coinductive
types coincide in the semantic setting in which Haskell is usually
On Sat, Jul 29, 2006 at 05:35:30PM -0700, Andrew Pimlott wrote:
On Sat, Jul 29, 2006 at 02:59:06AM +0200, Udo Stenzel wrote:
Andrew Pimlott wrote:
Second, foo is just as good a directory
as foo/ to the system
...unless you have both (think Reiser4) or you want to create the file
(I
Mark T.B. Carroll wrote:
Janis Voigtlaender [EMAIL PROTECTED] writes:
(snip)
Yes, as long as enough type information is provided for the
typechecker to decide what is the correct instance to use.
(snip)
I've always been a little surprised when this doesn't happen more
widely for things other
Hello Mark,
Friday, August 4, 2006, 3:03:54 PM, you wrote:
I've always been a little surprised when this doesn't happen more widely
for things other than instances. For instance, when IntMap.size,
Map.size and Set.size (or whatever) are all in scope as size, it
should be fairly obvious what
Bulat Ziganshin wrote:
this is called ad-hoc polymorphism which is not supported by Haskell.
instead Haskell supports parametric polymorphism via type classes.
I think you are wrong here Bulat. In fact, I think
a) Haskell supports parametric polymorphism, e.g.
id :: t - t
id x = x
b) Haskell
Hello All,
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
I can think of the following possibilities only:
1) Haskell is too slow for practical use, but the benchmarks I found
appear to contradict this.
2) Input and output are not
Martin Percossi wrote:
Bulat Ziganshin wrote:
this is called ad-hoc polymorphism which is not supported by Haskell.
instead Haskell supports parametric polymorphism via type classes.
I think you are wrong here Bulat. In fact, I think
a) Haskell supports parametric polymorphism, e.g.
id :: t
On Fri, 4 Aug 2006, Hans van Thiel wrote:
...
Are there other reasons why there seem to be just a few thousand
(hundred?) Haskell programmers in the world, compared to the 3 million
Java programmers and x million C/C++ programmers?
I can think of several other possible reasons -
6.
Hans van Thiel wrote:
Hello All,
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
I can think of the following possibilities only:
1) Haskell is too slow for practical use, but the benchmarks I found
appear to contradict this.
2)
On Aug 4, 2006, at 1:12 PM, Martin Percossi wrote:
Hi, I'm wondering what the rationale was for not allowing
capitalized variable names (and uncapitalized type names and
constructors). I can only think of two arguments, and IMHO both of
them are bad:
1. Enforces a naming convention.
Martin Percossi wrote:
Hi, I'm wondering what the rationale was for not allowing capitalized
variable names (and uncapitalized type names and constructors). I can
only think of two arguments, and IMHO both of them are bad:
I'm not so sure about variable names and constructors, but the type
Ok, you asked for it, so here's my worst :-)
1) Here's what the History of Haskell has to say about this:
Namespaces were a point of considerable discussion in the Haskell
Committee. We wanted the user to have as much freedom as possible,
while avoiding any form of ambiguity. So we
Hans van Thiel wrote:
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
Of course. Corporations are conservative to the point of being
boneheaded. So to avoid risk, they all went on the internet and said,
Gee, I can't find any
Hans van Thiel wrote:
Hello All,
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
I'm actually working on a Haskell program which I hope to release as a
commercial application. The biggest problem I'm encountering is the lack
Paul Hudak wrote:
Ok, you asked for it, so here's my worst :-)
You're too gentle! I was expecting some serious community flagellation
for my heretical remarks!
1) Here's what the History of Haskell has to say about this:
Namespaces were a point of considerable discussion in the
On Fri, 4 Aug 2006, Martin Percossi wrote:
I agree that naming can be abused. But I think it should be *me*, the
programmer, or in the limit ghc, the glorious compiler (but only because of
unresolvable ambiguities), who decides it -- not *you*, the language
implementor!!! ;-)
The ML
On Fri, 4 Aug 2006, Udo Stenzel wrote:
Hans van Thiel wrote:
I'm wondering why I can't find any commercial Haskell applications on
the Internet. Is there any reason for this?
Of course. Corporations are conservative to the point of being
boneheaded. So to avoid risk, they all went on the
On Fri, 4 Aug 2006, Brian Hulley wrote:
4) Haskell is open source and licensing restrictions forbid commercial
applications. I haven't seen any such restrictions, but is this a
problem for the standard modules?
You can discover the licensing situation by downloading the GHC source (or
Hello Brian,
Friday, August 4, 2006, 8:50:25 PM, you wrote:
class Bar a b where
bar :: a - b
(*) But there's one exception: you can't use typeclasses to resolve
overloadings between values and functions because non-function values don't
have a type of the form A - B:
Hello Hans,
Friday, August 4, 2006, 8:17:42 PM, you wrote:
1) Haskell is too slow for practical use, but the benchmarks I found
appear to contradict this.
it's an advertisement :D just check yourself
2) Input and output are not good enough, in particular for graphical
user interfacing
Hello Jason,
Friday, August 4, 2006, 10:01:31 PM, you wrote:
15. OO is now tried and true in industry. I would say it's far from
optimal but people do know they can build large applications (say
~100k lines of C++).
it's medium size. GHC is larger :)
--
Best regards,
Bulat
Hello,
I am attempting to process images captured from a webcam. My aim is to
do so, in real time, at the frame rate of the camera. I'm using GHC
6.4.2 with -O3.
A frame consists of ~100k 24bit colour values.
The webcam is interfaced through FFI bindings to some C++ -- these are
all labelled
Bulat Ziganshin wrote:
Hello Brian,
Friday, August 4, 2006, 8:50:25 PM, you wrote:
class Bar a b where
bar :: a - b
(*) But there's one exception: you can't use typeclasses to resolve
overloadings between values and functions because non-function
values don't have a
Chad
| x = runST $ return (1::Int)
This code looks simple, but it isn't. Here are the types:
runST :: forall a. (forall s. ST s a) - a
($) :: forall b c. (b-c) - b - c
return 1 :: forall s. ST s Int
To typecheck, we must instantiate
b with (forall s. ST
Martin Percossi wrote:
Paul Hudak wrote:
foo x y = ...
We know that x and y are formal parameters, whereas if they were
capitalized we'd know that they were constructors.
I agree that naming can be abused. But I think it should be *me* ...
Oh, you like to decide lexical ambiguities.
Hi fellow Haskelleers,
I have a tricky problem that I just can't seem to solve. The problem
is one of unresolved overloading, much like the (show . read) issue,
but unlike that particular problem I feel there should be a solution
to the one I'm wrestling with.
I've tried to strip away all the
Jeff Briggs wrote:
Hello,
I am attempting to process images captured from a webcam. My aim is to
do so, in real time, at the frame rate of the camera. I'm using GHC
6.4.2 with -O3.
A frame consists of ~100k 24bit colour values.
The webcam is interfaced through FFI bindings to some C++ -- these
Martin Percossi wrote:
Hi, I'm wondering what the rationale was for not allowing capitalized
variable names (and uncapitalized type names and constructors). I can
only think of two arguments, and IMHO both of them are bad:
1. Enforces a naming convention. Fine - but my view is that this
doesn't
There are two places where confusion could arise if you didn't have
the case distinction in Haskell: pattern matching (does a name refer
to a constructor or not) and type expressions (is it a type variable
or not).
In Haskell the distinction is made by case, but this is far from the
only
G'day all.
Quoting Udo Stenzel [EMAIL PROTECTED]:
Uh, this one's wrong. Does C++ of 15 years ago support today's programs?
C++ of _today_ doesn't support today's programs in some cases. Just
ask the Boost developers about the various workarounds they still have
to deal with.
No. C++ of 10
Thanks All
This is about my tries to understand monads and handling state - as
you perfectly know - is one of them. I have understood a little about
monads but that knowledge does not satidfy me. Again Thankyou
On 8/2/06, Duncan Coutts [EMAIL PROTECTED] wrote:
On Wed, 2006-08-02 at 13:26 +0330,
44 matches
Mail list logo
