ghc-4.04 pathch level 1 understands
module T () where f x = 'a'
as module T exporting f.
Probably, it confuses this withmodule Twhere f x = 'a'
?
--
Sergey Mechveliani
[EMAIL PROTECTED]
I tried to compile the following program with both ghc-3.02
and ghc-4.02
(pathlevel 1), using the linux glibc binary releases. The
3.02 one works
fine but the code produced by 4.02 segmentation faults when I
try to run
I can't repeat this one - the program compiles fine and pops up
Sven Panne [EMAIL PROTECTED] writes:
...
* hClose on a semi-closed handle fails (4.02 has this bug, too):
import IO
main = do
h - openFile "/etc/passwd" ReadMode
c - hGetContents h
putStr c
hClose h
Transcript:
And the Simon's warning is for remembering that the effect is about as
if one sets these instances manually.
Do i understand correct?
My point was merely that it's easy to forget how much code is needed for an
instance of Show or Read, since it's easy (too easy :-) to stick 'deriving
Show'
On 21-Feb-1999, Lennart Augustsson [EMAIL PROTECTED] wrote:
(i.e., you leave out the pivot [x])
Obviously the result of sort will no longer be a permutation of its
argument. Will this then not type check?
No, the proof (whereever it is) would no longer type check.
As I understand
On 21-Feb-1999, Lennart Augustsson [EMAIL PROTECTED] wrote:
F a * = member (map (F a) [0..]) // member [a] a - Bool
I mave no clue what this means. What is `member'?
Member is memq, in, etc. Checks for membership in a list.
I'm still lost. What is // and how does it bind?
I
If you return the same proof of correctness that you used
for the earlier definition of sort, then no it won't type check.
But if you return a proof defined as e.g.
proof = proof
then if I understand things correctly it will type check.
On that note, since this has been of
No, the proof (whereever it is) would no longer type check.
As I understand it, this is not necessarily true:
if the proof contains loops, it might type check,
even though it is not really a valid proof.
You're right. If the proof is looping it will still
pass as a proof.
--
apply :: (F a *) [a] - (F a *)
apply f [] = a
apply f [a:as] = apply (f a) as
The type gets noisier.
(To correct a couple of minor typos, that should be
apply f [] = f
apply f (a:as) = apply (f a) as
)
Heh, thank you. :)
I agree it is in some sense six of one and
I consider even the second one to be mixing the proofs
with the code, because there's no easy way that I can tell at
a glance that `sortReallySorts' is a proof rather than a program.
But I consider that a feature and not a bug. :-)
-- Lennart
[EMAIL PROTECTED] wrote:
enabling types to express all properties you want is, IMO, the right way.
Why do I feel that there must be another approach to programming?
How many people do you expect to program in Haskell once you are done adding all
it takes to "express all imaginable
What is the general consensus on views and the extended pattern guards that
are discussed at
http://www.haskell.org/development/ ?
I think views are really neat, but am not quite sure how I feel about
pattern guards.
...I thought about this pretty hard. Particularly I thought about using
classes; this was fruitless. So I decided I'd invent a new language feature
and a nice little syntax to handle it.
Sorted l r = Ordered r /\ Permutation l r
sort :: (l :: [a]) - (r :: [a]) = Sorted l r
You've
On 20-Feb-1999, Nick Kallen [EMAIL PROTECTED] wrote:
[Lennart wrote:]
[Nick Kallen wrote:]
To what
extent will a program that type checks completely fail to follow its
specification? Can someone give specific examples?
It's trivial to construct examples. Take sorting
sort ::
14 matches
Mail list logo
