Re: [GHC] #639: Give civilised error messages when desugaring Template Haskell brackets
#639: Give civilised error messages when desugaring Template Haskell brackets +--- Reporter: [EMAIL PROTECTED] | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Template Haskell |Version: 6.4.1 Severity: normal | Resolution: Keywords: | Os: Unknown Difficulty: Easy (1 hr)| Architecture: Unknown +--- Changes (by simonmar): * component: Compiler = Template Haskell -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/639 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #651: Template Haskell doesn't work with profiling
#651: Template Haskell doesn't work with profiling ---+ Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: Component: Template Haskell |Version: 6.4.1 Severity: major | Resolution: Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonmar): * priority: normal = high -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/651 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug documentation [was: Re: problem compiling with profiling]
Frederik Eaton wrote: Template Haskell doesn't work with profiling, I'm afraid (for the same reason that you can't load profiled object code into GHCi). I thought we had an open bug on this, but I couldn't find one, so I just created one: http://cvs.haskell.org/trac/ghc/ticket/651 Writing a large program which relies on some library or some feature of ghc that is expected to be stable, or at least to not conflict with other features; and then finding out after considerable effort has been spent that there is some catch which prevents my program from being as useful as anticipated, or even useful at all - this is a frustrating experience that I've had several times now. I think it might be reasonable to expect the ghc documentation to contain better and more up-to-date information about what is and what isn't currently supported, so that users can avoid wasting their time as I have. As grateful as I am for the work that is being carried on here, sometimes I would like to be able to see projects through to completion without becoming involved in the ghc development process. Furthermore, it seems that better documentation of open bugs could also be of use to people who *do* want to become involved... I hear your frustration, and I sympathise. I've updated the known bugs section on the template haskell wiki to be more useful: http://www.haskell.org/hawiki/TemplateHaskell, and I've bumped the priority of the TH/profiling bug. You want an easy way to find out what works and what doesn't, which is quite reasonable. This is something we should try to improve. The current situation is: - long term defects are described in the User's Guide, in the Known bugs and infelicities section: http://www.haskell.org/ghc/docs/latest/html/users_guide/bugs-and-infelicities.html - all other bugs that we know about are either: * in the bug tracker, or * on this mailing list, or * in someone's head. It would be a huge improvement if we could put all these in one place. So from now on we'll try to record a ticket for every bug, even if we fix it immediately. Unfortunately there isn't a way to query for all the bugs, open or closed against version 6.4.1, or open against an older verison. We could update the version of every open bug at each release, I suppose. For now, this query gets you all the bugs in 6.4.1, open or closed: http://cvs.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedstatus=closedversion=6.4.1order=priority Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #179: Instance match failure on openTypeKind
#179: Instance match failure on openTypeKind
--+-
Reporter: simonpj | Owner: simonpj
Type: bug | Status: assigned
Priority: normal | Milestone:
Component: Compiler (Type checker) |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
--+-
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
Consider
instance Show (a-b) where ...
foo x = show (\ _ - True)
This fails with:
No instance for (Show (t - Bool))
arising from use of `show' at Foo.hs:5
Reason: the type of (\_ - True) is (t - Bool) where
t has an openTypeKind. It's possible that the function
will be applied to say an Int#, and the openTypeKind
records that this is OK.
BUT, the instance decl Show (a-b) has
a::liftedTypeKind, and that doesn't match an
openTypeKind type variable.
This bug relates to GHC's unsatisfactory treatment of
the variants of kind type, for which there are at least 2
other SourceForge bugs registered (753780 and
753777). It's very obscure, so I'm not going to fix it
today.
}}}
New description:
{{{
Consider
instance Show (a-b) where ...
foo x = show (\ _ - True)
This fails with:
No instance for (Show (t - Bool))
arising from use of `show' at Foo.hs:5
Reason: the type of (\_ - True) is (t - Bool) where
t has an openTypeKind. It's possible that the function
will be applied to say an Int#, and the openTypeKind
records that this is OK.
BUT, the instance decl Show (a-b) has
a::liftedTypeKind, and that doesn't match an
openTypeKind type variable.
This bug relates to GHC's unsatisfactory treatment of
the variants of kind type, for which there are at least 2
other SourceForge bugs registered (753780 and
753777). It's very obscure, so I'm not going to fix it
today.
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/179
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #476: HUnit treats failures as errors
#476: HUnit treats failures as errors
+---
Reporter: stefanheimann | Owner: nobody
Type: bug| Status: assigned
Priority: normal | Milestone:
Component: libraries (other) |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown| Architecture: Unknown
+---
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
}}}
New description:
{{{
HUnit treats a failure in a testcase as an error. I
attached a patch that fixes the problem. I tested the
patch with ghc and hugs.
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/476
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #482: 'Bug' when installing GHC 6.4.1
#482: 'Bug' when installing GHC 6.4.1 ---+ Reporter: nobody| Owner: wolfgang Type: bug | Status: assigned Priority: normal| Milestone: Component: Build System |Version: 6.4.1 Severity: normal| Resolution: None Keywords:| Os: MacOS X Difficulty: Unknown | Architecture: powerpc ---+ Changes (by simonmar): * difficulty: = Unknown * version: None = 6.4.1 -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/482 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #485: AdjustorAsm.S doesn't build on AIX
#485: AdjustorAsm.S doesn't build on AIX ---+ Reporter: jgoerzen | Owner: nobody Type: bug | Status: assigned Priority: normal| Milestone: Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: None Keywords:| Os: AIX Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonmar): * difficulty: = Unknown * version: None = 6.4.1 -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/485 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #487: powerpc/linux segfaulting binaries
#487: powerpc/linux segfaulting binaries ---+ Reporter: dons | Owner: nobody Type: bug | Status: assigned Priority: normal| Milestone: Component: Compiler |Version: 6.4.1 Severity: normal| Resolution: None Keywords:| Os: Linux Difficulty: Unknown | Architecture: powerpc ---+ Changes (by simonmar): * difficulty: = Unknown * version: None = 6.4.1 -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/487 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #246: Wrong pat-match order for records
#246: Wrong pat-match order for records ---+ Reporter: simonpj | Owner: simonpj Type: bug | Status: assigned Priority: low | Milestone: Component: Compiler |Version: 6.4.1 Severity: minor | Resolution: None Keywords:| Os: Unknown Difficulty: Unknown | Architecture: Unknown ---+ Changes (by simonmar): * difficulty: = Unknown * version: None = 6.4.1 -- Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/246 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #312: Poor error message for kind error
#312: Poor error message for kind error
--+-
Reporter: simonpj | Owner: simonpj
Type: bug | Status: assigned
Priority: low | Milestone:
Component: Compiler (Type checker) |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
--+-
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
A kind error can lead to the following poor error msg:
tcfail132.hs:30:51:
Kind error: Expecting kind `k_a18s - k_a18w -
k_a18A - *',
but `DUnit t' has kind `k_a18s -
k_a18w - *'
In the type synonym declaration for `LiftObject'
The source program is
newtype Object f' f t o1 o2 = Object (f' t o1 - f t o2)
type DUnit t o1 o2 = ()
type T f g t o1 o2 = Either (f t o1 o2) (g t o1 o2)
type LiftObject t f' f = T (Object f' f t) (DUnit t)
}}}
New description:
{{{
A kind error can lead to the following poor error msg:
tcfail132.hs:30:51:
Kind error: Expecting kind `k_a18s - k_a18w -
k_a18A - *',
but `DUnit t' has kind `k_a18s -
k_a18w - *'
In the type synonym declaration for `LiftObject'
The source program is
newtype Object f' f t o1 o2 = Object (f' t o1 - f t o2)
type DUnit t o1 o2 = ()
type T f g t o1 o2 = Either (f t o1 o2) (g t o1 o2)
type LiftObject t f' f = T (Object f' f t) (DUnit t)
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/312
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #323: Exponential behaviour with type synonyms
#323: Exponential behaviour with type synonyms
--+-
Reporter: simonpj | Owner: simonpj
Type: bug | Status: assigned
Priority: low | Milestone:
Component: Compiler (Type checker) |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
--+-
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
You're quite right. GHC has a simple but non-
performant representation of type synonyms in types, so
as to be able to generate good error messages, In
particular, the type
S t
where S is a type synonym defined by 'type S a = s', is
represented as
SynNote (S t) (s [t/a])
That is, (S t) is represented by *both* its un-expanded
and expanded form.
The SynNote is ignored by unification, but the un-
expanded form is useful for error messages.
Unfortunately, t is duplicated, as you can see, and that
leads to the behaviour you describe.
I don't see myself fixing this soon, at least partly
because I can't see an obvious way to fix it that doesn't
lose error message behaviour.
I'm going to open a SourceForge bug for it. If anyone
has good ideas, let me know.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Iavor Diatchki
| Sent: 17 February 2005 01:27
| To: glasgow-haskell-bugs@haskell.org
| Subject: 'type' declarations
|
| hello,
| ghc seems to be having trouble with 'type' declarations.
| while compiling (i guess kind checking is the correct
word here)
| the following program for a very long time, ghc (6.2)
runs out of 300Mb of heap.
|
| module Test where
|
| type S = Maybe
| type S2 n = S (S n)
| type S4 n = S2 (S2 n)
| type S8 n = S4 (S4 n)
| type S16 n = S8 (S8 n)
| type S32 n = S16 (S16 n)
|
| type N64 n = S32 (S32 n)
|
| type N64' =
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| Int
|
|
|
|
|
|
|
|
|
| if i remove the N64 definition things work. i guess
something
| exponential is happening
| (substitution?).
|
| -iavor
}}}
New description:
{{{
You're quite right. GHC has a simple but non-
performant representation of type synonyms in types, so
as to be able to generate good error messages, In
particular, the type
S t
where S is a type synonym defined by 'type S a = s', is
represented as
SynNote (S t) (s [t/a])
That is, (S t) is represented by *both* its un-expanded
and expanded form.
The SynNote is ignored by unification, but the un-
expanded form is useful for error messages.
Unfortunately, t is duplicated, as you can see, and that
leads to the behaviour you describe.
I don't see myself fixing this soon, at least partly
because I can't see an obvious way to fix it that doesn't
lose error message behaviour.
I'm going to open a SourceForge bug for it. If anyone
has good ideas, let me know.
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:glasgow-haskell-bugs-
| [EMAIL PROTECTED] On Behalf Of Iavor Diatchki
| Sent: 17 February 2005 01:27
| To: glasgow-haskell-bugs@haskell.org
| Subject: 'type' declarations
|
| hello,
| ghc seems to be having trouble with 'type' declarations.
| while compiling (i guess kind checking is the correct
word here)
| the following program for a very long time, ghc (6.2)
runs out of 300Mb of heap.
|
| module Test where
|
| type S = Maybe
| type S2 n = S (S n)
| type S4 n = S2 (S2 n)
| type S8 n = S4 (S4 n)
| type S16 n = S8 (S8 n)
| type S32 n = S16 (S16 n)
|
| type N64 n = S32 (S32 n)
|
| type N64' =
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| S ( S ( S ( S ( S ( S ( S ( S (
| Int
|
|
|
|
|
|
|
|
|
| if i remove the N64 definition things work. i guess
something
| exponential
Re: [GHC] #427: Random.StdGen slowness
#427: Random.StdGen slowness
-+--
Reporter: remit | Owner: nobody
Type: bug | Status: assigned
Priority: low | Milestone:
Component: libraries/base |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
-+--
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe random _crandom :: IO Int
randomInt :: (Int, Int) - IO Int
randomInt (min,max) = do
n - _crandom
return $ min + n `rem` range
where
range = max - min + 1
main = replicateM_ (5*10^6) $ do
x - randomRIO (0::Int,1000) :: IO Int
x `seq` return ()
return ()
First, without the seq at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
Does help in this example, but also changes behaviour
of the library:
x - randomRIO undefined
currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.
Second, even _with_ the seq, replacing randomRIO by
randomInt speeds the thing up with a factor of about
30. (2 to 3.6, in a real world university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
}}}
New description:
{{{
Two (performance) problems in one:
{-# OPTIONS -fffi #-}
module Main (main) where
import Control.Monad
import Random
foreign import ccall unsafe random _crandom :: IO Int
randomInt :: (Int, Int) - IO Int
randomInt (min,max) = do
n - _crandom
return $ min + n `rem` range
where
range = max - min + 1
main = replicateM_ (5*10^6) $ do
x - randomRIO (0::Int,1000) :: IO Int
x `seq` return ()
return ()
First, without the seq at the end, hardly anything is
evaluated and we're building huge amounts of thunks.
Three ideas about this one:
- Blame the user :)
- data StdGen = StdGen !Int !Int
Use strict fields in StdGen. Doesn't actually help
(at least in this example).
- Force evaluation of the StdGen in getStdRandom.
Does help in this example, but also changes behaviour
of the library:
x - randomRIO undefined
currently dies only when x (or the result of a later
randomRIO) is evaluated. This change causes it to die
immediately.
Second, even _with_ the seq, replacing randomRIO by
randomInt speeds the thing up with a factor of about
30. (2 to 3.6, in a real world university practicum
exercise of 900 lines of code)
Even given the fact that they're not really doing the
same thing, this seems rather much :(
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/427
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #481: Recompilation check fails for TH
#481: Recompilation check fails for TH
---+
Reporter: simonpj | Owner: simonpj
Type: bug | Status: assigned
Priority: low | Milestone:
Component: Template Haskell |Version: 6.4.1
Severity: normal| Resolution: None
Keywords:| Os: Unknown
Difficulty: Unknown | Architecture: Unknown
---+
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
The recompilation check only recompiles a module when
the *interface* of a module it imports changes. But
with Template Haskell, it may need to be recompiled
when the *implementation* changes.
Concrete example below. It's quite awkward to fix.
* Perhaps a module that contains any splices should be
recompiled always.
* Perhaps a module that exports any TH stuff (how
would we tell?) should be flagged as changed if
anything about it changes.
Simon
The following scenario reproduces this error
(thanks to Bulat Ziganshin [EMAIL PROTECTED]):
1) create Main.hs containing code
module Main where
import Sub
main = print $x
and Sub.hs containing code
module Sub where
x = [| 1 |]
2) compile them with --make:
C:\!\Haskell\!ghc --make -fth Main.hs
Chasing modules from: Main.hs
Compiling Sub ( ./Sub.hs, ./Sub.o )
Compiling Main ( Main.hs, Main.o )
Loading package base-1.0 ... linking ... done.
Loading package haskell98-1.0 ... linking ... done.
Loading package template-haskell-1.0 ... linking ...
done.
Linking ...
C:\!\Haskell\!main.exe
1
3) now change Sub.hs to the following code:
module Sub where
x = [| 2 |]
4) and recompile program:
C:\!\Haskell\!ghc --make -fth Main.hs
Chasing modules from: Main.hs
Compiling Sub ( ./Sub.hs, ./Sub.o )
Skipping Main ( Main.hs, Main.o )
Linking ...
C:\!\Haskell\!main.exe
1
As you see, Main.hs is not recompiled despite the fact
that definition
of x is changed and now program must print 2
}}}
New description:
{{{
The recompilation check only recompiles a module when
the *interface* of a module it imports changes. But
with Template Haskell, it may need to be recompiled
when the *implementation* changes.
Concrete example below. It's quite awkward to fix.
* Perhaps a module that contains any splices should be
recompiled always.
* Perhaps a module that exports any TH stuff (how
would we tell?) should be flagged as changed if
anything about it changes.
Simon
The following scenario reproduces this error
(thanks to Bulat Ziganshin [EMAIL PROTECTED]):
1) create Main.hs containing code
module Main where
import Sub
main = print $x
and Sub.hs containing code
module Sub where
x = [| 1 |]
2) compile them with --make:
C:\!\Haskell\!ghc --make -fth Main.hs
Chasing modules from: Main.hs
Compiling Sub ( ./Sub.hs, ./Sub.o )
Compiling Main ( Main.hs, Main.o )
Loading package base-1.0 ... linking ... done.
Loading package haskell98-1.0 ... linking ... done.
Loading package template-haskell-1.0 ... linking ...
done.
Linking ...
C:\!\Haskell\!main.exe
1
3) now change Sub.hs to the following code:
module Sub where
x = [| 2 |]
4) and recompile program:
C:\!\Haskell\!ghc --make -fth Main.hs
Chasing modules from: Main.hs
Compiling Sub ( ./Sub.hs, ./Sub.o )
Skipping Main ( Main.hs, Main.o )
Linking ...
C:\!\Haskell\!main.exe
1
As you see, Main.hs is not recompiled despite the fact
that definition
of x is changed and now program must print 2
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/481
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #229: Integer overflow in array allocation
#229: Integer overflow in array allocation
-+--
Reporter: josefs | Owner: simonmar
Type: bug | Status: assigned
Priority: lowest | Milestone:
Component: libraries/base |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
-+--
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
When asked to create a sufficiently large array ghci
coredumps.
\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base
example = runST (do arr - newArray (minInt,maxInt)
False
go arr)
where go :: STArray s Int Bool - ST s Bool
go arr = readArray arr 3
\end{code}
Load this into ghci and type 'example'.
}}}
New description:
{{{
When asked to create a sufficiently large array ghci
coredumps.
\begin{code}
import Data.Array.ST
import Control.Monad.ST
import GHC.Base
example = runST (do arr - newArray (minInt,maxInt)
False
go arr)
where go :: STArray s Int Bool - ST s Bool
go arr = readArray arr 3
\end{code}
Load this into ghci and type 'example'.
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/229
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #386: :i wrongly claims Imported from ...
#386: :i wrongly claims Imported from ...
--+-
Reporter: pimlott | Owner: nobody
Type: bug | Status: assigned
Priority: lowest | Milestone:
Component: GHCi |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
--+-
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
Mostly cosmetic mix-up:
Prelude :m GHC.Exception
Prelude GHC.Exception :i System.IO.Error.catch
catch :: IO a - (IOError - IO a) - IO a
-- Imported from GHC.Exception
The catch described is not the same on as imported from
GHC.Exception.
}}}
New description:
{{{
Mostly cosmetic mix-up:
Prelude :m GHC.Exception
Prelude GHC.Exception :i System.IO.Error.catch
catch :: IO a - (IOError - IO a) - IO a
-- Imported from GHC.Exception
The catch described is not the same on as imported from
GHC.Exception.
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/386
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #418: unsafeInterleaveIO + Ctrl-C/killThread related segfault
#418: unsafeInterleaveIO + Ctrl-C/killThread related segfault
-+--
Reporter: remit | Owner: nobody
Type: bug | Status: assigned
Priority: lowest | Milestone:
Component: Runtime System |Version: 6.4.1
Severity: normal | Resolution: None
Keywords: | Os: Unknown
Difficulty: Unknown | Architecture: Unknown
-+--
Changes (by simonmar):
* architecture: = Unknown
* difficulty: = Unknown
* version: None = 6.4.1
* os: = Unknown
Old description:
{{{
[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-
June/005235.html)]
Good evening,
I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)
module Main where
import Control.Concurrent
import System.IO.Unsafe (unsafeInterleaveIO)
main = do
v - newEmptyMVar
a - unsafeInterleaveIO (readMVar v)
t - forkIO (print a)
threadDelay (1000*1000)
killThread t
forkIO (print a)
putMVar v ()
The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first print a
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:
Prelude System.IO.Unsafe Control.Concurrent v -
newEmptyMVar
Prelude System.IO.Unsafe Control.Concurrent a -
unsafeInterleaveIO (readMVar v)
Prelude System.IO.Unsafe Control.Concurrent print a
Interrupted.
Prelude System.IO.Unsafe Control.Concurrent forkIO
(print a)
Prelude System.IO.Unsafe Control.Concurrent putMVar v ()
zsh: segmentation fault (core dumped) ghci
Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.
Although I'm pretty sure I've seen 6.2.1 crashing
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)
Whether the module is compiled before being loaded into
ghci has
no effect.
Core-dumps etc can of course be sent if necessary.
Good night,
Remi
}}}
New description:
{{{
[copy-pasting my original mail
(http://www.haskell.org/pipermail/glasgow-haskell-bugs/2005-
June/005235.html)]
Good evening,
I just stumbled across a segfault caused when running the
following small program. (During an attempt to implement
single-assignment variables.)
module Main where
import Control.Concurrent
import System.IO.Unsafe (unsafeInterleaveIO)
main = do
v - newEmptyMVar
a - unsafeInterleaveIO (readMVar v)
t - forkIO (print a)
threadDelay (1000*1000)
killThread t
forkIO (print a)
putMVar v ()
The crucial part about it seems to be the interruption
of the
lazy IO. Typing Ctl-c while running the first print a
by hand
from ghci instead of the forkIO+killThread doesn't change
behaviour:
Prelude System.IO.Unsafe Control.Concurrent v -
newEmptyMVar
Prelude System.IO.Unsafe Control.Concurrent a -
unsafeInterleaveIO (readMVar v)
Prelude System.IO.Unsafe Control.Concurrent print a
Interrupted.
Prelude System.IO.Unsafe Control.Concurrent forkIO
(print a)
Prelude System.IO.Unsafe Control.Concurrent putMVar v ()
zsh: segmentation fault (core dumped) ghci
Both 6.4 and 6.2.1 crash when running main from ghci.
When running it as a compiled executable everything is
fine.
Although I'm pretty sure I've seen 6.2.1 crashing
on it when run with -e main, I cannot reproduce it
anymore. 6.4
certainly happily runs it with -e main. (A serious lack
of sleep
the last week may play a role too.. :-/)
Whether the module is compiled before being loaded into
ghci has
no effect.
Core-dumps etc can of course be sent if necessary.
Good night,
Remi
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/418
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: bug documentation [was: Re: problem compiling with profiling]
Simon Marlow wrote: For now, this query gets you all the bugs in 6.4.1, open or closed: http://cvs.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedstatus=closedversion=6.4.1order=priority A slightly better URL: http://cvs.haskell.org/trac/ghc/query?status=newstatus=assignedstatus=reopenedstatus=closedversion=6.4.1type=bugorder=priority Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #652: Have a single Data.Typeable hash table in GHCi
#652: Have a single Data.Typeable hash table in GHCi
---+
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal| Milestone: 6.6
Component: Runtime System|Version: 6.4.1
Severity: normal| Resolution:
Keywords:| Os: Unknown
Difficulty: Moderate (1 day) | Architecture: Unknown
---+
Old description:
The hash table used by Data.Typeable is declared as a top-level IORef.
This means in GHCi, there will be two Data.Typeable hash tables: one in
the dynamically-loaded base package, and one in the statically-linked
GHCi binary. Therefore Dyanmics created in one world are incompatible
with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack
we could different TypeReps bogusly claiming to be equal). However, we
would like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a TypeRep compares equal,
we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr (StablePtr?) to the hash table in an RTS global, so
that there is only one per runtime instance.
New description:
The hash table used by {{{Data.Typeable}}} is declared as a top-level
IORef. This means in GHCi, there will be two {{{Data.Typeable}}} hash
tables: one in the dynamically-loaded base package, and one in the
statically-linked GHCi binary. Therefore Dyanmics created in one world
are incompatible with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack we
could different TypeReps bogusly claiming to be equal). However, we would
like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a {{{TypeRep}}} compares
equal, we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
global, so that there is only one per runtime instance.
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/652
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #652: Have a single Data.Typeable hash table in GHCi
#652: Have a single Data.Typeable hash table in GHCi
---+
Reporter: simonmar | Owner:
Type: task | Status: new
Priority: normal| Milestone: 6.6
Component: Runtime System|Version: 6.4.1
Severity: normal| Resolution:
Keywords:| Os: Unknown
Difficulty: Moderate (1 day) | Architecture: Unknown
---+
Old description:
The hash table used by {{{Data.Typeable}}} is declared as a top-level
IORef. This means in GHCi, there will be two {{{Data.Typeable}}} hash
tables: one in the dynamically-loaded base package, and one in the
statically-linked GHCi binary. Therefore Dyanmics created in one world
are incompatible with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack
we could different TypeReps bogusly claiming to be equal). However, we
would like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a {{{TypeRep}}} compares
equal, we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
global, so that there is only one per runtime instance.
New description:
The hash table used by {{{Data.Typeable}}} is declared as a top-level
IORef. This means in GHCi, there will be two {{{Data.Typeable}}} hash
tables: one in the dynamically-loaded base package, and one in the
statically-linked GHCi binary. Therefore Dyanmics created in one world
are incompatible with the other world.
We have a hack to make sure the two hash tables don't use the same
uniques, so at least a {{{TypeRep}}} created in one world will ''never''
compare equal to a {{{TypeRep}}} from the other world (before this hack we
could different {{{TypeRep}}}s bogusly claiming to be equal). However, we
would like them to compare equal when they are equal.
This implies that the packages in use in both world must be compatible
(preferably identical). This is because when a {{{TypeRep}}} compares
equal, we must be sure that the value has the representation we expect.
Fortunately this is the case in a stage2 GHC.
We should store a ptr ({{{StablePtr}}}?) to the hash table in an RTS
global, so that there is only one per runtime instance.
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/652
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #637: Ctrl-Break handler doesn't work in forked threads in -threaded RTS
#637: Ctrl-Break handler doesn't work in forked threads in -threaded RTS
+---
Reporter: [EMAIL PROTECTED] | Owner:
Type: bug| Status: new
Priority: normal | Milestone:
Component: Runtime System |Version: 6.4.1
Severity: normal | Resolution:
Keywords: | Os: Unknown
Difficulty: Unknown| Architecture: Unknown
+---
Comment (by guest):
The following program demonstrates bug in 6.4.1 (6.4.0 was ok).
if you compile it with -threaded, run and press Ctrl-Break, you will
see message main.EXE: stdin: hGetLine: end of file and program
blocks (because forked thread is dead). the problem is that installed
ctrl-break handler don't called in forked threads
if you compile program without -threaded or with 6.4.0, it works as
expected - pressing Ctrl-Break runs my handler so you will see
^Break! main.EXE: thread killed message
{{{
import Control.Concurrent
import Control.Exception
import GHC.ConsoleHandler
handleCtrlBreak action = do
myThread - myThreadId
let onBreak event = do
putStrLn ^Break!
killThread myThread
bracket (installHandler$ Catch onBreak) (installHandler) $ \oldHandler
- do
action
main = do
handleCtrlBreak $ do
x - newEmptyMVar
forkIO$ do a - getLine
print a
putMVar x ()
return ()
takeMVar x
return ()
}}}
--
Ticket URL: http://cvs.haskell.org/trac/ghc/ticket/637
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #653: Changeable lexer/parser (like DynFlags.log_action)
#653: Changeable lexer/parser (like DynFlags.log_action) +--- Reporter: Lemmih |Owner: Type: feature request | Status: new Priority: low |Milestone: 6.6 Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: Os: Multiple | Difficulty: Moderate (1 day) Architecture: Multiple | +--- It would be very convenient for projects such as 'Haskell Server Pages' if the GHC library allowed the user to supply his own lexer and parser. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/653 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #654: Cabalization of the GHC library.
#654: Cabalization of the GHC library. +--- Reporter: Lemmih |Owner: Type: feature request | Status: new Priority: normal |Milestone: 6.6 Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: Os: Multiple | Difficulty: Moderate (1 day) Architecture: Multiple | +--- Rebuilding the GHC library when, say, a new version of Cabal is install, is not very convenient. Even harder is it to build with profiling enabled. Cabalizing the library would be an ideal solution, although I'm not sure how it'll work with the rest of the build-system. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/654 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #654: Cabalization of the GHC library.
#654: Cabalization of the GHC library. ---+ Reporter: Lemmih| Owner: Type: feature request | Status: new Priority: normal| Milestone: 6.6 Component: Build System |Version: 6.4.1 Severity: normal| Resolution: Keywords:| Os: Multiple Difficulty: Moderate (1 day) | Architecture: Multiple ---+ Changes (by Lemmih): * component: Compiler = Build System -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/654 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[GHC] #655: Loading the GHC library from GHCi.
#655: Loading the GHC library from GHCi. +--- Reporter: Lemmih |Owner: Type: feature request | Status: new Priority: normal |Milestone: 6.6 Component: Compiler | Version: 6.4.1 Severity: normal | Keywords: Os: Multiple | Difficulty: Moderate (1 day) Architecture: Multiple | +--- The GHC library exports some symbols which should probably be kept in the GHC binary (see $fptools/ghc/compiler/parser/hschooks.c) and it uses other symbols which aren't exported at all. Loading the library dynamically is essential for hIDE (http://haskell.org/hawiki/hIDE). -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/655 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: darcs switchover
John Goerzen wrote: On 2006-01-11, John Goerzen [EMAIL PROTECTED] wrote: I've talked to Simon about this, and here's what we've agreed I will do: * I will re-convert all of the top-level directories in the current libraries darcs repo, except for: doc, mk, and Cabal * Each new repo will be under darcs.haskell.org/packages * I will convert HEAD only and not the ghc-6.4 branch. Simon plans to continue using CVS for ghc-6.4 anyway. These steps are now done. See all the new repos under http://darcs.haskell.org/packages. libraries and libraries.ghc-6.4 are now gone. And GHC is now usable from the new darcs setup. I've updated the instructions on the wiki: http://cvs.haskell.org/trac/ghc/wiki/GhcDarcs All of the packages are sync'd from CVS except for Cabal - it seemed more sensible to use the existing Cabal repo directly. However I've taken a branch of that Cabal repo to add the fptools Makefiles for now; the branch is in http://darcs.haskell.org/packages/Cabal. I added a script darcs-all at the top-level of the ghc tree which automates invoking darcs on the various sub-repos. To get a whole tree, do this: $ darcs get --partial http://darcs.haskell.org/ghc $ cd ghc $ chmod +x ./darcs-all $ ./darcs-all get and to pull new changes: $ ./darcs-all pull Please test, as we'd like to switch over as soon as possible. Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] State Monad
Hello, Can somebody point me out the exact CVS location of the State Monad implementation that ships with GHC? I am a bit lost in the CVS directory structure ... Related to this, I saw the following thread: http://www.mail-archive.com/haskell@haskell.org/msg17702.html Which seems to hint that there are 2 alternative implementations for the State Monad: one lazy version and one more strict version. Is this correct? What I am really trying to find out is if the version that ships with GHC is the strict version. At least I am inclined to think that, since a program that I expected to terminate is not terminating ... Finally, if there are indeed two versions, can somebody write (or point me out) the two different implementations. Thanks, Bruno ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: State Monad
Bruno Oliveira wrote: Can somebody point me out the exact CVS location of the State Monad implementation that ships with GHC? I am a bit lost in the CVS directory structure ... fptools/libraries/mtl/Control/Monad/State.hs Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: State Monad
Christian Maeder [EMAIL PROTECTED] writes: Bruno Oliveira wrote: Can somebody point me out the exact CVS location of the State Monad implementation that ships with GHC? I am a bit lost in the CVS directory structure ... fptools/libraries/mtl/Control/Monad/State.hs Or rather fptools/libraries/base/Control/Monad/ST.hs fptools/libraries/base/Control/Monad/ST/Strict.hs fptools/libraries/base/Control/Monad/ST/Lazy.hs Regards, Malcolm ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Looking for a random-access sequence data structure
Hi all, I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a - Int - Maybe a insert :: Sequence a - Int - a - Sequence a delete :: Sequence a - Int - Sequence a Obviously I can implement this with ordinary lists in O(n) time for each operation. It seems that this could be done in O(log n) time for each operation. This seems like a fairly common collection signature to want but to my surprise I've not been able to find any existing implementations that support it. There are several that have almost all the necessary operations. For example the Data.Map supports all of these except insert. Okasaki's random access lists only support inserting elements at the head of the list. I'd guess that some kind of (balanced) binary search tree where each node is annotated with the number of nodes below it could support all these operations. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. [snip] For example the Data.Map supports all of these except insert. Okasaki's random access lists only support inserting elements at the head of the list. I think it's possible to give an O(log n) insert-operation of Okasaki's random access list, but I would expect it to be rather messy. I'd guess that some kind of (balanced) binary search tree where each node is annotated with the number of nodes below it could support all these operations. Yes, but you don't need to go that far. Braun trees should do fine. Stefan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On 1/13/06, Duncan Coutts [EMAIL PROTECTED] wrote: Hi all, I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a - Int - Maybe a insert :: Sequence a - Int - a - Sequence a delete :: Sequence a - Int - Sequence a Obviously I can implement this with ordinary lists in O(n) time for each operation. It seems that this could be done in O(log n) time for each operation. This seems like a fairly common collection signature to want but to my surprise I've not been able to find any existing implementations that support it. There are several that have almost all the necessary operations. For example the Data.Map supports all of these except insert. Okasaki's random access lists only support inserting elements at the head of the list. What's the semantics of insert? Does it replace an element, or does it shirt all the elements after it one step? /S -- Sebastian Sylvan +46(0)736-818655 UIN: 44640862 ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On Fri, Jan 13, 2006 at 01:18:35PM +, Duncan Coutts wrote: I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a - Int - Maybe a insert :: Sequence a - Int - a - Sequence a delete :: Sequence a - Int - Sequence a Have a look at Data.Sequence (in CVS/darcs version), docs at http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Sequence.html insert and delete aren't provided, but are easily derived: insert :: Seq a - Int - a - Seq a insert xs i x = front x | back where (front, back) = splitAt i xs delete :: Seq a - Int - Seq a delete xs i = front drop 1 back where (front, back) = splitAt i xs (where splitAt and drop are the sequence versions). Each of the three operations takes O(log(min(i,n-i))) time. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On Fri, 2006-01-13 at 14:41 +0100, Sebastian Sylvan wrote: On 1/13/06, Duncan Coutts [EMAIL PROTECTED] wrote: Hi all, I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a - Int - Maybe a insert :: Sequence a - Int - a - Sequence a delete :: Sequence a - Int - Sequence a What's the semantics of insert? Does it replace an element, or does it shirt all the elements after it one step? It shifts all the elements after it one step. So that's why all the finite map types are no help. Here's the semantics I want, in terms of an implementation using lists: -- for simplicity lets ignore the case of indexing out of range lookup :: Sequence a - Int - a lookup = (!!) insert :: Sequence a - Int - a - Sequence a insert seq i x = case splitAt i seq of (before, after) - before ++ x : after delete :: Sequence a - Int - Sequence a delete seq i = case splitAt i seq of (before, x : after) - before ++ after Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On Fri, 2006-01-13 at 13:53 +, Ross Paterson wrote: On Fri, Jan 13, 2006 at 01:18:35PM +, Duncan Coutts wrote: I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a - Int - Maybe a insert :: Sequence a - Int - a - Sequence a delete :: Sequence a - Int - Sequence a Have a look at Data.Sequence (in CVS/darcs version), docs at Ah, that's why I didn't find it! :-) http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Sequence.html insert and delete aren't provided, but are easily derived: insert :: Seq a - Int - a - Seq a insert xs i x = front x | back where (front, back) = splitAt i xs delete :: Seq a - Int - Seq a delete xs i = front drop 1 back where (front, back) = splitAt i xs (where splitAt and drop are the sequence versions). Each of the three operations takes O(log(min(i,n-i))) time. Thanks very much, that's great. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Looking for a random-access sequence data structure
Duncan Coutts wrote: What's the semantics of insert? Does it replace an element, or does it shirt all the elements after it one step? It shifts all the elements after it one step. So that's why all the finite map types are no help. import Data.Map as Map seqInsert i v = Map.insert i v . Map.mapKeysMonotonic (\ j - if j i then j else j + 1) ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Looking for a random-access sequence data structure
Christian Maeder wrote: seqInsert i v = Map.insert i v . Map.mapKeysMonotonic (\ j - if j i then j else j + 1) Sorry, only O(n) and not O(log n). The same would apply to delete. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Looking for a random-access sequence data structure
On Fri, 2006-01-13 at 15:21 +0100, Christian Maeder wrote: Duncan Coutts wrote: What's the semantics of insert? Does it replace an element, or does it shirt all the elements after it one step? It shifts all the elements after it one step. So that's why all the finite map types are no help. import Data.Map as Map seqInsert i v = Map.insert i v . Map.mapKeysMonotonic (\ j - if j i then j else j + 1) Ah, ok so it can be done, but it's linear rather than log time. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
Duncan Coutts wrote: I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. See also, Robert Will's Democratic Sequences which strive for O(log n) complexity for all major operations... Democratic Sequences: an Abstract Sequence Data Type which is not optimised for some algorithms (as Deques and many other implementations are), but which aims to provide a very simple and consistent interface for day-to-day programming and prototyping, where any sensible operation runs with acceptable performance, although possible none is optimal. ...unfortunately the write-up and code seems to have lost its home, so you'll have to get it from the Google cache ( http://xrl.us/jjs9 ). Greg Buchholz ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On Fri, 2006-01-13 at 13:53 +, Ross Paterson wrote: On Fri, Jan 13, 2006 at 01:18:35PM +, Duncan Coutts wrote: I've been looking around (unsuccessfully) for an efficient data structure to implement a sequence data type with indexed insert/delete/lookup. lookup :: Sequence a - Int - Maybe a insert :: Sequence a - Int - a - Sequence a delete :: Sequence a - Int - Sequence a Have a look at Data.Sequence (in CVS/darcs version), docs at http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Sequence.html And as a bonus the append and prepend operations are O(1), which is nice since for my application these are probably more likely than inserting at arbitrary indexes. It's probably too much to ask, but here's a question: would it be possible to provide an operation that gives a left or right view from looking up an index. Say: viewrFromIndex :: Seq a - Int - ViewL a viewlFromIndex :: Seq a - Int - ViewR a The library currently provides views for the each end of the sequence. viewl :: Seq a - ViewL a viewr :: Seq a - ViewR a I suppose this would be a zipper-like iterator for the sequence? I ask since a common use in my application will involve sequential access (though random access is still required). So if I cached an iterator/zipper/view thing to use in case the next lookup happens to be the next in the sequence then I could do that in O(1) time rather than doing an ordinary O(log n) lookup. Just wondering. :-) Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On Fri, Jan 13, 2006 at 08:25:46PM +, Duncan Coutts wrote: On Fri, 2006-01-13 at 13:53 +, Ross Paterson wrote: Have a look at Data.Sequence (in CVS/darcs version), docs at http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Sequence.html [...] It's probably too much to ask, but here's a question: would it be possible to provide an operation that gives a left or right view from looking up an index. Say: viewrFromIndex :: Seq a - Int - ViewL a viewlFromIndex :: Seq a - Int - ViewR a The library currently provides views for the each end of the sequence. viewl :: Seq a - ViewL a viewr :: Seq a - ViewR a I suppose this would be a zipper-like iterator for the sequence? I'm not entirely sure what these are intended to do, but can't you just compose view[lr] with take/drop? A zipper for a non-empty sequence is just an element and a pair of sequences. Moving it by k positions using splitAt and () costs O(log(k+1)). ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: ANN: HDBC (Haskell Database Connectivity)
Yes, I see... I edited it from the source code, which actually has the type:
dbConnectWith :: VerifyTables t = (SqlHandle () - IO ()) - t - Query
() - IO ()
dbConnectWith confn tabs query = confn (do { _ - runST (do verifyTables
tabs ; query) 0; return () })
I obviously did not think hard enough about the changes I was making for
readability...
Keean
Benjamin Franksen wrote:
On Monday 09 January 2006 10:03, Axel Simon wrote:
On Sun, 2006-01-08 at 14:51 +, Keean Schupke wrote:
My solution to this when developing a database library for my own
use was to define the API
in a bracket notation style, and only provide safe functions. The
idea is that the function obtains the resource, calls a function
passed as an argument, then frees the resource, so all resouces are
guaranteed to be freed in the correct order... for example:
dbConnectWith :: DbName - (DbHandle - IO Result) - Result
dbConnectWith name workFn = do
handle - dbConnectTo name
workFn handle `finally` dbDisconnect handle
In this way you avoid finalizers... and everthing is safe providing
you only export the with style functions from the library...
Here's an example from the library, the connect function:
I suppose you meant to write result rather than Result. This
style of functions is only safe if the user ensures that DbHandle is
never returned as part of the result. You should have that in your
documentation.
I wanted to mention this too, but you were quicker ;)
As far as I can tell, the only general solution is to use finalizers
and, if you really need to enforce a sequence of finialization,
touchForeignPtr.
Repeat: touchForeignPtr can NOT be used to enforce finalization order.
A practical issue with touchForeignPtr is that it
cannot be conveniently called from another finalizer, since the
latter live in C.
What do you mean live in C? Can't or shouldn't finalizers be written
in Haskell, too?
Ben
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
___
Haskell mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Haskell DB bindings (was Re: ANN: HDBC (Haskell Database Connectivity)
Erm, has nobody replied to this yet? I want a robust interface, that uses bracket notation all the way down, so that any error is caught and resources are freed appropriately without the use of finalizers (which may not get run and lead to resource starvation - they are not reliable if dealing with many connections, unless you start forcing garbage collections). I want a simple interface (as few functions as possible to do the job) and robust exception handling. I certainly like the idea of using runST to encapsulate the DbHandle... and infact the DB code I have does this, but not in a systematic way... I guess really all allocated handles that are passed to user defined functions need to be protected in this way. The code I wrote is really to support a relational algebra layer over the top... When I developed this there were no database drivers that worked under linux, as HSQL only supported ODBC under windows, so I developed an ODBC specific layer myself tested with unixODBC and iODBC. So IMHO, braket notation, STRef encapsulation, no finalizers, lots of exception handling, minimal interface. I would sacrifice some speed for simplicity of interface... Keean Krasimir Angelov wrote: There are three active database libraries: HDBC, HSQL and Takusen. It is quite disappointing from my point of view. Recently there was the same situation with the GUI libraires. The Haskell Community is quite small to waste efforts, developing different libraries for the same things. When I started with HSQL there were only two database libraries: HaSQL for ODBC and libpq for PostgreSQL. They both are dead, I think. I decided that it is useful to have one abstract API that can cover all database bindings. I imagine something like JDBC, ADO or DBI for Haskell. If you guys would like this to happen then lets discuss what we want. I would be happy to work on single project that can satisfy all needs. Cheers, Krasimir 2006/1/10, Tim Docker [EMAIL PROTECTED]: [EMAIL PROTECTED] wrote: Incidentally, the difficulty with finalizers was precisely the argument for using enumerators rather than cursors in database APIs. Takusen has implemented that idea; takusen currently supports Sqlite, PostgreSQL and Oracle, has a test suite. Its performance test shows that takusen can retrieve 2 million rows from a table without running out of memory. The differences between HDBC and HSQL have been recently discussed. Where does Takusen fit into this picture? From the above, it sounds like it has quite a different API. Are all 3 of these actively maintained? As someone who may wish to construct a haskell db binding for a new db, it's not clear to which API it should conform. Sometimes choice is a burden... Tim ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Looking for a random-access sequence data structure
On Fri, 2006-01-13 at 20:52 +, Ross Paterson wrote: On Fri, Jan 13, 2006 at 08:25:46PM +, Duncan Coutts wrote: On Fri, 2006-01-13 at 13:53 +, Ross Paterson wrote: Have a look at Data.Sequence (in CVS/darcs version), docs at http://www.haskell.org/ghc/dist/current/docs/libraries/base/Data-Sequence.html [...] It's probably too much to ask, but here's a question: would it be possible to provide an operation that gives a left or right view from looking up an index. Say: viewrFromIndex :: Seq a - Int - ViewL a viewlFromIndex :: Seq a - Int - ViewR a The library currently provides views for the each end of the sequence. viewl :: Seq a - ViewL a viewr :: Seq a - ViewR a I suppose this would be a zipper-like iterator for the sequence? I'm not entirely sure what these are intended to do, but can't you just compose view[lr] with take/drop? Oh yes, so you can. That's very neat. Thanks. Duncan ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: haskell.org Simple Permissive License
This is done now, with a mandatory simple permissive license. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: What does the Haskell type system do with show (1+2)?
Jared Updike wrote: http://www.haskell.org/onlinereport/decls.html#default-decls http://www.haskell.org/tutorial/numbers.html#sect10.4 I still don't see, why it works for show but not for my_show. On 1/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [...] class (Show a) = My_show a where my_show :: a - String If I let this be class My_show a where my_show :: a - String instance My_show Int where my_show a = show a ++ :: Int instance My_show Integer where my_show a = show a ++ :: Integer What is the difference to the builtin Show class? Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What does the Haskell type system do with show (1+2)?
On Thu, 12 Jan 2006 [EMAIL PROTECTED] wrote: What does the Haskell type system do with expressions such as these . . . ? show 1 show (1+2) The type of the subexpressions 1 and 1+2 are ambiguous since they have type (Num a) = a. I'm under the assumption before 1+2 is evaluated, the 1 and 2 must be coerced into a concrete type such as Int, Integer, Double, etc, and before show 1 is evaluated, the 1 must be coerced into a concrete type. Is my assumption correct? Yep. If you start ghc with -Wall option then it also tells you that some automatism is invoked. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Does anybody have a simple example of using continuation Monad?
Am Freitag, 13. Januar 2006 01:31 schrieb Cale Gibbard: On 12/01/06, Marc Weber [EMAIL PROTECTED] wrote: I think one simple example like ((+1).(\x-x**2)) in continuation style would make me understand a lot more.. Marc The basic idea about the continuation monad is that the entire computation you are defining is parametrised on a function which will take its result and continue to operate on it (the 'future'). The computation is built up in this way -- at each stage, we extend the computation by providing another piece of the future, while still leaving the computation as a whole parametrised on it. Normally we'd be forced to manage these futures by having explicit parameters for them and such, but the monad machinery hides all of this so that you don't have to worry so much about it. If you don't ever make use of the extra feature that you can get a handle on the future, you can use it just like the identity monad: addOne x = return (x+1) square x = return (x**2) f x = do y - addOne x; square y With explicit continuations, this would look something like: addOne x k = k (x + 1) square x k = k (x ** 2) f x k = addOne x (\v - square v k) Now, this seems like an awkward way to handle things as we're not making any use of the fact that at each stage, we have a handle to the future which can be used multiple times, passed into other functions, etc. The Cont monad gives one primitive for capturing the current continuation and passing it into a computation, called callCC. callCC :: ((a - Cont b) - Cont a) - Cont a This type requires some study to understand at first, but essentially, callCC takes a function from a future (a - Cont b) to a new computation (Cont a), and passes it the current future (which is accessible due to the funny way in which we're parametrising our computations). In terms of callCC, we can write other, more convenient ways to manipulate futures. The following is due to Tomasz Zielonka [1]: getCC :: MonadCont m = m (m a) getCC = callCC (\c - let x = c x in return x) getCC' :: MonadCont m = a - m (a, a - m b) getCC' x0 = callCC (\c - let f x = c (x, f) in return (x0, f)) getCC will get the current continuation explicitly as a computation which can be executed. This essentially gives us a 'goto-label' at that point in the computation, and executing it will jump back. This isn't terribly useful in plain Cont, except to land us in an infinite loop, but over a state monad, or IO, we can cause side-effect havoc, observe the state, and decide whether to return to the goto-label or not. Stealing an example from Tomasz' original message: -- prints hello! in an endless loop test :: IO () test = (`runContT` return) $ do jump - getCC lift $ putStrLn hello! jump getCC' is similar, but actually allows an additional parameter to be sent back. The parameter to getCC' is just the initial value. Here's a simplistic implementation of mod by repeated addition/subtraction which prints intermediate results as it goes, in the ContT transformed IO monad. x `modulo` m = (`runContT` return) $ do (u, jump) - getCC' x lift $ print u case u of _ | u 0 - jump (u + m) | u = m- jump (u - m) | otherwise - return u - Cale [1] http://www.haskell.org/pipermail/haskell-cafe/2005-July/010623.html This helps, but not enough for me, unfortunately. Could someone give or point to an example of medium complexity? Something to bridge the gap between a CPS-factorial and ReadP, preferably with an explanation why CPS is used ? Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What does the Haskell type system do with show (1+2)?
Am Freitag, 13. Januar 2006 11:12 schrieb Christian Maeder: Jared Updike wrote: http://www.haskell.org/onlinereport/decls.html#default-decls http://www.haskell.org/tutorial/numbers.html#sect10.4 I still don't see, why it works for show but not for my_show. Says the report: Ambiguities in the class Num are most common, so Haskell provides another way to resolve them---with a default declaration: default (t1 , ... , tn) where n=0, and each ti must be a type for which Num ti holds. In situations where an ambiguous type is discovered, an ambiguous type variable, v, is defaultable if: v appears only in constraints of the form C v, where C is a class, and at least one of these classes is a numeric class, (that is, Num or a subclass of Num), and all of these classes are defined in the Prelude or a standard library (Figures ^^ That's the point! ^^ 6.2--6.3, pages -- show the numeric classes, and Figure 6.1, page , shows the classes defined in the Prelude.) Each defaultable variable is replaced by the first type in the default list that is an instance of all the ambiguous variable's classes. It is a static error if no such type is found. On 1/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [...] class (Show a) = My_show a where my_show :: a - String If I let this be class My_show a where my_show :: a - String instance My_show Int where my_show a = show a ++ :: Int instance My_show Integer where my_show a = show a ++ :: Integer What is the difference to the builtin Show class? It's not declared in the prelude or standard libraries. Christian Now the question is, could that restriction be lifted, i.e., would it be possible/worthwhile to let defaulting also take place if user defined classes are involved? Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What does the Haskell type system do with show (1+2)?
On 13/01/06, Daniel Fischer [EMAIL PROTECTED] wrote: Am Freitag, 13. Januar 2006 11:12 schrieb Christian Maeder: Jared Updike wrote: http://www.haskell.org/onlinereport/decls.html#default-decls http://www.haskell.org/tutorial/numbers.html#sect10.4 I still don't see, why it works for show but not for my_show. Says the report: Ambiguities in the class Num are most common, so Haskell provides another way to resolve them---with a default declaration: default (t1 , ... , tn) where n=0, and each ti must be a type for which Num ti holds. In situations where an ambiguous type is discovered, an ambiguous type variable, v, is defaultable if: v appears only in constraints of the form C v, where C is a class, and at least one of these classes is a numeric class, (that is, Num or a subclass of Num), and all of these classes are defined in the Prelude or a standard library (Figures ^^ That's the point! ^^ 6.2--6.3, pages -- show the numeric classes, and Figure 6.1, page , shows the classes defined in the Prelude.) Each defaultable variable is replaced by the first type in the default list that is an instance of all the ambiguous variable's classes. It is a static error if no such type is found. On 1/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [...] class (Show a) = My_show a where my_show :: a - String If I let this be class My_show a where my_show :: a - String instance My_show Int where my_show a = show a ++ :: Int instance My_show Integer where my_show a = show a ++ :: Integer What is the difference to the builtin Show class? It's not declared in the prelude or standard libraries. Christian Now the question is, could that restriction be lifted, i.e., would it be possible/worthwhile to let defaulting also take place if user defined classes are involved? So long as we're going to have a defaulting mechanism, it seems a bit odd to restrict it to Num, and to classes in the Prelude. It would be neat if this could be somewhat generalised, so that, say, the Haskell 98 defaulting behaviour could be completely specified by declarations in the Prelude, but it's a good question as to exactly how it should be generalised at all. It seems a bit tricky to come up with a way to specify the defaulting behaviour which is both general enough to express the current behaviour, and which doesn't result in conflicts in the orders in which default types are tried. The 'obvious' thing is to have a specification somewhat like: default C (t1,...,tn) where C is the name of a single parameter typeclass (or a multiparameter one, with all but one of the type variables applied; there ought to be a way to generalise to multi-parameter typeclasses if we can sort out the problems here) The problem comes when you have a type variable which is ambiguous, and to which multiple defaulting specifications apply. In which order do we try the defaults? We almost certainly wouldn't want it to depend, for example, on the order in which the class constraints in a type declaration were specified. We could pick the defaulting mechanism based on order of occurrence to some extent, but even this seems a little ugly. Also, how do these defaults interact with modules? If we want the system to be nice and general, it would be nice to have the behaviour with respect to Num specified in the Prelude and merely exported, but this potentially opens up another can of worms with regard to exporting defaults. If we always export them, it's unclear what happens with cyclic module dependency graphs. Perhaps there should be some provision to allow for writing something like default C in the module export/import lists. - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What does the Haskell type system do withshow (1+2)?
Cale Gibbard wrote: Snip So long as we're going to have a defaulting mechanism, it seems a bit odd to restrict it to Num, and to classes in the Prelude. Instead of having literals such as 1 that could be Int, Integer, or Float etc, why not just have one Number type declared as something like: data Number = NInt Int | NInteger Integer | NFloat Float | NDouble Double | NRational Integer Integer | NComplex Number Number etc so that all numeric literals would just be translated by the compiler into a Number. Arithmetic ops would then not be overloaded but the compiler could hopefully optimize out the extra indirection caused by using Number instead of plain Int, Integer, etc. Regards, Brian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What does the Haskell type system do withshow (1+2)?
On 13/01/06, Brian Hulley [EMAIL PROTECTED] wrote: Cale Gibbard wrote: Snip So long as we're going to have a defaulting mechanism, it seems a bit odd to restrict it to Num, and to classes in the Prelude. Instead of having literals such as 1 that could be Int, Integer, or Float etc, why not just have one Number type declared as something like: data Number = NInt Int | NInteger Integer | NFloat Float | NDouble Double | NRational Integer Integer | NComplex Number Number etc so that all numeric literals would just be translated by the compiler into a Number. Arithmetic ops would then not be overloaded but the compiler could hopefully optimize out the extra indirection caused by using Number instead of plain Int, Integer, etc. Regards, Brian. This is not very extensible though. You can't extend that type later with numeric types of your own (e.g. polynomials, power series, an arbitrary precision computable real type, or some finite field). Having a Num typeclass allows for users to add their own numeric types at will. Also, implicit coercions would be required to implement the operations on your type, which I'm not sure is such a good idea. The real problem is that the syntax is overloaded. Somehow I don't fancy the requirement to type NInteger 5 (respectively 5 :: Integer) whenever I want to refer to 5 in an arithmetic expression, and determining which constructor to apply automatically is the same problem as the defaulting mechanism solves. (Only, with the algebraic union, it must be solved at each and every numeric literal, rather than the comparatively fewer times it would need to be solved in general to make the system of type constraints determined.) Ambiguity is actually seldom a real problem in practice. Usually something comes along and fixes the type -- it's only really at the GHCi/Hugs prompt that this is usually a major issue. This is another reason perhaps why it hasn't been generalised. Probably the real reason that it's restricted to Num is that instances of Num are the only types with such overloaded syntax in the language. (I can write 5, and have it mean an Integer, Complex Double, a Rational, or a constant power series of some type I cooked up.) There are other situations where ambiguities can arise, but to be honest, I've never been too annoyed by them. Still, it sort of looks odd to have a feature which looks like it could be vastly more general, but which only applies to this one Prelude class Num, and only in contexts involving other Prelude classes. Thinking about it more is making it clearer why it is restricted to Num, though it's not obvious that it should remain that way forever. The original question posed by Daniel is whether we should lift the restriction that all of the classes involved are in a standard library when doing defaulting. That's such a subtle and odd point that there almost certainly is a reason for it. Does anyone know it? - Cale ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskell-Cafe Digest, Vol 29, Issue 36
Christian Maeder wrote: Jared Updike wrote: http://www.haskell.org/onlinereport/decls.html#default-decls http://www.haskell.org/tutorial/numbers.html#sect10.4 I still don't see, why it works for show but not for my_show. On 1/12/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: [...] class (Show a) = My_show a where my_show :: a - String If I let this be class My_show a where my_show :: a - String instance My_show Int where my_show a = show a ++ :: Int instance My_show Integer where my_show a = show a ++ :: Integer What is the difference to the builtin Show class? I was wondering the same thing myself. Then, I reread the online Haskell report link. From http://www.haskell.org/onlinereport/decls.html#default-decls: where n=0, and each ti must be a type for which Num ti holds. In situations where an ambiguous type is discovered, an ambiguous type variable, v, is defaultable if: o v appears only in constraints of the form C v, where C is a class, and o at least one of these classes is a numeric class, (that is, Num or a subclass of Num), and o all of these classes are defined in the Prelude or a standard library (Figures 6.2--6.3, pages -- show the numeric classes, and Figure 6.1, page , shows the classes defined in the Prelude.) Notice the last bullet item. class Show is part of the Prelude. However, class My_show is not part of the prelude. AS far as I can tell, that's the only reason my_show 1 produces errors while show 1 is okay. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Inheritance without OOHaskell
Hello, I'd like to put forth two situations in which I miss the ability to use inheritance in Haskell, and then see if maybe somebody has some insight that I'm missing out on. Situation #1: In HDBC, there is a Connection type that is more or less equivolent to a class on a OOP language. In Haskell, we use a record with named fields that represent functions. Closures are used to permit those functions to access internal state. That works well enough. But there is no way at all to extend this. Say a database such as PostgreSQL has some extra features -- it would be nice for the PostgreSQL objects to support additional functions, whereas Connection objects from other databases might not support those functions. Any Haskell function could expect a Connection object (in which case it could access only the standard functions) or a PostgreSQL object (in which case it could access the standard plus the enhanced functions). The internal state of a Connection object is DB-specific, so there can be no general function to expose it. Situation #2: In Python, every exception is an object, and every object can be extended. Therefore, I could write an exception handler for, say, an IO error, and have it work for anything that's a subclass of the generic IO error -- even if these subclasses weren't known at the time the program was written. Other handlers could be as specific or as general as desired. In Haskell, it seems that all of this has to be anticipated in advance; it's not very easy to extend things. So my questions are: 1. I have sometimes used typeclasses instead of data records. This provides some of what I'm searching for, but has the unfortunate side-effect that one can't very easily build a list of objects that may not come from the same place but are nonetheless part of the class. For instance, had I used typeclasses for HDBC, I couldn't have a list of Connection objects where some are from MySQL, some from PostgreSQL, etc. 2. As a library designer, what is the most friendly way around these problems that adheres to the principle of least surprise for Haskell programmers? 3. How does one choose between a type class and a data record of functions when both would meet the general needs? 4. Is there a way to solve these inheritance problems without resorting to a library such as OOHaskell, which many Haskell programmers are not familiar with? Thanks, -- John -- John Goerzen [EMAIL PROTECTED]GPG: 0x8A1D9A1Fwww.complete.org Value your freedom, or you will lose it, teaches history. `Don't bother us with politics,' respond those who don't want to learn. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Splitting a string into chunks
Hi,
I'm trying to split a string into a list of substrings, where substrings
are delimited by blank lines.
This feels like it *should* be a primitive operation, but I can't seem
to find one that works. It's neither a fold nor a partition, since each
chunk is separated by a 2-character sequence. It's also not a grouping
operation, since ghc's Data.List.groupBy examines the first element in a
sequence with each candidate member of the same sequence, as
demonstrated by:
Prelude :module + Data.List
Prelude Data.List let t = asdfjkl;
Prelude Data.List groupBy (\a _ - a == 's') t
[a,sdfjkl;]
As a result, I've wound up with this:
-- Convert a file into blocks separated by blank lines (two
-- consecutive \n characters.) NB: Requires UNIX linefeeds
blocks :: String - [String]
blocks s = f s
where
f [] = []
f s [] = [s]
f s ('\n':'\n':rest) = (s:f rest)
f s (a:rest) = f (s ++ [a]) rest
Which somehow feels ugly. This feels like it should be a fold, a group
or something, where the test is something like:
(\a b - (a /= '\n') (b /= '\n'))
Any thoughts?
Thanks,
-- Adam
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Inheritance without OOHaskell
On 13/01/06, John Goerzen [EMAIL PROTECTED] wrote: Hello, I'd like to put forth two situations in which I miss the ability to use inheritance in Haskell, and then see if maybe somebody has some insight that I'm missing out on. Situation #1: In HDBC, there is a Connection type that is more or less equivolent to a class on a OOP language. In Haskell, we use a record with named fields that represent functions. Closures are used to permit those functions to access internal state. That works well enough. But there is no way at all to extend this. Say a database such as PostgreSQL has some extra features -- it would be nice for the PostgreSQL objects to support additional functions, whereas Connection objects from other databases might not support those functions. Any Haskell function could expect a Connection object (in which case it could access only the standard functions) or a PostgreSQL object (in which case it could access the standard plus the enhanced functions). The internal state of a Connection object is DB-specific, so there can be no general function to expose it. You're describing what sounds like a good application of type classes. You have an interface which all connection types should support, and specific types which may have extra properties apart from that interface. Situation #2: In Python, every exception is an object, and every object can be extended. Therefore, I could write an exception handler for, say, an IO error, and have it work for anything that's a subclass of the generic IO error -- even if these subclasses weren't known at the time the program was written. Other handlers could be as specific or as general as desired. In Haskell, it seems that all of this has to be anticipated in advance; it's not very easy to extend things. So my questions are: 1. I have sometimes used typeclasses instead of data records. This provides some of what I'm searching for, but has the unfortunate side-effect that one can't very easily build a list of objects that may not come from the same place but are nonetheless part of the class. For instance, had I used typeclasses for HDBC, I couldn't have a list of Connection objects where some are from MySQL, some from PostgreSQL, etc. If you need to hold a bunch of connections of varying types together in a data structure at some point, you can use an existential type, like: data Connection where Conn :: (IsConnection c) = c - Connection In general, existential types are the solution to this problem. You can often get around the use of existential types, but they're pretty convenient when you run into this problem and don't want to redesign everything. Also, without a lot of thinking, this can often lead to just passing dictionaries around to simulate the existential type. (otoh, it's Haskell 98, whereas existential types aren't) 2. As a library designer, what is the most friendly way around these problems that adheres to the principle of least surprise for Haskell programmers? Existential types aren't bad. They do however indicate an OO-design going on. Without really considering the application at hand, it can be hard to decide how to write it in a more functional way, but the basic concept is that data are hard to extend, so you should make them fairly universal, and all the extending should happen by writing additional functions (and potentially some new datatypes altogether). Note that this is the opposite of the usual case with OO, where it's often easy to extend the data being carried around, but it can be quite a lot of work to extend the functional interface. 3. How does one choose between a type class and a data record of functions when both would meet the general needs? The biggest differences between those are that 1) There can be only one typeclass instance for a given assignment of type parameters, so if you expect that users will often want to use the same type with the given interface in multiple ways, typeclasses are poor. 2) In almost every other situation, typeclasses are nicer, since you don't have to pass instances around or name which one you're using explicitly. Further, if you add a method to a typeclass, you need to implement it in all the instances, but if you add an additional function to your record type, you not only have to update the 'instance' records, but also likely a number of the places where they've been used. 4. Is there a way to solve these inheritance problems without resorting to a library such as OOHaskell, which many Haskell programmers are not familiar with? Well, hmm... You can try to avoid the concept of inheritance altogether. You can give names to separate parts of interfaces via typeclasses, and even enforce that something implementing one of these classes implements the other. Often, you can also take care of things via parametric polymorphism, where the data types are parametrised over the later extensions, and anything which doesn't
Re: [Haskell-cafe] Splitting a string into chunks
On 1/13/06, Adam Turoff [EMAIL PROTECTED] wrote:
Hi,
I'm trying to split a string into a list of substrings, where substrings
are delimited by blank lines.
This feels like it *should* be a primitive operation, but I can't seem
to find one that works. It's neither a fold nor a partition, since each
chunk is separated by a 2-character sequence. It's also not a grouping
operation, since ghc's Data.List.groupBy examines the first element in a
sequence with each candidate member of the same sequence, as
demonstrated by:
Prelude :module + Data.List
Prelude Data.List let t = asdfjkl;
Prelude Data.List groupBy (\a _ - a == 's') t
[a,sdfjkl;]
As a result, I've wound up with this:
-- Convert a file into blocks separated by blank lines (two
-- consecutive \n characters.) NB: Requires UNIX linefeeds
blocks :: String - [String]
blocks s = f s
where
f [] = []
f s [] = [s]
f s ('\n':'\n':rest) = (s:f rest)
f s (a:rest) = f (s ++ [a]) rest
Which somehow feels ugly. This feels like it should be a fold, a group
or something, where the test is something like:
(\a b - (a /= '\n') (b /= '\n'))
Off the top of my head:
blocks = map concat . groupBy (const null) . lines
The lines function splits it into lines, the groupBy will group the
list into lists of lists and split when the sedond of two adjacent
elements is null (which is what an empty line passed to lines will
give you) and then a concat on each of the elements of this list will
undo the redundant lines-splitting that lines performed...
/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a string into chunks
On 1/13/06, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 1/13/06, Adam Turoff [EMAIL PROTECTED] wrote:
Hi,
I'm trying to split a string into a list of substrings, where substrings
are delimited by blank lines.
This feels like it *should* be a primitive operation, but I can't seem
to find one that works. It's neither a fold nor a partition, since each
chunk is separated by a 2-character sequence. It's also not a grouping
operation, since ghc's Data.List.groupBy examines the first element in a
sequence with each candidate member of the same sequence, as
demonstrated by:
Prelude :module + Data.List
Prelude Data.List let t = asdfjkl;
Prelude Data.List groupBy (\a _ - a == 's') t
[a,sdfjkl;]
As a result, I've wound up with this:
-- Convert a file into blocks separated by blank lines (two
-- consecutive \n characters.) NB: Requires UNIX linefeeds
blocks :: String - [String]
blocks s = f s
where
f [] = []
f s [] = [s]
f s ('\n':'\n':rest) = (s:f rest)
f s (a:rest) = f (s ++ [a]) rest
Which somehow feels ugly. This feels like it should be a fold, a group
or something, where the test is something like:
(\a b - (a /= '\n') (b /= '\n'))
Off the top of my head:
blocks = map concat . groupBy (const null) . lines
The lines function splits it into lines, the groupBy will group the
list into lists of lists and split when the sedond of two adjacent
elements is null (which is what an empty line passed to lines will
give you) and then a concat on each of the elements of this list will
undo the redundant lines-splitting that lines performed...
Sorry, I got the meaning of groupBy mixed up, it should be
blocks = map concat . groupBy (const (not . null)) . lines
/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a string into chunks
That works except it loses single newline characters.
let s = 1234\n5678\n\nabcdefghijklmnopq\n\n,,.,.,.
Prelude blocks s
[12345678,abcdefghijklmnopq,,,.,.,.]
Jared.
On 1/13/06, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 1/13/06, Sebastian Sylvan [EMAIL PROTECTED] wrote:
On 1/13/06, Adam Turoff [EMAIL PROTECTED] wrote:
Hi,
I'm trying to split a string into a list of substrings, where substrings
are delimited by blank lines.
This feels like it *should* be a primitive operation, but I can't seem
to find one that works. It's neither a fold nor a partition, since each
chunk is separated by a 2-character sequence. It's also not a grouping
operation, since ghc's Data.List.groupBy examines the first element in a
sequence with each candidate member of the same sequence, as
demonstrated by:
Prelude :module + Data.List
Prelude Data.List let t = asdfjkl;
Prelude Data.List groupBy (\a _ - a == 's') t
[a,sdfjkl;]
As a result, I've wound up with this:
-- Convert a file into blocks separated by blank lines (two
-- consecutive \n characters.) NB: Requires UNIX linefeeds
blocks :: String - [String]
blocks s = f s
where
f [] = []
f s [] = [s]
f s ('\n':'\n':rest) = (s:f rest)
f s (a:rest) = f (s ++ [a]) rest
Which somehow feels ugly. This feels like it should be a fold, a group
or something, where the test is something like:
(\a b - (a /= '\n') (b /= '\n'))
Off the top of my head:
blocks = map concat . groupBy (const null) . lines
The lines function splits it into lines, the groupBy will group the
list into lists of lists and split when the sedond of two adjacent
elements is null (which is what an empty line passed to lines will
give you) and then a concat on each of the elements of this list will
undo the redundant lines-splitting that lines performed...
Sorry, I got the meaning of groupBy mixed up, it should be
blocks = map concat . groupBy (const (not . null)) . lines
/S
--
Sebastian Sylvan
+46(0)736-818655
UIN: 44640862
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
[EMAIL PROTECTED]
http://www.updike.org/~jared/
reverse )-:
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a string into chunks
On 2006-01-13 at 13:32PST Jared Updike wrote: That works except it loses single newline characters. let s = 1234\n5678\n\nabcdefghijklmnopq\n\n,,.,.,. Prelude blocks s [12345678,abcdefghijklmnopq,,,.,.,.] Also the argument to groupBy ought to be some sort of equivalence relation. blocks = map unlines . filter (all $ not . null) . groupBy (\a b - not (null b|| null a)) . lines ... but that suffers from the somewhat questionable properties of lines and unlines. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a string into chunks
On Jan 13, 2006, at 4:35 PM, Jon Fairbairn wrote: On 2006-01-13 at 13:32PST Jared Updike wrote: That works except it loses single newline characters. let s = 1234\n5678\n\nabcdefghijklmnopq\n\n,,.,.,. Prelude blocks s [12345678,abcdefghijklmnopq,,,.,.,.] Also the argument to groupBy ought to be some sort of equivalence relation. Humm, still not reflexive. You need xor. blocks = map unlines . filter (all $ not . null) . groupBy (\a b - not (null b|| null a)) . lines ... but that suffers from the somewhat questionable properties of lines and unlines. -- Jón Fairbairn Jon.Fairbairn at cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Splitting a string into chunks
On 1/13/06, Sebastian Sylvan [EMAIL PROTECTED] wrote:
blocks = map concat . groupBy (const (not . null)) . lines
Thanks. That's a little more involved than I was looking for, but that
certainly looks better than pattern matching on ('\n':'\n':rest). ;-)
For the record, lines removes the trailing newline, so a string like:
a
b
c
d
becomes [ab, cd], which can interfere with processing if the whitespace
is significant. Changing this to
blocks = map unlines . groupBy (const (not . null)) . lines
re-adds all of the newlines, thus re-adding the significant whitespace,
while still chunking everything into blocks: [a\nb\n,\nc\nd\n]
Thanks again,
-- Adam
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] HDBC Transactions with Sqlite3
I have HDBC running with Sqlite3, but I'm getting a SqlError due to a
locked table. Please excuse my SQL ignorance, but what may be causing
the problem? In SQL, are we not allowed to select, update, and delete
from a table within a single transaction? If not, what are the rules
for transactions?
Thanks for any help!
-Tom
SELECT * FROM freeKey;
SELECT * FROM nextKey;
INSERT INTO nextKey VALUES (1);
SELECT * FROM freeKey;
SELECT * FROM nextKey;
UPDATE nextKey SET key = 2 WHERE key = 1;
SELECT * FROM freeKey;
SELECT * FROM nextKey;
UPDATE nextKey SET key = 3 WHERE key = 2;
INSERT INTO freeKey VALUES (0);
INSERT INTO freeKey VALUES (1);
SELECT * FROM freeKey;
DELETE FROM freeKey WHERE key = 0;
SqlError {seState = , seNativeError = 1, seErrorMsg = step:
database table is locked}
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: What does the Haskell type system do with show (1+2)?
Daniel Fischer wrote: Now the question is, could that restriction be lifted, i.e., would it be possible/worthwhile to let defaulting also take place if user defined classes are involved? The current defaulting mechanism in Haskell is very, very conservative. You could easily relax the restriction that all classes have to come from the Prelude. I have sometimes wished for that. But on the other hand, I try to avoid relying on defaulting anywhere, so it doesn't disturb me much. -- Lennart ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
