Consider
module Bug where
e = fmap id 1
ghci --version
The Glorious Glasgow Haskell Compilation System, version 5.02.2
says
:l Bug.hs
Compiling Bug ( Bug.hs, interpreted )
Bug.hs:5:
No instance for (Num (f a))
arising from the literal `1' at Bug.hs:5
In the second
The reason there's an error message at all is because of the
monomorphism restriction. So that's not surprising.
So the compiler has to solve the constraints { Num (f a), Functor f }
in the absence of any other context whatsoever.
So the constraint (Functor f) is certainly ambiguous, in the
The reason there's an error message at all is because of the
monomorphism restriction. So that's not surprising.
Can you suggest a better error message? I'm always looking for ways to
report errors more informatively.
It may be hard to do, but it would be helpful in cases like this for
the
Bugs item #643878, was opened at 2002-11-26 01:12
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032
Category: Prelude
Group: 5.04.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Mike Gunter (magunter)
Assigned to:
Bugs item #643878, was opened at 2002-11-26 01:12
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032
Category: Prelude
Group: 5.04.1
Status: Open
Resolution: None
Priority: 7
Submitted By: Mike Gunter (magunter)
Assigned to:
We don't support Posix for Win32. It's probably not impossible to
implement it, but we have not devoted the time to do so. Maybe you can?
Simon
| -Original Message-
| From: Ahn Ki-yung [mailto:[EMAIL PROTECTED]]
| Sent: 25 November 2002 06:37
| To: [EMAIL PROTECTED]
| Subject: how can
Simon Marlow [EMAIL PROTECTED] writes:
One reason, I think, is lazy I/O(*). It's to stop you accidentally
[...]
(*) kill it! die! die!
So you want
main = readFile /dev/zero return ()
to terminate violantly rather than terminate peacefully? :)
Seriously, I understand that
Simon Marlow:
[Lazy I/O] is nice, but it introduces too many problems. What
happens to any I/O errors encountered by the lazy I/O? They have to
be discarded, which means you can't effectively use lazy I/O for
robust applications anyway.
Surely they are thrown as exceptions which can then
On Mon, Nov 25, 2002 at 10:09:01AM -, Simon Marlow wrote:
It is nice, but it introduces too many problems. What happens to any
I/O errors encountered by the lazy I/O? They have to be discarded,
which means you can't effectively use lazy I/O for robust applications
anyway.
Simon Marlow:
[Lazy I/O] is nice, but it introduces too many problems. What
happens to any I/O errors encountered by the lazy I/O? They have to
be discarded, which means you can't effectively use lazy I/O for
robust applications anyway.
Surely they are thrown as exceptions which can
I am reading the article template meta-programming for haskell and am
wondering if
1) this is already implemented in ghc.
2) if not when this will be released
Thanks in advance
Immanuel
***
His endeavours to improve these
Simon Marlow wrote:
Simon Marlow:
[Lazy I/O] is nice, but it introduces too many problems. What
happens to any I/O errors encountered by the lazy I/O? They have to
be discarded, which means you can't effectively use lazy I/O for
robust applications anyway.
Surely they are
On Mon, Nov 25, 2002 at 11:22:56AM -0500, Dean Herington wrote:
Is even the following example from the library report (section 11.8.2)
problematic?
import System
import Char( toUpper )
main = do
[f1,f2] - getArgs
s - readFile f1
writeFile f2 (map toUpper s)
Simon Marlow wrote:
Simon Marlow:
[Lazy I/O] is nice, but it introduces too many problems. What
happens to any I/O errors encountered by the lazy I/O?
They have to
be discarded, which means you can't effectively use lazy I/O for
robust applications anyway.
Surely
I am reading the article template meta-programming for haskell and am
wondering if
1) this is already implemented in ghc.
2) if not when this will be released
answered in section 2.1 (GHC) and 3.6.1 (Template Haskell) of the
Haskell Communities Activities Report (November 2002 edition):
Francis Girard wrote:
You caught my attention.
It would be nice if you write your own version from scratch to make all of us
profit of this.
I have a confession to make. Andrew Bromage's list-based code is much faster than my
array-based code. So I think I shall end up adapting Andrew
Previous methods have generally identified the location of a type
error as a particular program point or the program subtree rooted at
that point. In the paper Type Error Slicing in Implicitly Typed
Higher-Order Languages by two of us (Haack and Wells), we present a
new approach that treats the
On Sun, 24 Nov 2002 22:50:43 +0100, Nick Name [EMAIL PROTECTED] wrote:
On Sun, 24 Nov 2002 20:42:31 +
Glynn Clements [EMAIL PROTECTED] wrote:
Even if Haskell were strict, you still wouldn't be able to treat I/O
operations as functions without discarding referential transparency.
Yes, but
Please tell me when it recognises [] as the empty list and :: as a list
constructor.
Thanks!
Greg
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Please give some examples.
It doesn't like ; at the end but says EOF when ; is missed.
It doesn't show the examples when I select them.
Greg
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Mark P Jones wrote:
Moreover,
in attempting to optimize the code, you might instead break it
and introduce some bugs that will eventually come back and bite.
Indeed! If we take Mark Phillips's original version of penultimax as our
specification, all four alternate versions are incorrect:
On Sun, Nov 24, 2002 at 10:06:42PM -0800, Mark P Jones wrote:
To your three implementations, let me add another two. If you are
looking
for the smallest possible definition, consider the following:
import List
penultimax1 :: Ord a = [a] - a
penultimax1 = head . tail . sortBy
Some quick tests with Hugs +s on a example list that I constructed
with 576 elements give food for thought:
reductions cells
my one liner 403511483
tournament705312288
your penultimax 1671520180
your
G'day all.
On Mon, Nov 25, 2002 at 12:19:10PM +0100, George Russell wrote:
I have a confession to make. Andrew Bromage's list-based code is
much faster than my array-based code. So I think I shall end up
adapting Andrew Bromage's code, even though I do not understand it.
You mean you did
Thanks for your alternative solutions. (I also take
Mark Jones' point that there was an error with some of my
initial solutions.)
On Mon, 2002-11-25 at 16:36, Mark P Jones wrote:
To your three implementations, let me add another two. If you are
looking
for the smallest possible definition,
The latest Chamleon release includes a compiler. Chameleon programs
are translated into plain Haskell (= Hindley/Milner subset plus
polymorphic recursion).
Note that Chameleon comes also with a type debugger.
Check out
http://www.comp.nus.edu.sg/~sulzmann/chameleon/
for the latest release
On Tue, 2002-11-26 at 02:38, Richard Braakman wrote:
penultimax1' :: Ord a = [a] - a
penultimax1' = head . tail . sortBy (flip compare) . nub
What does nub stand for? (This is the first I've heard of it.)
From the definition in List.hs it seems to remove repeats, keeping
only the first. Is
Hi,
(maybe I got the message to the community this time, Mark P ;-)
I would like to know if anyone (maybe Mark P) knows the status of
Cartesian classes in different Haskell implementations. I.e., does
anyone implement the suggested functional dependencies or the less
general parameterized type
What does nub stand for? (This is the first I've heard of it.)
From the definition in List.hs it seems to remove repeats, keeping
only the first.
Yes, that's what it does. It doesn't stand for anything, it's a word:
nub: small knob or lump, esp. of coal; small residue, stub; point or gist
29 matches
Mail list logo
