Re: [GHC] #4116: Type supplement for constructor specific uses of sum types
#4116: Type supplement for constructor specific uses of sum types
-+--
Reporter: gabrielrf | Owner:
Type: proposal | Status: new
Priority: normal| Component: Compiler
Version: 6.13 |Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by gabrielrf):
Sorry
{{{
headFromJust :: (Maybe (List a)) @ {Just (_:_)} - a
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4116#comment:7
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] #4116: Type supplement for constructor specific uses of sum types
#4116: Type supplement for constructor specific uses of sum types
-+--
Reporter: gabrielrf | Owner:
Type: proposal | Status: new
Priority: normal| Component: Compiler
Version: 6.13 |Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by gabrielrf):
Correction. No need for type info within the supplement.
{{{
hd :: (List2 a) @ { Cons _ _ | Cons2 _ _ _ } - a
hd (Cons x _) = x
hd (Cons2 x _ _) = x
}}}
{{{
headFromJust :: (Maybe a) @ {Just (_:_)} - a
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4116#comment:6
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] #4123: Control.Concurrent.MVar doesn't need to depend on the Prelude
#4123: Control.Concurrent.MVar doesn't need to depend on the Prelude -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Component: libraries/base Version: 6.13 |Keywords: Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- `Control.Concurrent.MVar` currently depends on the `Prelude`, causing an import cycle in the new I/O manager. This patch replaces the dependency on the `Prelude` with modules in the `GHC` hierarchy, breaking the cycle. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4123 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] #4116: Type supplement for constructor specific uses of sum types
#4116: Type supplement for constructor specific uses of sum types -+-- Reporter: gabrielrf | Owner: Type: proposal | Status: new Priority: normal| Component: Compiler Version: 6.13 |Keywords: Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Changes (by ozgur): * cc: ozgurak...@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4116#comment:5 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] #4122: Data.Monoid doesn't need to depend on the Prelude
#4122: Data.Monoid doesn't need to depend on the Prelude -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Component: libraries/base Version: 6.13 |Keywords: Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Comment(by tibbe): I've attached a revised patch that adds `-XNoImplicitPrelude`. The same flag is set in the .cabal file but it doesn't hurt to be explicit. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4122#comment:1 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] #4122: Data.Monoid doesn't need to depend on the Prelude
#4122: Data.Monoid doesn't need to depend on the Prelude -+-- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal| Component: libraries/base Version: 6.13 |Keywords: Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- `Data.Monoid` currently depends on the `Prelude`, causing an import cycle in the new I/O manager. This patch replaces the dependency on the `Prelude` with modules in the `GHC` hierarchy, breaking the cycle. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4122 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] #4122: Data.Monoid doesn't need to depend on the Prelude
#4122: Data.Monoid doesn't need to depend on the Prelude -+-- Reporter: tibbe |Owner: Type: bug | Status: patch Priority: normal|Milestone: Component: libraries/base| Version: 6.13 Keywords:| Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Changes (by igloo): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4122#comment:2 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] #4116: Type supplement for constructor specific uses of sum types
#4116: Type supplement for constructor specific uses of sum types
-+--
Reporter: gabrielrf | Owner:
Type: proposal | Status: new
Priority: normal| Component: Compiler
Version: 6.13 |Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Comment(by gabrielrf):
Further extension:
since we try to propagate case analysis
we can express the type supplement as a set of disjoint patterns, as masks
for the different branches
{{{
hd :: (List2 a) @ { Cons a _ | Cons2 a _ _ } - a
hd (Cons x _) = x
hd (Cons2 x _ _) = x
}}}
as reflected by Wren NG Thornton in
http://article.gmane.org/gmane.comp.lang.haskell.cafe/75669
making possible nested patterns
{{{
headFromJust :: (Maybe a) @ {Just a:_} - a
}}}
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4116#comment:4
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] #2889: Compilation fails - Can't opne temporary
#2889: Compilation fails - Can't opne temporary ---+ Reporter: fobrock | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 6.12.3 Component: Compiler |Version: 6.12.2 Resolution:| Keywords: Difficulty: Unknown | Os: Windows Testcase:| Architecture: x86 Failure: None/Unknown | ---+ Changes (by igloo): * owner: igloo = simonmar Comment: Simon, do you have a Windows machine with multiple drives? If so, can you see if you can reproduce this with the same split, i.e. temporary directory on one and GHC on another, please? -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2889#comment:16 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] #3994: Add support for creating and interrupting process groups
#3994: Add support for creating and interrupting process groups --+- Reporter: hamish |Owner: simonmar Type: proposal | Status: patch Priority: high |Milestone: 6.14.1 Component: libraries/process | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by igloo): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3994#comment:8 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] #3994: Add support for creating and interrupting process groups
#3994: Add support for creating and interrupting process groups --+- Reporter: hamish |Owner: simonmar Type: proposal | Status: new Priority: high |Milestone: 6.14.1 Component: libraries/process | Version: 6.12.1 Keywords: | Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: None/Unknown --+- Changes (by igloo): * owner: = simonmar -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3994#comment:7 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] #4117: GHC does not accept --srcdir
#4117: GHC does not accept --srcdir
-+--
Reporter: uzytkownik|Owner:
Type: bug | Status: new
Priority: normal|Milestone: 6.14.1
Component: Build System | Version: 6.12.1
Keywords:| Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: Building GHC failed
-+--
Changes (by igloo):
* component: Compiler = Build System
* milestone: = 6.14.1
Comment:
Thanks for the report.
I assume it is configure, rather than GHC, which uzytkownik expects to
accept the flag. Our configure script's `--help` output claims:
{{{
--srcdir=DIRfind the sources in DIR [configure dir or `..']
}}}
but I assume the build system currently ignores it.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4117#comment:1
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] #4123: Control.Concurrent.MVar doesn't need to depend on the Prelude
#4123: Control.Concurrent.MVar doesn't need to depend on the Prelude -+-- Reporter: tibbe |Owner: Type: bug | Status: patch Priority: normal|Milestone: Component: libraries/base| Version: 6.13 Keywords:| Difficulty: Os: Unknown/Multiple | Testcase: Architecture: Unknown/Multiple | Failure: Building GHC failed -+-- Changes (by igloo): * status: new = patch -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4123#comment:1 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] #4117: GHC does not accept --srcdir
#4117: GHC does not accept --srcdir
-+--
Reporter: uzytkownik|Owner:
Type: bug | Status: new
Priority: normal|Milestone: 6.14.1
Component: Build System | Version: 6.12.1
Keywords:| Difficulty:
Os: Unknown/Multiple | Testcase:
Architecture: Unknown/Multiple | Failure: Building GHC failed
-+--
Comment(by uzytkownik):
Replying to [comment:1 igloo]:
Thanks for the report.
I assume it is configure, rather than GHC,
Ups. Sorry my error.
which uzytkownik expects to accept the flag. Our configure script's
`--help` output claims:
{{{
--srcdir=DIRfind the sources in DIR [configure dir or
`..']
}}}
but I assume the build system currently ignores it.
IIRC it says it is not supported and fail the configuration.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4117#comment:2
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] #4124: GHC rejects instance quotations with splices in the instance head
#4124: GHC rejects instance quotations with splices in the instance head
-+--
Reporter: lilac | Owner:
Type: bug | Status: new
Priority: normal| Component: Template Haskell
Version: 6.12.1|Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
-+--
I think the following code should be accepted.
{{{
{-# LANGUAGE TemplateHaskell #-}
class Storable a where
data X = X
[d| instance Storable $( [t| X |] ) where |]
}}}
GHC disagrees, saying:
{{{
test.hs:4:4:
Illegal instance declaration for `Storable t_aKj'
(All instance types must be of the form (T a1 ... an)
where a1 ... an are type *variables*,
and each type variable appears at most once in the instance head.
Use -XFlexibleInstances if you want to disable this.)
In the instance declaration for `Storable $[t| X |]'
In the Template Haskell quotation
[d|
instance Storable $[t| X |] where |]
In the expression:
[d|
instance Storable $[t| X |] where |]
}}}
This checking seems inappropriate before the type is actually spliced in!
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4124
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] #4124: GHC rejects instance quotations with splices in the instance head
#4124: GHC rejects instance quotations with splices in the instance head -+-- Reporter: lilac | Owner: Type: bug | Status: new Priority: normal| Component: Template Haskell Version: 6.12.1|Keywords: Os: Unknown/Multiple |Testcase: Architecture: Unknown/Multiple | Failure: GHC rejects valid program -+-- Comment(by lilac): Some quick checking indicates the error message is using invalid syntax too: $[t| X |] is not accepted by GHC. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4124#comment:1 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] #4125: Template haskell rejects duplicate instances before they're spliced
#4125: Template haskell rejects duplicate instances before they're spliced
-+--
Reporter: lilac | Owner:
Type: bug | Status: new
Priority: normal| Component: Template Haskell
Version: 6.12.1|Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: GHC rejects valid program
-+--
Suppose I want to see (from within ghci) how to write an instance
declaration in the TH AST. I try:
{{{
Prelude runQ $ [d| instance Monad Maybe where |]
interactive:1:13:
Duplicate instance declarations:
instance Monad Maybe -- Defined at interactive:1:13-23
instance Monad Maybe -- Defined in Data.Maybe
In the Template Haskell quotation
[d|
instance Monad Maybe where |]
In the expression:
[d|
instance Monad Maybe where |]
In the definition of `it':
it = [d|
instance Monad Maybe where |]
}}}
This seems ridiculous; I'm not trying to create an instance, just to
create a TH AST fragment.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4125
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] #4127: Template haskell instance declaration quotations with members don't work in ghci
#4127: Template haskell instance declaration quotations with members don't work
in
ghci
-+--
Reporter: lilac | Owner:
Type: bug | Status: new
Priority: normal| Component: GHCi
Version: 6.12.1|Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Inside GHCi, the following quotation fails:
{{{
Prelude Language.Haskell.TH runQ [d| instance Monad ((,) a) where return
= (,) undefined; (a,x) = f = f x |]
interactive:1:38:
`return' is not a (visible) method of class `Monad'
interactive:1:68:
`=' is not a (visible) method of class `Monad'
}}}
The same error seems to occur for any typeclass I try. This code works
fine inside a module passed to GHC.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4127
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] #4128: Can't capture classes inside a template haskell type quotation
#4128: Can't capture classes inside a template haskell type quotation
-+--
Reporter: lilac | Owner:
Type: feature request | Status: new
Priority: normal| Component: Template Haskell
Version: 6.12.1|Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
GHC rejects the following:
{{{
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
class C a where
data X = X
fmap return $ instanceD (cxt []) [t| C $(conT ''X) |] []
}}}
with the error:
{{{
test.hs:5:23:
Class `C' used as a type
In the Template Haskell quotation [t| C $(conT 'X) |]
In the second argument of `instanceD', namely `[t| C $(conT 'X) |]'
In the expression: instanceD (cxt []) [t| C $(conT 'X) |] []
}}}
This is frustrating, since that quotation would have resulted in exactly
the TH AST fragment I wanted, had the error not occurred. Instead I must
resort to:
{{{
instanceD (cxt []) (appT (conT ''Storable) (conT ''X)) []
}}}
Incidentally, the error message produced is wrong: The error says 'X
whereas I wrote ''X.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4128
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] #4129: Template haskell API makes inconsistent use of [Q Dec], Q [Dec] and Q Dec
#4129: Template haskell API makes inconsistent use of [Q Dec], Q [Dec] and Q Dec
-+--
Reporter: lilac | Owner:
Type: proposal | Status: new
Priority: normal| Component: Template Haskell
Version: 6.12.1|Keywords:
Os: Unknown/Multiple |Testcase:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Template haskell declaration quotations produce Q [Dec]. However, all of
the functions for consuming lists of declarations in Language.Haskell.TH
accept only [Q Dec]. This results in some pretty awkward constructs, such
as:
{{{
instanceD ctxt inst = (fmap.fmap) return [d|
foo a = a * 42
|]
}}}
[Note also that |] must be indented in the above example (otherwise GHC
gives an unhelpful error).]
Equally problematically, the functions which /create/ declarations all
produce Q Dec, but declaration splices want Q [Dec], resulting in the need
to write ugly code or drop into a do-block.
My modest proposal to fix all this is to have only a single type used for
declarations within the world of TH. The obvious most-general choice for
this type is Q [Dec]. So:[[br]]
1) Change all [DecQ] arguments to Q [Dec][[br]]
2) Change all DecQ return types to Q [Dec][[br]]
3) Add ++ = liftM2 (++) for easy combining of Q [Dec] to
Language.Haskell.TH.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4129
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] #2833: internal error: throwTo: unrecognised why_blocked value
#2833: internal error: throwTo: unrecognised why_blocked value -+-- Reporter: lilac | Owner: Type: bug | Status: closed Priority: low | Milestone: 6.12.1 Component: Runtime System |Version: 6.10.1 Resolution: fixed | Keywords: Difficulty: Unknown | Os: Linux Testcase: | Architecture: Unknown/Multiple Failure: None/Unknown| -+-- Changes (by lilac): * failure: = None/Unknown Comment: Hi, Sorry for taking such an enormously long time to respond. I can confirm that I can no longer reproduce an issue here using GHC 6.12.1. Thanks! -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/2833#comment:7 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
hsc2hs on Mac OS 10.6 unreliable?
Hi all, we're facing serious problems (the seg'faulting kind) with Gtk2Hs on Mac OS 10.6. Chris has tracked this down to incorrect structure offsets that hsc2hs calculates. The offsets that hsc2hs calculates are too large, so it is probably in x86_64 mode. The offsets with which Gtk+ was compiled are smaller, so it must have been compiled with something like -arch i386. My question is the following: What is the right way to compile unixy software on Mac OS 10.6. Is the Gtk+ library incorrectly compiled or is hsc2hs not producing its C file in the correct way? It seems that a C Gtk+ program works correctly when compiled with no special flags. The only thing we could do is to pass some magic option to hsc2hs when it creates the C program that calculates the offsets. Detecting how Gtk + was compiled would require some sort of autoconf magic which is beyond a simple cabal file. So I probably cannot hope for an easy fix. Any comments or experience appreciated, cheers, Axel ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: Please check your dependencies on fgl
Ivan Lazar Miljenovic schrieb: We considered giving it a new name (fgl', etc.) but figured that in the long term this wouldn't be advantagous. We feel that the situation is analogous to QuickCheck: when the new version came out most people kept using the old one until slowly the momentum shifted and more people started using the new version (without checking in depth, Roel's Hackage mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 reverse dependencies for QC-1.y). If we changed the name, then the emotional attachment that the Haskell community has to FGL being the de-facto graph library means that people would keep using the old version. Whilst we also face the possible problems of people not liking the old version and thus automatically dismissing the new version, I think this is a much more unlikely scenario. I'm afraid you'll destroy the emotational attachment to fgl by annoying incompatibilities (and possibly interfering new bugs). Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform). Changing a dependency in a cabal file is a small problem. Those (unaware), who only mention fgl, will fall over an incompatibility (usually at installation time!) and simple say fgl ... unless they are willing to change their code then. Those who already have fgl ... need to find an advertisement of a new and better fgl anyway and can choose when to change their code. Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Christian Maeder christian.mae...@dfki.de writes: Ivan Lazar Miljenovic schrieb: We considered giving it a new name (fgl', etc.) but figured that in the long term this wouldn't be advantagous. We feel that the situation is analogous to QuickCheck: when the new version came out most people kept using the old one until slowly the momentum shifted and more people started using the new version (without checking in depth, Roel's Hackage mirror reports QC-2.x now has 153 reverse dependencies as opposed to 127 reverse dependencies for QC-1.y). If we changed the name, then the emotional attachment that the Haskell community has to FGL being the de-facto graph library means that people would keep using the old version. Whilst we also face the possible problems of people not liking the old version and thus automatically dismissing the new version, I think this is a much more unlikely scenario. I'm afraid you'll destroy the emotational attachment to fgl by annoying incompatibilities (and possibly interfering new bugs). Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform). I'm sorry, I don't recall this discussion: care to summarise? With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes. Changing a dependency in a cabal file is a small problem. Those (unaware), who only mention fgl, will fall over an incompatibility (usually at installation time!) and simple say fgl ... unless they are willing to change their code then. Those who already have fgl ... need to find an advertisement of a new and better fgl anyway and can choose when to change their code. But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Ivan Lazar Miljenovic schrieb: [...] we don't need to repeat a parsec-2 vs parsec-3 discussion. There are obviously different opinions that cannot be easily changed. Well, I've created a custom instance: http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs and our hets project is not a hackageDB package. This looks very similar to what is currently called Data.Graph.Inductive.PatriciaTree; is there any particular reason for using your own custom variant? I guess, Data.Graph.Inductive.PatriciaTree wasn't available when I created my own instance. Furthermore, I'm using more efficient functions directly on the graph that are not available via the graph class methods. It's a very simple change, however (and arguably you and everyone should always use bounded dependencies anyway just in case of this kind of problem). Sure, I can live with either way. Arguably, changing the code may involve more time to take into account the new API. However, we aim to have sufficient advantages to the new version of fgl that people would _want_ to change. I'll rather wait and see how the new FGL will look like and then consider if re-writing is worthwhile. (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) Wow, considering that tabular-0.2.1.0 (the first in the 0.2.x series) came out over a year ago and you still haven't upgraded is a little surprising... Well, looking at our simple ascii usage, I decided to copy the used bits from the sources (one package less and its dependencies, to worry about). As a compromise, we might consider not uploading the new version of fgl to hackage (or having the developmental version use a new name, similar to how darcs has darcs-beta for testing releases) and get that package deprecated and hidden once we're satisfied and make a formal release. For me it's no big deal, if you make a new package fgl6 or make a new version fgl-6, because I'll stick to fgl-5.4.2.2 as long as I see fit. Others may complain, if their old sources no longer compile because they got fgl-6 instead of fgl-5 by whatever unintended circumstances. However, I envisage having the new version fully developed and out by the end of the year (time permitting, etc.; I want to get the API right the first time so we don't have to go through this argument again next year :p). I think, sources should go on hackageDB as soon as possible to get early feedback. Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Ivan Lazar Miljenovic schrieb: Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform). I'm sorry, I don't recall this discussion: care to summarise? http://www.haskell.org/pipermail/libraries/2010-March/013101.html With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). I usually don't want to make even small changes at installation time. The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes. Well, I've created a custom instance: http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs and our hets project is not a hackageDB package. But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. Your incentive would be a small annoyance for me since it would force me to change the dependency to fgl ... until I find time to test our code with the newer fgl version (without possible other changes). (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) Cheers Christian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? Programs which use an upper bound on their fgl dependency, as the PvP advises, won't break. A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Thanks Ian ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] Re: Please check your dependencies on fgl
Christian Maeder christian.mae...@dfki.de writes: Ivan Lazar Miljenovic schrieb: Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform). I'm sorry, I don't recall this discussion: care to summarise? http://www.haskell.org/pipermail/libraries/2010-March/013101.html I've read through that thread, but I remain unconvinced. First of all, I think there are a few misconceptions raised there (e.g. the gitit discussion is because John Macfarlane doesn't want to use Parsec-3 for Pandoc because it used to be slow and because it isn't available in Debian; this latter point shouldn't be a concern for most software IMHO; secondly, if the documentation of the 2.x series was better, then why not improve the documentation of the 3.y series?). Maintaining Haskell98 compatability may be a valid concern (I don't know how valid it is to most people, but I can see some people preferring it). _Why_ should a library remain fixed at a particular version (unless of course you are convinced it is perfect)? By creating a new package, people will keep using the old version which will eventually bit-rot rather than upgrading. There are also a few other differences between the situations here: * A lot more packages use parsec than fgl, such that the conversion process is more difficult (whereas for those packages on Hackage that use fgl, over half have already responded that they'll fix the dependency problem such that the version update won't be a problem). * The most common reason given for not upgrading to parsec-3 was efficiency; we're going to work hard to make sure that the speeds are comparable if not better (since for the most part the data structure is the same, it's just the overall API that differs in terms of how function names, etc.). * Many people liked parsec-2; the common opinion on #haskell, etc. seems to be that fgl is full of warts and many people (such as Cale) prefer to use one-off custom graph implementations (e.g. IntMap IntSet) rather than use fgl. A lot of the changes we're making to fgl comes from taking into account what people don't like about the current layout of fgl. With fgl, the actual changes aren't that big on the user side of things if they want to keep using the defaults (it's not a drop-in replacement, but the _way_ to use it remains unchanged). I usually don't want to make even small changes at installation time. But this isn't an installation time change, it's a build/develop time change. The big difference is when people want to make custom instances; however, as far as I know no-one has created any custom instances for FGL's classes. Well, I've created a custom instance: http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Common/Lib/Graph.hs and our hets project is not a hackageDB package. This looks very similar to what is currently called Data.Graph.Inductive.PatriciaTree; is there any particular reason for using your own custom variant? One thing you may like from the new fgl: proper Show, Read and Eq instances being available for graphs (since I know some people are annoyed that fgl currently doesn't have any method of serialising the graph for storage/transmission; so much so that someone has even resorted to converting the graph to/from Dot format and using that for serialisation). But by keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. If, however, we re-use the package name then it will be more obvious that there is a new and (hopefully) improved version available. Your incentive would be a small annoyance for me since it would force me to change the dependency to fgl ... until I find time to test our code with the newer fgl version (without possible other changes). It's a very simple change, however (and arguably you and everyone should always use bounded dependencies anyway just in case of this kind of problem). Arguably, changing the code may involve more time to take into account the new API. However, we aim to have sufficient advantages to the new version of fgl that people would _want_ to change. (I still haven't updated from tabular-0.1.0.2 to tabular-0.2.x, yet.) Wow, considering that tabular-0.2.1.0 (the first in the 0.2.x series) came out over a year ago and you still haven't upgraded is a little surprising... As a compromise, we might consider not uploading the new version of fgl to hackage (or having the developmental version use a new name, similar to how darcs has darcs-beta for testing releases) and get that package deprecated and hidden once we're satisfied and make a formal release. However, I envisage having the new version fully developed and out by the end of the year (time permitting, etc.; I want to get the API right the first time so we don't have to go through this argument again next year :p). -- Ivan Lazar
Re: [Haskell] Re: Please check your dependencies on fgl
ivan.miljenovic: Christian Maeder christian.mae...@dfki.de writes: Ivan Lazar Miljenovic schrieb: Although parsec-3 can be used as an replacement for parsec-2 it would have been better, they had different names (as argued elsewhere for the haskell platform). I'm sorry, I don't recall this discussion: care to summarise? http://www.haskell.org/pipermail/libraries/2010-March/013101.html I've read through that thread, but I remain unconvinced. First of all, I think there are a few misconceptions raised there (e.g. the gitit discussion is because John Macfarlane doesn't want to use Parsec-3 for Pandoc because it used to be slow and because it isn't available in Debian; this latter point shouldn't be a concern for most software IMHO; secondly, if the documentation of the 2.x series was better, then why not improve the documentation of the 3.y series?). Maintaining Haskell98 compatability may be a valid concern (I don't know how valid it is to most people, but I can see some people preferring it). _Why_ should a library remain fixed at a particular version (unless of course you are convinced it is perfect)? By creating a new package, people will keep using the old version which will eventually bit-rot rather than upgrading. If it is a complete rewrite, with a new API, in what sense is it FGL? How is it true to Erwig's design? I think it is great you want to overhaul it, but I bet that FGL 6 (or whatever) is going to break a bunch of Hackage when you upload it -- because very very few fgl users specify a version range. Can you avoid that? -- Don ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Please check your dependencies on fgl
Hey Robby, Yeah, two documents: The PVP http://www.haskell.org/haskellwiki/Package_versioning_policy The Package Addition Policy for the Haskell Platform http://trac.haskell.org/haskell-platform/wiki/AddingPackages robby: Hi all. Just thought I'd poke my head in here (perhaps where I'm not wanted...) to ask: is there a rationale and/or guidelines for how to use version numbers in hackage somewhere that I could read? I ask because we worry that similar things to this discussion would come up in PLaneT, the Racket package management scheme (if you're curious see http://planet.racket-lang.org/ for the site or http://docs.racket-lang.org/planet/index.html for the documentation). We preemptively resolved this kind of thing by tweaking the semantics of version numbers. Specifically, if you ask for version 1.3, say, of a package, PLaneT will give you the largest version that has the same major version number, ie the largest 1.x (that is compatible with the version of Racket you're using, that is). The idea was that when changes to the functionality happen, the package maintainer would bump the major number and feel safe that old uses would not break. This seems to have worked pretty well in practice, fwiw (PLaneT has been around for six years so far). (We took inspiration for this particular issue by the way we've seen major version numbers move into package names in various linux distributions.) Robby ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Ian Lynagh ig...@earth.li writes: On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. Definitely (though hopefully we wouldn't pick names like fgl-awesome anyway...). I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
On Sun, Jun 6, 2010 at 5:10 AM, Thomas Hartman tphya...@gmail.com wrote: Here's two implementations of break, a snappy one from the prelude, ... prelbreak p xs = (takeWhile (not . p) xs,dropWhile (not . p) xs) -- fast, more or less as implemented in prelude iiuc I had a look at the prelude, and I was surprised to see there's 2 versions, depending on a flag : #ifdef USE_REPORT_PRELUDE break p = span (not . p) #else -- HBC version (stolen) break _ x...@[] = (xs, xs) break p xs@(x:xs') | p x= ([],xs) | otherwise = let (ys,zs) = break p xs' in (x:ys,zs) #endif I'm curious why is it so, and which version is compiled in the platform or the ghc binaries. ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the haskell report, but the other version is faster and used by default. ) David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haddock on HP failing
Sorry, I should have said. I have installed Haskell Platform in the default place: C:\Program Files\Haskell Platform\2010.1.0.0 Chris -Original Message- From: Ivan Lazar Miljenovic [mailto:ivan.miljeno...@gmail.com] Sent: 07 June 2010 23:35 To: Chris Dornan Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Haddock on HP failing Chris Dornan ch...@chrisdornan.com writes: I am trying to use Haddock on the Haskell Platform 2010.1.0.0 and getting haddock.exe: can't find a package database at E:\ghc\ghc-6.12.1\lib\package.conf.d Where did you install GHC to (just checking...)? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] HP/Cygwin and Curl
Thanks very much: I didn't know about this resource. I do appreciate all of the hard work everyone has put in and I want to contribute myself, especially in 2011 (I am fully committed until then). For the moment the best contribution I can make is to report the problems I am having. The above wiki page is (of course) too vague about how Cygwin and MSYS can be used. Cygwin is a much better supported product and a much easier way of getting hold of many Unixy things (like X11). AFAIK MSYS doesn't have a proper installer at the moment. It would be nice to know how Cygwin can be used with HP. If the answer is not at all (for serious work) then can we say this very prominently on HP Windows page. How about linking the HP-Windows page to the Wiki article on Haskell for Windows? A FAQ for HP would also surely be useful. If others agree these would be useful and they haven't been when I will pick them up, but first, are these a good idea? My feeling is that the ramp onto Haskell is far steeper than it needs to be considering the fundamental excellence of the parts. Chris -Original Message- From: Henk-Jan van Tuyl [mailto:hjgt...@chello.nl] Sent: 07 June 2010 22:28 To: Chris Dornan Cc: Haskell-Cafe@haskell.org Subject: Re: [Haskell-cafe] HP/Cygwin and Curl On Mon, 07 Jun 2010 21:44:13 +0200, Chris Dornan ch...@chrisdornan.com wrote: Thanks ever so much for your clear answer. I have no problem at all with using MSYS to build libraries that link to libraries built in Windows land--this seems entirely reasonable. Is this written down somewhere? I mean I really would like to RTFM! :-) Some information can be found at: http://www.haskell.org/haskellwiki/Windows#Tools_for_compilation (improvements are welcome) Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Stone age programming for space age hardware?
Hi, The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. for some safety critical applications that require certification, SCADE with the underlying Lustre language is used. It has formal semantics and some properties can be checked with automatic verification (up to linear arithmetic). The Lustre dataflow programs are then transformed to C (or Ada), by compiling to automata and representing those in C. This transformation is realized in Ocaml afaik. I think these kind of transformations, maybe specifying an embedded DSL instead of using a language like Lustre resulting in C with static bounds etc. could be a way to use Haskell. But anything using dynamic memory allocation, GC etc. is dangerous for real-time bounds. These programs also often run on old outdated, but reliable HW for which mainly C compilers exist. The used standards only allow a certain set of programming languages (or subsets of these languages) and you even have to use proved and tested compilers and tools. I have a hunch that the real restrictions of this kind of software are not concerned with fixed memory, iterations, whatever, but rather with guaranteed bounds. If that is indeed the case, how feasible would it be to prove relevant properties for systems programmed in Haskell? I think proving the correct transformation of some input language to static C using Haskell is possible. Functional languages like Haskell or Ocaml in the case of SCADE are well suited to this, due to lack of loops, side effects etc. I think atom is such a DSL embedded into Haskell that can generate code for real-time systems. regards Matthias ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
R J wrote: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PDF generation?
The fonts aren't rasterized, but PDFs that were converted from PS tend to look awful in almost any PDF viewer other than Adobe's Acrobat Reader. Fonts look especially bad. I don't know exactly what the problem is, but my experience is that you are best off generating PDF directly, and using Acrobat Reader on any document that looks bad otherwise. Not to mention that PDF has a document model and supports things such as hyperlinks, which Postscript does not, which is another reason to avoid PostScript. Best, Leon On Tue, Jun 1, 2010 at 2:45 PM, Yitzchak Gale g...@sefer.org wrote: I wrote: I have often generated PostScript from Haskell... Then you convert the PS to PDF using any of the nice utilities around for that Pierre-Etienne Meunier wrote: Isn't there a problem with non-type 1 vectorial fonts being rasterized during this conversion ? No. PDF is just a simplified, compressed encoding of PostScript. Unless there is some special reason to do so, why would a conversion utility go to the trouble of rasterizing fonts instead of just copying them in? Perhaps something like ImageMagick might do that; its internal format is a raster. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Fwd: [Gtk2hs-users] Installation problem with cairo.
Hi, I cannot subscribe to libraries maillist. So I forward this here. I cannot install gtk2hs-cairo by cabal using cairo 1.9.6 compiled myself. Cabal always said that the cairo library/devel files were missing. -- Forwarded message -- From: Axel Simon axel.si...@in.tum.de Date: Tue, Jun 8, 2010 at 7:15 PM Subject: Re: [Gtk2hs-users] Installation problem with cairo. To: Magicloud Magiclouds magicloud.magiclo...@gmail.com Cc: gtk2hs-users gtk2hs-us...@lists.sourceforge.net Hi again, it's very difficult for me to say what is happening. Could you ask on the cabal mailing list to see if anybody there has an idea. Cheers, Axel On 08.06.2010, at 11:01, Magicloud Magiclouds wrote: I've tried a little, the error was not thrown out in gtk2hssetup.hs. And even I faked a version (1.8.10), it did not work. On Tue, Jun 8, 2010 at 3:47 PM, Axel Simon axel.si...@in.tum.de wrote: Hi, On Jun 8, 2010, at 9:21, Magicloud Magiclouds wrote: Yes, seems like so. Here is the output: # /usr/bin/pkg-config --modversion cairo-pdf 1.9.6 # /usr/bin/pkg-config --modversion cairo-ps 1.9.6 # /usr/bin/pkg-config --modversion cairo-svg 1.9.6 # /usr/bin/pkg-config --modversion cairo 1.9.6 Oh dear. Since cabal manages once to get the correct version and fails later on, I assume it's the magic Duncan added to out Gtk2HsSetup.hs file that requests the package version again. If you look for --FIXME: Cabal should tell us the selected pkg-config package versions in the -- LocalBuildInfo or equivalent. -- In the mean time, ask pkg-config again. in the cabal file and try to add some debugging output then maybe you can find out more. I suspect that either the LocalBuildInfo or the PackageDescription value is not the most up-to-date one but some default value that lack some path or some such. cheers, Axel On Tue, Jun 8, 2010 at 2:56 PM, Axel Simon axel.si...@in.tum.de wrote: Hi, On Jun 8, 2010, at 8:54, Magicloud Magiclouds wrote: /usr/bin/pkg-config --modversion cairo setup: Missing dependency on a foreign library: * Missing C library: cairo This problem can usually be solved by installing the system package that provides this library (you may need the -dev version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. well, what's the output of /usr/bin/pkg-config --modversion cairo ? Maybe cabal fails to parse the version for some reason. Axel -- 竹密岂妨流水过 山高哪阻野云飞 -- 竹密岂妨流水过 山高哪阻野云飞 -- 竹密岂妨流水过 山高哪阻野云飞 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... 2010/6/8 Yitzchak Gale g...@sefer.org: R J wrote: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function to find a substring
R J wrote: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? Thomas Hartman wrote: If you want to use libs to make your life easier, maybe something along these lines? Prelude Data.List.Split Safe ... True, those are both very nice libraries. It's just about as easy to do this with the more standard ones, though: Prelude Data.List Data.Maybe listToMaybe . map fst . filter ((asdf `isPrefixOf`) . snd) . zip [0..] . tails $ blee blah asdf bloo Just 10 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
This isn`t a manifestation of the Curry-Howard isomorphism? 2010/6/8 Alexander Solla a...@2piix.com On Jun 7, 2010, at 4:10 PM, Alexander Solla wrote: You might note how much like evaluating the function generating the analysis is. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
Hello David, Tuesday, June 8, 2010, 10:33:51 AM, you wrote: ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the haskell report, but the other version is faster and used by default. ) you are right -- Best regards, Bulatmailto:bulat.zigans...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
if we add 'a' to the definition of this function, (to make it work), the type of it turns out to be: [a] - [(a, Bool)] you might have forgotten the map fst $ part. Best, On 8 June 2010 14:51, Bill Atkins watk...@alum.rpi.edu wrote: f :: [a] - [a] f = filter snd $ zip a (cycle [True, False]) On Monday, June 7, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: or, since you don't need to give a name to the second element of the list: f :: [a] - [a] f (x:_:xs) = x : f xsf x = x On 7 June 2010 20:11, Ozgur Akgun ozgurak...@gmail.com wrote: i think explicit recursion is quite clean? f :: [a] - [a]f (x:y:zs) = x : f zs f x = x On 7 June 2010 19:42, Thomas Hartman tphya...@gmail.com wrote: maybe this? map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5] 2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun -- Ozgur Akgun -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
f :: [a] - [a] f = filter snd $ zip a (cycle [True, False]) On Monday, June 7, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: or, since you don't need to give a name to the second element of the list: f :: [a] - [a] f (x:_:xs) = x : f xsf x = x On 7 June 2010 20:11, Ozgur Akgun ozgurak...@gmail.com wrote: i think explicit recursion is quite clean? f :: [a] - [a]f (x:y:zs) = x : f zs f x = x On 7 June 2010 19:42, Thomas Hartman tphya...@gmail.com wrote: maybe this? map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5] 2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
From: Don Stewart d...@galois.com ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the Which version of QuickCheck should I use? problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. My 2 cents, anyway. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Function to find a substring
What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? my quick take, with Maybe and fmap : substringP :: String - String - Maybe Int substringP _ [] = Nothing substringP sub str = case isPrefixOf sub str of False - fmap (+1) $ substringP sub (tail str) True - Just 0 -- Paul ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
jwlato: From: Don Stewart d...@galois.com ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the Which version of QuickCheck should I use? problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cabal problem on OS X
Did you manage to fix this problem, or are there any updates on it? I am now having the same issue - presumably due to updating my Mac OS X version, because cabal was working fine before that. I can't upgrade cabal or install anything either, same reason. Gordon J. Uszkay uszka...@mcmaster.ca On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote: Bill Atkins watk...@alum.rpi.edu writes: When I run cabal update on my Mac (Snow Leopard, Intel), I get: % cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version I'm going to randomly guess that the version of the C zlib library that Cabal was indirectly built against is different to the one on your machine. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
And for a few more lines of codes, you get a more flexible solution: data Consume = Take | Skip consumeBy :: [Consume] - [a] - [a] consumeBy [] _ = [] consumeBy _[] = [] consumeBy (tOrS:takesAndSkips) (x:xs) = case tOrS of Take - x : consumeBy takesAndSkips xs Skip - consumeBy takesAndSkips xs *Main consumeBy (cycle [Take,Take,Skip]) [1,2,3,4,5,6] [1,2,4,5] *Main consumeBy (cycle [Take,Take,Take,Skip]) [1,2,3,4,5,6] [1,2,3,5,6] -deech On 6/8/10, Christopher Done chrisd...@googlemail.com wrote: Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... 2010/6/8 Yitzchak Gale g...@sefer.org: R J wrote: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f = map head . takeWhile (not . null) . iterate (drop 2) . drop 1 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
On Tuesday 08 June 2010 08:33:51, David Virebayre wrote: On Sun, Jun 6, 2010 at 5:10 AM, Thomas Hartman tphya...@gmail.com wrote: Here's two implementations of break, a snappy one from the prelude, ... prelbreak p xs = (takeWhile (not . p) xs,dropWhile (not . p) xs) -- fast, more or less as implemented in prelude iiuc I had a look at the prelude, and I was surprised to see there's 2 versions, depending on a flag : #ifdef USE_REPORT_PRELUDE break p = span (not . p) #else -- HBC version (stolen) break _ x...@[] = (xs, xs) break p xs@(x:xs') | p x= ([],xs) | otherwise = let (ys,zs) = break p xs' in (x:ys,zs) #endif I'm curious why is it so, and which version is compiled in the platform or the ghc binaries. ( my guess is USE_REPORT_PRELUDE compiles functions as defined in the haskell report, but the other version is faster and used by default. ) Aye. I'm not sure whether there's a difference with -O2, but it's substantial without optimisations. David. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL a similar opportunity is present with 'fgl', where the new maintainers are seeking to improve the code. Below I try to summarise the pros and cons of calling the new rewrite/api 'fgl', in the hope we can identify a path that minimizes disruption to users. A group of developers is planning to write a new graph library for Haskell. * They maintain an existing package called 'fgl'. * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/ * The new library will have different authors and a different API. * They would like the new library 'fgl'. It is a controversial step to write a new library and give it the same name as an existing, famous library. Let's look at the arguments. = Reasons to use the new name = * The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption. * Rewrites are effective if the name is preserved. E.g. QuickCheck 2. * It is the maintainer's right to modify APIs as they see fit. * Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. * Relatively few packages use fgl. So damage is limited. = Reasons not to use the name = * Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct * Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us. * The package has been stable for ~10 years -- why change a stable API? It is already perfect * The new package really isn't the same package in any sense. * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3) * No additional breakages are introduced. * If you weren't maintainer of 'fgl' this rewrite wouldn't even be possible to call 'fgl' -- there's a conflict of interest. * Maintaining Haskell98 compatability. Keep it simple. (See regex-posix's mistakes here) * Distros that support the Haskell Platform will have to keep an old version of fgl around for a long time anyway. Are there any other arguments I'm missing? -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
On Tue, Jun 8, 2010 at 4:13 PM, Don Stewart d...@galois.com wrote: jwlato: From: Don Stewart d...@galois.com ivan.miljenovic: Thomas Bereknyei are currently re-writing fgl (just about completely from scratch) and we plan to make an initial release to get feedback on the API in the next few weeks. However, I'm sending this email out now to warn people that I highly doubt any code that was written for the current version of fgl (http://hackage.haskell.org/package/fgl-5.4.2.2) will work with the new version. How about you give the library a different name then -- so as not to break all those programs? A complete rewrite with a new maintainer: fgl-awesome I would like to argue against this practice, i.e. re-naming new, incompatible versions of existing packages. I think it's bad for the following reasons: 1. It makes development by new users more difficult by fracturing the package-space (the Which version of QuickCheck should I use? problem). Since this is already an acknowledged issue, I think it's better that developers not add to it. 2. It discourages adoption of the latest version despite any benefits the later version may provide. This also leads to greater incompatibility between dependent packages. 3. For packages in the platform, I believe this will create uncertainty about which package(s) should be included with new major releases. 4. It adds to the maintainer workload as the same person or team will often be responsible for both packages. I do agree that there are legitimate reasons why users may decide to remain with older versions, however I think that in nearly all cases the proper solution is to follow the PVP and for users to include upper dependency bounds in .cabal files. In particular, for the very common case of compatibility with older code, an upper dependency bound seems like the correct approach. IMHO changing a package name should be for when developers intend to continue development (not just maintenance releases) along both branches. Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan. Thanks very much; that's a useful page. It highlights some points I hadn't considered, such as when the original author is no longer involved with substantial changes to the code. Hopefully a productive discussion will follow. I don't think a one-size-fits-all approach is appropriate, but it would be nice if the community could come to some common recommendations on this topic. Also, to everyone working on fgl: I certainly don't mean to single out your work as an example, however I think your contributions to this discussion are very helpful as it's a current issue for you. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function to find a substring
Hi, R J wrote: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? The naive algorithm of matching the second string on every position of the first string can be implemented as follows. import Data.List (findIndex, tails) findSubstringIndex text pattern = findIndex (pattern `isPrefixOf`) (tails text) Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? f x = [y | (True, y) - zip (cycle [False, True]) x] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HP/Cygwin and Curl
Thanks Stephen--that was related to my original question, about using HP with Cygwin. The answer seems to be No!--you must use MSYS (for real work). The short version: - Cygwin provides commandline tools, compilers and libraries - MSYS provides commandline tools for the MinGW compilers and libraries You can use the commandline tools from either Cygwin or MSYS, but you need to compile and link with the compilers and libraries from MinGW. Cygwin's gcc produces binaries that live in a unix-emulation on top of windows, and depend on a cygwin dll to act as a translator. MinGW's gcc produces native windows binaries. Claus http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Function to find a substring
El dom, 06-06-2010 a las 15:51 +, R J escribió: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? import Data.List f a b = findIndex (a `isPrefixOf`) (tails b) Jürgen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Execution call graph pruning
Hi, I have a call grah which contains information of the edges in the following format caller callee count (time spent by the caller) === foo bar 10100 xxx yyy 2010 zzz yyy 1010 (I used pintool pintool.org to generate this call graph) Now, the problem is that the graph is huge and it take a long to render using 'dot' or use any visualizing tool. Even if they render, it's too cluttered to be useful. I wanted to prune the graph in such a way that I'd have only the edges corresponding to the top 10% of the time consumers. What would be a good way to do such a thing? Has anyone written some utility that I could use? -- Regards, Kashyap ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Updates in the regions library
Hi Arie (and others who are interested in the regions library),
I would like to let you know that I'm working on a new version of my
regions package and its reverse dependencies:
regions-monadsfd, regions-monadstf,
safer-file-handles, regional-pointers and usb-safe.
The major change is that I removed the Resource class:
class Resource resource where
data Handle resource ∷ *
open ∷ resource → IO (Handle resource)
close ∷ Handle resource → IO ()
in favor of a much more simple interface, namely:
-- | An 'IO' computation that closes or finalizes a resource. For example
-- 'hClose' or 'free'.
type CloseAction = IO ()
-- | A handle to a 'CloseAction' that allows you to duplicate the action to a
-- parent region using 'dup'.
newtype CloseHandle (r ∷ * → *)
-- | Register the 'CloseAction' in the region. When the region terminates all
-- registered close actions will be perfomed if they're not duplicated to a
-- parent region.
register ∷ MonadIO pr ⇒ CloseAction → RegionT s pr (CloseHandle (RegionT s pr))
Here's an example how to use this new interface from my updated
regional-pointers package:
import qualified Foreign.Marshal.Alloc as FMA
-- | A regional handle to memory. This should provide a safer replacement for
-- Foreign.Ptr.Ptr
data RegionalPtr α (r ∷ * → *) = RegionalPtr (Ptr α) (CloseHandle r)
{-| Allocates the given number of bytes and returns a
regional pointer to them.
This should provide a safer replacement for:
Foreign.Marshal.Alloc.mallocBytes.
-}
mallocBytes ∷ MonadCatchIO pr
⇒ Int
→ RegionT s pr (RegionalPtr α (RegionT s pr))
mallocBytes size = block $ do
ptr ← liftIO $ FMA.mallocBytes size
let closeAction = free ptr
ch ← register closeAction
return $ RegionalPtr ptr ch
And here's an example from safer-file-handles:
-- | A regional handle to an opened file parameterized by the 'IOMode' in which
-- you opened the file and the region in which it was created.
data RegionalFileHandle ioMode (r ∷ * → *) =
RegionalFileHandle (Handle ioMode) (CloseHandle r)
openFile ∷ MonadCatchIO pr
⇒ FilePath
→ IOMode ioMode
→ RegionT s pr
(RegionalFileHandle ioMode (RegionT s pr))
openFile = openNormal E.openFile
-- | Opens a file in binary mode then yields a regional handle to it. This
-- provides a safer replacement for System.IO.openBinaryFile.
openBinaryFile ∷ MonadCatchIO pr
⇒ FilePath
→ IOMode ioMode
→ RegionT s pr
(RegionalFileHandle ioMode (RegionT s pr))
openBinaryFile = openNormal E.openBinaryFile
openNormal ∷ MonadCatchIO pr
⇒ (FilePath → IOMode ioMode → IO (E.Handle ioMode))
→ FilePath
→ IOMode ioMode
→ RegionT s pr
(RegionalFileHandle ioMode (RegionT s pr))
openNormal open filePath ioMode = block $ do
h ← liftIO $ open filePath ioMode
let closeAction = sanitizeIOError $ hClose h
ch ← register closeAction
return $ RegionalFileHandle h ch
I haven't released it yet because I need to write some more
documentation. However all the repositories contain the new code:
darcs get http://code.haskell.org/~basvandijk/code/regions
darcs get http://code.haskell.org/~basvandijk/code/regions-monadsfd
darcs get http://code.haskell.org/~basvandijk/code/regions-monadstf
darcs get http://code.haskell.org/~basvandijk/code/regional-pointers
darcs get http://code.haskell.org/~basvandijk/code/safer-file-handles
darcs get http://code.haskell.org/~basvandijk/code/usb-safe
and some examples:
darcs get http://code.haskell.org/~basvandijk/code/usb-safe-examples
darcs get http://code.haskell.org/~basvandijk/code/safer-file-handles-examples
darcs get
http://code.haskell.org/~basvandijk/code/usb-safe-and-safer-file-handles-examples
Regards,
Bas
On Wed, Jun 2, 2010 at 3:13 PM, Bas van Dijk v.dijk@gmail.com wrote:
On Wed, Jun 2, 2010 at 2:57 PM, Arie Peterson ar...@xs4all.nl wrote:
On Wed, Jun 2, 2010 at 2:28 PM, Bas van Dijk v.dijk@gmail.com
wrote:
Before answering your questions I would like to make sure I understand
your Resource type. When I want to create a memory Resource for
example is the following what you have in mind?
{-# LANGUAGE Rank2Types #-}
-- from base:
import Foreign.Ptr ( Ptr )
import Foreign.Marshal.Alloc ( mallocBytes, free )
-- from transformers:
import Control.Monad.IO.Class ( liftIO )
-- from MonadCatchIO-transformers:
import Control.Monad.CatchIO ( MonadCatchIO, bracket )
newtype Resource cap m = Resource { with :: forall a. (cap - m a) - m
a }
type Memory m a = Resource (Ptr a) m
memory :: MonadCatchIO m = Int - Memory m a
memory size = Resource $ bracket (liftIO $ mallocBytes size) (liftIO .
free)
Yes, exactly. I also create type aliases for resources providing a
specific capability.
On Wed, 2 Jun 2010 14:45:08 +0200, Bas van Dijk v.dijk@gmail.com
wrote:
Re: [Haskell-cafe] Removing alternate items from a list
Yes, this was an old draft I accidentally sent out. My post higher up the thread is correct. :) On Tuesday, June 8, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: if we add 'a' to the definition of this function, (to make it work), the type of it turns out to be: [a] - [(a, Bool)] you might have forgotten the map fst $ part. Best, On 8 June 2010 14:51, Bill Atkins watk...@alum.rpi.edu wrote: f :: [a] - [a] f = filter snd $ zip a (cycle [True, False]) On Monday, June 7, 2010, Ozgur Akgun ozgurak...@gmail.com wrote: or, since you don't need to give a name to the second element of the list: f :: [a] - [a] f (x:_:xs) = x : f xsf x = x On 7 June 2010 20:11, Ozgur Akgun ozgurak...@gmail.com wrote: i think explicit recursion is quite clean? f :: [a] - [a]f (x:y:zs) = x : f zs f x = x On 7 June 2010 19:42, Thomas Hartman tphya...@gmail.com wrote: maybe this? map snd . filter (odd . fst) . zip [1,2..] $ [1,2,3,4,5] 2010/6/6 R J rj248...@hotmail.com: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? The New Busy is not the old busy. Search, chat and e-mail from your inbox. Get started. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ozgur Akgun -- Ozgur Akgun -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
On 8 June 2010 15:13, Jürgen Doser jurgen.do...@gmail.com wrote: El dom, 06-06-2010 a las 14:46 +, R J escribió: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? adding another suggestion: import Data.Either(rights) f = rights . zipWith ($) (cycle [Left,Right]) Ohhh. Nice. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package naming policy (was: Please check your dependencies on fgl)
jwlato: Great points: I've added them to this wiki page of for and against points: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename Please add points as you see fit, and maybe we can come up with a mitigation/change plan. Thanks very much; that's a useful page. It highlights some points I hadn't considered, such as when the original author is no longer involved with substantial changes to the code. Hopefully a productive discussion will follow. I don't think a one-size-fits-all approach is appropriate, but it would be nice if the community could come to some common recommendations on this topic. Also, to everyone working on fgl: I certainly don't mean to single out your work as an example, however I think your contributions to this discussion are very helpful as it's a current issue for you. Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
Hello The regular list functionals - map, zip, foldl, foldr, filter, etc. - all process the input list at speed 1 - i.e. one element at a time. As Ozgur Akgun has shown - consuming the list at speed 2 gives a very pleasant implementation - algorithmically: consume at speed 2, produce the new list with the first element of the two and drop the second. Trying to code an algorithm at speed 1 with the list functionals presents a significant hurdle towards clarity of exposition... Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
El dom, 06-06-2010 a las 14:46 +, R J escribió: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? adding another suggestion: import Data.Either(rights) f = rights . zipWith ($) (cycle [Left,Right]) Jürgen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
It only works for infinite lists, though
you wanted it :)
(fix $ \f xs - case xs of { (x:_: xs) - x : f xs; _ - [] }) [1..10]
= [1,3,5,7,9]
here you go :)
2010/6/8 Yitzchak Gale g...@sefer.org
Christopher Done wrote:
Can't forget fix in a game of code golf!
(fix $ \f (x:_: xs) - x : f xs) [1..]
= [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4...
Ho, good shot! It only works for infinite lists, though:
Prelude (fix $ \f (x:_: xs) - x : f xs) [1..10]
[1,3,5,7,9*** Exception: interactive:1:7-30: Non-exhaustive patterns in
lambda
Regards,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Ozgur Akgun
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stone age programming for space age hardware?
Michael Schuerig wrote: I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. After all, the question is this: why use C if you don't actually use C? The reason is probably that designing/writing a proper DSL is considered too error prone, but with today's theorem provers, this should no longer be the case. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: haskell.org down?
I saw on the Reddit page that people urged caution about the costs of hosting haskell.org commercially. This was a jest wasn't it? ( The cost of webhosting is absurdly cheap, by almost any standards.) I would be very happy to help out here but time (where the true costs lie) is my main concern. If it's still a problem in the new year I will look into it. Seriously--this is unnecessary and harmful. Chris -Original Message- From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Vo Minh Thu Sent: 08 June 2010 04:04 To: Benjamin L. Russell Cc: haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] Re: haskell.org down? 2010/6/7 Benjamin L. Russell dekudekup...@yahoo.com: Ozgur Akgun ozgurak...@gmail.com writes: http://downforeveryoneorjustme.com/www.haskell.org-- Ozgur Akgun Same problem here since two days ago. Apparently, the server just went back up. Anybody know what kept the server down for so long? http://www.reddit.com/r/haskell/comments/cbkkb/wwwhaskellorg_wiki_mailing_li st_server_has_been/ Cheers, Thu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Function to find a substring
R J rj248...@hotmail.com writes: What's an elegant definition of a Haskell function that takes two strings and returns Nothing in case the first string isn't a substring of the first, or Just i, where i is the index number of the position within the first string where the second string begins? f n h = listToMaybe [b | (a,b)- tails h `zip` [1..], n `isPrefixOf` a] seems plausible, but how do you define elegant? -- Jón Fairbairn jon.fairba...@cl.cam.ac.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
Christopher Done wrote: Can't forget fix in a game of code golf! (fix $ \f (x:_: xs) - x : f xs) [1..] = [1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31,33,35,37,39,41,4... Ho, good shot! It only works for infinite lists, though: Prelude (fix $ \f (x:_: xs) - x : f xs) [1..10] [1,3,5,7,9*** Exception: interactive:1:7-30: Non-exhaustive patterns in lambda Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing alternate items from a list
OK, here's mine: f as = [ x | (True,x) - zip (cycle [True, False]) as ] -md begin R J quotation: What's the cleanest definition for a function f :: [a] - [a] that takes a list and returns the same list, with alternate items removed? e.g., f [0, 1, 2, 3, 4, 5] = [1,3,5]? _ The New Busy is not the old busy. Search, chat and e-mail from your inbox. http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
Hello all While new libraries develop at pace, their documentation rarely does; so I'd have to disagree with John's claim that re-naming libraries makes development by new users harder. I'd argue that having tutorials not work for later revisions is more confusing than having various packages doing the same thing. I'd also contend that beginners are better off lagging behind the cutting edge and using Parsec 2, QuickCheck 1, Haskore-vintage, as the earlier version all have comprehensive documentation - Parsec 2 and Haskore have extensive manual/tutorials, QuickCheck 1 was small enough that the original QuickCheck paper covered its use. An advantage of separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time - the old one to work with while learning the package, the new one if other installed packages depend on it. This can still be done with package-hiding but its less straight-forward. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
On 06/08/10 11:08, Don Stewart wrote: Are there any other arguments I'm missing? Also parsec3 had an issue as an upgrade that it was slower at runtime (at least for a few years). (and some people were using parsec in the real world for performance-critical applications.) -Isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is there a way to prove the equivalence of these two implementations of (Prelude) break function?
On Jun 8, 2010, at 2:38 AM, Alberto G. Corona wrote: This is`t a manifestation of the Curry-Howard isomorphism? Yes, basically. If we rephrase the isomorphism as a proof is a program, the formula it proves is a type for the program (as Wikipedia states it), we can see the connection. The characterization of prelBreak I gave is a type for prelBreak. The type is richer than we can express in the Haskell type system (prelbreak accepts a proposition p and a list xs, and returns a pair whose first element is the largest prefix of xs for which no x satisfies p, and whose second element is the complement of the first, taken in xs.), but we can still reason about the richer type mathematically, and the Curry-Howard isomorphism applies to it.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Stone age programming for space age hardware?
On Tuesday 08 June 2010, Heinrich Apfelmus wrote: Michael Schuerig wrote: I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. That suggestion is similar to the approach taken by verifiable languages, as Matthias describes it in a parallel reply. Now, the interesting question is, whether it is possible to define a DSL that's expressive enough and still can be translated to a very restrictive subset of C. I wouldn't expect the on-board functionality of a space probe or rover to be trivial. I think it would count as cheating if you compile down a DSL to C code that only takes a fixed chunk of memory, but then itself manages blocks of that memory dynamically. After all, the question is this: why use C if you don't actually use C? The reason is probably that designing/writing a proper DSL is considered too error prone, but with today's theorem provers, this should no longer be the case. As I understood Holzmann in his talk, use of C is a kind of cultural heritage at JPL. BTW, thanks for your recent video on GADTs. Michael -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg On Jun 8, 2010, at 11:08 AM, Gene A wrote: On Tue, Jun 8, 2010 at 8:08 AM, Don Stewart d...@galois.com wrote: (... There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL ...) (... * No additional breakages are introduced. ...) Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! cheers, gene ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
On Tuesday 08 June 2010 20:21:54, Gregory Crosswhite wrote: Or you just put an upper bound on the versions of the fgl library that your program will build against, as you should be doing anyway, and then nothing breaks. Cheers, Greg Right. At least, nothing breaks until the next compiler release makes the old library break. But a new package name wouldn't help with that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Stone age programming for space age hardware?
That's interesting, writing a DSL that compiles to C. I've actually inerviewed Gerard Holzamann twice, the first time when he received the ACM Software System Award in 2002 [1] and in 2008 after he moved to JPL [2]. What they use to test distributed software is the Process Meta Language (Promela) which models communication between distributed processes. Now Spin checks all possible models for deadlock, liveness etc. You can also use asserts to test conditions, just as in C. It also uses LTL (linear temporal logic) to formulate statements like, will the railroad crossing always eventually open and such. Two articles about Spin are [3] and [4]. Unfortunately, all four are in Dutch, but, hey, surely somebody here must be able to read that language g. The articles on Spin contain listings in Promela. Now, what Gerard Holzmann told me in the interview, is that NASA is very conservative in it's use of software tools. They don't use C++, just C, and a well defined version of the GNU C compiler at that. The coding standards, which even prohibit the use of C pointers, are aimed to keep everything as simple as possible. Just imagine hundreds of people working over many years to produce code where any error, how trivial it may be, will occur millions of miles away, cost hundreds of millions of dollars, and could damage the reputation of the company and its future funding. Now, if you can use a DSL to make embedded software absolutely failsafe, that would certainly grab NASA's attention. But again, they are very conservative, it seems... [1] http://muitovar.com/pub/pdf/holzmann.pdf [2] http://muitovar.com/pub/pdf/acmaw.pdf [3] http://muitovar.com/pub/pdf/spin1.pdf [4] http://muitovar.com/pub/pdf/spin2.pdf On Tue, 2010-06-08 at 18:27 +0200, Heinrich Apfelmus wrote: Michael Schuerig wrote: I was dumbfounded, although I have known all this. I have no personal experience with either embedded or real time software, but I've been aware that C still is the most popular language for that purpose and that coding standards are very restrictive. The real reason behind my surprise was, that I was wondering how more modern languages could make inroads into such an environment. Haskell without recursion and dynamic memory allocation? Hard to imagine. I have absolutely no experience with real time system, but if I were tasked to write with these coding standards, I would refuse and instead create a small DSL in Haskell that compiles to the requested subset of C. After all, the question is this: why use C if you don't actually use C? The reason is probably that designing/writing a proper DSL is considered too error prone, but with today's theorem provers, this should no longer be the case. Regards, Heinrich Apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Proposal to solve Haskell's MPTC dilemma
Sorry for reopening an old thread, but I thought I'd counter some of the negative feedback :) I think this proposal is a great idea! It seems like this would make working with MPTCs much easier. When programming, I generally want to only specify the minimum amount of information to make my code logically unambiguous. If the code contains enough information to infer the proper instantiation without the use of an FD, then I shouldn't need to add a FD. It seems like this would have much more of a it just works feel than the currently alternatives. Also the MPTC + FDs type errors are a pain. I'm not sure if the type errors for your proposal would be better, but it would be hard to make them worse. I do worry about imported instances, (over which we currently have little control) messing up our code. But this would probably be pretty unusual and I feel that this is more of a problem with how instances are imported than with this proposal itself. Anyway, just my two cents, - Job On Thu, May 20, 2010 at 10:34 AM, Carlos Camarao carlos.cama...@gmail.comwrote: This message presents, informally, a proposal to solve Haskell's MPTC (multi-parameter type class) dilemma. If this informal proposal turns out to be acceptable, we (I am a volunteer) can proceed and make a concrete proposal. The proposal has been published in the SBLP'2009 proceedings and is available at www.dcc.ufmg.br/~camarao/CT/solution-to-MPTC-dilemma.pdfhttp://www.dcc.ufmg.br/%7Ecamarao/CT/solution-to-MPTC-dilemma.pdf The well-known dilemma (hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma) is that it is generally accepted that MPTCs are very useful, but their introduction is thought to require the introduction also of FDs (Functional Dependencies) or another mechanism like ATs (Associated Types) and FDs are tricky and ATs, somewhat in a similar situation, have been defined more recently and there is less experience with its use. In www.haskell.org/ghc/dist/current/docs/html/users_guide/type-class-extensions.html there exists a solution to the termination problem related to the introduction of MPTCs in Haskell. In our proposal, neither FDs nor any other mechanism like ATs are needed in order to introduce MPTCs in Haskell; the only change we have to make is in the ambiguity rule. This is explained below. The termination problem is essentially ortogonal and can be dealt with, with minor changes, as described in the solution presented in the above mentioned (type-class-extensions) web page. Let us review the ambiguity rule used in Haskell-98 and after that the ambiguity rule used in GHC. Haskell-98 ambiguity rule (which is adequate for Haskell-98's single parameter type classes) is: a type C = T is ambiguous iff there is a type variable v that occurs in the context (constraint set) C but not in the simple (unconstrained) type T. For example: forall a.(Show a, Read a)=String is ambiguous, because a occurs in the constraints (Show a,Read a) but not in the simple type (String). In the context of MPTCs, this rule alone is not enough. Consider, for example (Example 1): class F a b where f:: a-b class O a where o:: a and k = f o:: (C a b,O a) = b Type forall a b. (C a b,O a) = b can be considered to be not ambiguos, since overloading resolution can be defined so that instantiation of b can determine that a should also be instantiated (as FD b|-a does), thus resolving the overloading. GHC, since at least version 6.8, makes significant progress towards a definition of ambiguity in the context of MPTCs; GHC 6.10.3 User’s Guide says (section 7.8.1.1): GHC imposes the following restrictions on the constraints in a type signature. Consider the type: forall tv1..tvn (c1, ...,cn) = type. ... Each universally quantified type variable tvi must be reachable from type. A type variable a is reachable if it appears in the same constraint as either a type variable free in the type, or another reachable type variable.” For example, type variable a in constraint (O a) in the example above is reachable, because it appears in (C a b) (the same constraint as type variable b, which occurs in the simple type). Our proposal is: consider unreachability not as indication of ambiguity but as a condition to trigger overloading resolution (in a similar way that FDs trigger overloading resolution): when there is at least one unreachable variable and overloading is found not to be resolved, then we have ambiguity. Overloading is resolved iff there is a unique substitution that can be used to specialize the constraint set to one, available in the current context, such that the specialized constraint does not contain unreachable type variables. (A formal definition, with full details, is in the cited SBLP'09 paper.) Consider, in Example 1, that we have a single instance of F and O, say: instance F Bool Bool where f = not instance O Bool where o =
[Haskell-cafe] Re: Stone age programming for space age hardware?
On Tuesday 08 June 2010, Hans van Thiel wrote: Now, what Gerard Holzmann told me in the interview, is that NASA is very conservative in it's use of software tools. They don't use C++, just C, and a well defined version of the GNU C compiler at that. The coding standards, which even prohibit the use of C pointers, are aimed to keep everything as simple as possible. Just imagine hundreds of people working over many years to produce code where any error, how trivial it may be, will occur millions of miles away, cost hundreds of millions of dollars, and could damage the reputation of the company and its future funding. Perhaps it's just my lack of imagination that was driving my original question. I'm just having a hard time imagining how to write reasonably interesting algorithms that way. As I wrote, they might cheat. It's entirely possible to implement dynamic memory on top of fixed-size arrays and use indexes instead of pointers. Of course, I have no idea if that's what they do. Michael -- Michael Schuerig mailto:mich...@schuerig.de http://www.schuerig.de/michael/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] HP/Cygwin and Curl
Thanks Claus,
Your condensed summary was my understanding, but if I try to issue
Cabal install --reinstall cmu
It works every time from a MSYS shell, but with Cygwin I get
Linking dist\build\cmu\cmu.exe ...
C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres:
can't open temporary file `\/cca04932.irc': No such file or directory
cabal.exe: Error: some packages failed to install:
cmu-1.2 failed during the building phase. The exception was:
ExitFailure 1
('cmu' is just an example; the same behaviour seems apparent whatever the
package; I see something very similar when I ask GHC to compile hello.hs.)
The general answer I seem to have been getting (and responses I have seen
elsewhere top this problem) is 'don't expect the Haskell tools to work with
Cygwin'.
At any rate it seems that, for some people at least, the latest version of
the Haskell tools won't work when launched from Cygwin Bash.
Chris
-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Claus Reinke
Sent: 08 June 2010 09:02
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] HP/Cygwin and Curl
Thanks Stephen--that was related to my original question, about using
HP with Cygwin. The answer seems to be No!--you must use MSYS (for
real work).
The short version:
- Cygwin provides commandline tools, compilers and libraries
- MSYS provides commandline tools for the MinGW compilers and libraries
You can use the commandline tools from either Cygwin or MSYS, but you need
to compile and link with the compilers and libraries from MinGW.
Cygwin's gcc produces binaries that live in a unix-emulation on top of
windows, and depend on a cygwin dll to act as a translator. MinGW's gcc
produces native windows binaries.
Claus
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HP/Cygwin and Curl
Your condensed summary was my understanding, but if I try to issue
Cabal install --reinstall cmu
It works every time from a MSYS shell, but with Cygwin I get
If MSYS works for you, why not stick with it?-)
Cygwin with MinGW tools should work, but it is very easy to mess up
with this setup (configure scripts might not notice that they are on
windows and use the wrong calling convention, Cygwin libraries and
compiler tools might be called accidentally if they are installed, and
so on). Of course, the more people give up and switch to MSYS, the
smaller the chances that such bugs (things that accidentally work when
using MSYS, or with a certain directory layout) get reported and fixed.
Linking dist\build\cmu\cmu.exe ...
C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin\windres:
can't open temporary file `\/cca04932.irc': No such file or directory
cabal.exe: Error: some packages failed to install:
cmu-1.2 failed during the building phase. The exception was:
ExitFailure 1
('cmu' is just an example; the same behaviour seems apparent whatever the
package; I see something very similar when I ask GHC to compile hello.hs.)
You could try running 'ghc -v hello.hs' and check the windres command
for oddities. I have no problems building a simple hello world from Cygwin:
$ uname -a
CYGWIN_NT-6.1-WOW64 VAIO 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin
$ type ghc
ghc is hashed (/cygdrive/c/haskell/ghc/ghc-6.12.2.20100522/bin/ghc)
$ ghc tst.hs
$ ./main.exe
Hello, World!
The general answer I seem to have been getting (and responses I have seen
elsewhere top this problem) is 'don't expect the Haskell tools to work
with
Cygwin'.
That tends to be a self-fulfilling prophesy, similar to 'don't expect the
Haskell
tools to work on Windows (because so many people rely on unixisms)'. But
the result is that problems do surface more often in this configuration. If
you
want to investigate, you could file a report on the HP trac.
Claus
At any rate it seems that, for some people at least, the latest version of
the Haskell tools won't work when launched from Cygwin Bash.
Chris
-Original Message-
From: haskell-cafe-boun...@haskell.org
[mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Claus Reinke
Sent: 08 June 2010 09:02
To: haskell-cafe@haskell.org
Subject: Re: [Haskell-cafe] HP/Cygwin and Curl
Thanks Stephen--that was related to my original question, about using
HP with Cygwin. The answer seems to be No!--you must use MSYS (for
real work).
The short version:
- Cygwin provides commandline tools, compilers and libraries
- MSYS provides commandline tools for the MinGW compilers and libraries
You can use the commandline tools from either Cygwin or MSYS, but you need
to compile and link with the compilers and libraries from MinGW.
Cygwin's gcc produces binaries that live in a unix-emulation on top of
windows, and depend on a cygwin dll to act as a translator. MinGW's gcc
produces native windows binaries.
Claus
http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/ghci-cygwin.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] HP/Cygwin and Curl
with Cygwin I get Linking dist\build\cmu\cmu.exe ... C:\Program Files\Haskell Platform\2010.1.0.0\lib\..\mingw\bin \windres: can't open temporary file `\/cca04932.irc': No such file or directory This sounds very much like a temporary-filename issue. The reported filename's lack of a valid directory specifier looks highly suspicious to me. Are your TEMP, TEMPDIR, TMP, and TMPDIR environment variables set? Are their values sensible? Do you have appropriate permissions on the directories they point to? These are the kinds of thing I usually need to check when setting up a new Cygwin build environment. Admittedly, we do not use cabal on Windows (firewall prevents it from working), but the other ghc tools generally seem to work without problems for us under Cygwin. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Problems with threading?
Louis Wasserman wasserman.louis at gmail.com writes: While working on the Shootout, I noticed the following benchmarks: http://shootout.alioth.debian.org/u64/program.php?test=chameneosreduxlang=ghcid=3 http://shootout.alioth.debian.org/u64q/program.php?test=chameneosreduxlang=ghcid=3 [...] I'd like to see it improved. [...] One difficulty is that the single meeting place is a bottleneck. The only parallel activity I can see for the chameneos creatures is standing around in queues. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Re: [Haskell-cafe] Please check your dependencies on fgl
Ian Lynagh ig...@earth.li writes: On Mon, Jun 07, 2010 at 11:50:44AM -0700, Donald Bruce Stewart wrote: A complete rewrite with a new maintainer: fgl-awesome In 10 years time, we don't want to have fgl fgl-awesome fgl-great fgl-joe which all do the same thing, and have an unclear relationship to each other. Definitely (though hopefully we wouldn't pick names like fgl-awesome anyway...). I think the important question is: Once the new FGL is finished, will there be a good reason (other than backwards compatibility) for people to use the current FGL? If yes, then different names should be used. Otherwise, no matter how different the API is, keeping the same name is the right thing to do. And this is why we're going to request the community's input on our API design: to try and avoid the situation where there's a specific reason to keep using the old one. As it stands, the only real advantage that I can think of is that the new version uses extensions, the old version doesn't (and hence is more compatible). So if there is consensus that the new design is a better fgl, I think it ought to keep the name. Which is what we're trying to build (the consensus, that is). Don has started a wiki page with the arguments here, and I've already added my 2c: http://haskell.org/haskellwiki/Libraries/WhenToRewriteOrRename -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Gene A yumag...@gmail.com writes: Oh lord yes... just call it fgl3 and leave the fgl package alone. This is a source based community here... so you take a package that has a dependency on another library and you go out and get that to cover the dependency and the API is not the same!!! AND especially if that might be the only thing you will ever use that lib for ... and you have to stop and rewrite the original.. and as someone else said with maybe documentation of that API that is not maybe finished or... NO ... At that point the person will probably just DISCARD the compile on the lib or program that had the dependency.. rather then put the effort in to learn an entire API that doesn't match up.. BAD IDEA!! So as soon as you write the basics of an API you can never change it, just extend it to avoid making people have to re-write their code that uses it? That road leads down the path of complacency and stagnation IMHO... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Execution call graph pruning
C K Kashyap ckkash...@gmail.com writes: Hi, I have a call grah which contains information of the edges in the following format caller callee count (time spent by the caller) === foo bar 10100 xxx yyy 2010 zzz yyy 1010 (I used pintool pintool.org to generate this call graph) Now, the problem is that the graph is huge and it take a long to render using 'dot' or use any visualizing tool. Even if they render, it's too cluttered to be useful. I wanted to prune the graph in such a way that I'd have only the edges corresponding to the top 10% of the time consumers. What would be a good way to do such a thing? Has anyone written some utility that I could use? Well, graphviz [1] lets you parse Dot code, so you could then do a filter on it (I'm currently working on ways of letting you interact with the Dot code better). [1]: http://hackage.haskell.org/package/graphviz Also, to let you skip a step prof2dot [2] will create the Dot code for you. [2]: http://hackage.haskell.org/package/prof2dot -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package naming policy
Don Stewart d...@galois.com writes: Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along. As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users Oj! New version coming up with heaps of changes!. Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-c...@? -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons
Sorry, I hit Reply instead of Reply To All. -- Forwarded message -- From: Jake McArthur jake.mcart...@gmail.com Date: Tue, Jun 8, 2010 at 6:16 PM Subject: Re: [Haskell-cafe] Rewriting a famous library and using the same name: pros and cons To: Don Stewart d...@galois.com Making a new name for an existing package subverts the intended meaning of major revision numbers. Libraries that break as a result of a major revision should have had more specific dependencies, and tutorials that go out of date should also have specified the version number of the package for which they were intended. It's a package maintainer's responsibility to respect version number conventions. I don't believe it is a package maintainer's responsibility to account for blatant misuse of it. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package naming policy
On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Don Stewart d...@galois.com writes: Yes, my intent here is to produce a set of guidelines for maintainers of important packages, that ensures we balance stability with innovation. We have a great document for what to consider when adding packages to the HP, for example: http://trac.haskell.org/haskell-platform/wiki/AddingPackages But nothing yet for maintainers who want to keep a package moving along. As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users Oj! New version coming up with heaps of changes!. Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-c...@? Yes, and posting to reddit and having an article on planet haskell about it helps too. There are lots of ways to get the same information and using more of them will help you reach your audience. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: package naming policy
Jason Dagit da...@codersbase.com writes: On Tue, Jun 8, 2010 at 4:13 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: As part of this, we should consider if we want an official process to do what I've done to kick-off this whole discussion: have a way of telling users Oj! New version coming up with heaps of changes!. Whilst major projects might have their own mailing lists, not all users might be subscribed to them, etc. Should we stick with what I've done and just email haskell@ and haskell-c...@? Yes, and posting to reddit and having an article on planet haskell about it helps too. There are lots of ways to get the same information and using more of them will help you reach your audience. Well, someone else would have to do the posting on reddit for me; I waste too much time as-is reading it let alone posting there and getting involved in the discussions on yet another front! ;-) I'll do up a blog post in the next day or so to get it on planet though. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
I don't really see this listed on your list, but maybe I missed it. Happstack has been affected by QuickCheck 1 - QuickCheck 2, parsec 2 - 3, and HaXml 1.13 - 1.20. Those packages are common, and people often want to use happstack with other libraries that also use those packages. The problem is that if we upgrade to the newer versions, then people can't use happstack with libraries that use the old version. For example, when we upgrade to QuickCheck 2, gitit no longer installed, because some dependency of gitit still used (and perhap still does) QuickCheck 1. We are now faced with the same problem with HaXml. Do we upgrade to 1.20 and stick with 1.13 for a while? Either way we cause incompatibilities. The the cause of QuickCheck, 99% of the time, it would have been ok to link the app against QC1 and QC2, because no one ever tried to combine the QC1 tests and the QC2 tests. So, in that cause, making QC1 and QC2 completely different packages would have solved our problem. Duncan C, also proposed a system whereby we could declare QuickCheck as an 'internal' dependency -- meaning we never export any QC2 functions or types to the outside word, so it is safe to link against other versions of QC. That would have worked fine as well, but the proposal does not seem to have gotten any traction yet. That is unfortunate, because it seems useful. In the case of HaXml, things are a bit trickier. It is more likely that people are going to want to use the HaXml stuff we export with other libraries that use HaXml, so everyone would have to be using the same version of HaXml then. At the same time, not very many people actually use the HaXml stuff in happstack, even if they are using another library that use HaXml. So, for most people the version mismatch isn't really an issue. So, like QC, it would actually probably be better for use if HaXml 1.13 and 1.20 had unique package names, so we could link against multiple HaXml versions. Of course, in the case of QC2 and HaXml, the ultimate solution is that everyone upgrades to the latest, and then the problem goes away. But, once you start depending on a larger number of packages directly and indirectly, it does not take very long before you run into someone that has not updated to the latest, and then you are kind of stuck... As a maintainer, I have no idea when the right time to switch to HaXml 1.20 is.. and that is an issue. That same would be true of fgl (though, fortunately, happstack doesn't use that yet). The only solution I have at the moment, is to upgrade to HaXml 1.20, and then send patches to any other direct or indirect dependencies of happstack that use HaXml and get them upgraded as well.. Maybe that is the best solution.. though it is also a lot of work. - jeremy On Tue, Jun 8, 2010 at 10:08 AM, Don Stewart d...@galois.com wrote: There have been a few cases of major API / rewrites to famous old packages causing problems, including: * QuickCheck 1 vs 2 * parsec 2 vs 3 * OpenGL a similar opportunity is present with 'fgl', where the new maintainers are seeking to improve the code. Below I try to summarise the pros and cons of calling the new rewrite/api 'fgl', in the hope we can identify a path that minimizes disruption to users. A group of developers is planning to write a new graph library for Haskell. * They maintain an existing package called 'fgl'. * 'fgl' has a long history: http://web.engr.oregonstate.edu/~erwig/fgl/ * The new library will have different authors and a different API. * They would like the new library 'fgl'. It is a controversial step to write a new library and give it the same name as an existing, famous library. Let's look at the arguments. = Reasons to use the new name = * The new code will be better, and should be preferred. Using the name 'fgl' will ensure adoption. * Rewrites are effective if the name is preserved. E.g. QuickCheck 2. * It is the maintainer's right to modify APIs as they see fit. * Keeping the old fgl around as a separate package, there is then no real incentive to change/upgrade. * Relatively few packages use fgl. So damage is limited. = Reasons not to use the name = * Code that depends on 'fgl' will break. There are 23 direct and 25 indirect dependencies on fgl. http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/fgl-5.4.2.2#direct * Doesn't matter if the old fgl is still around. If the new code is better, it will be adopted on its own merits (see e.g. bytestrings vs packedstring, vector vs uvector) Let the market decide if it is better, rather than forcing us. * The package has been stable for ~10 years -- why change a stable API? It is already perfect * The new package really isn't the same package in any sense. * Rewrites by new teams damage the brand of famous packages (e.g. parsec 3) * No
Re: [Haskell-cafe] cabal problem on OS X
I am also experiencing this problem. I read that the problem was fixed in the latest Cabal-install version. But I'm not sure, as I tried to install the latest Cabal-install and got 50 linker errors which I'm not prepared to tackle until the weekend. On 8 June 2010 18:21, Gordon J. Uszkay uszka...@mcmaster.ca wrote: Did you manage to fix this problem, or are there any updates on it? I am now having the same issue - presumably due to updating my Mac OS X version, because cabal was working fine before that. I can't upgrade cabal or install anything either, same reason. Gordon J. Uszkay uszka...@mcmaster.ca On May 22, 2010, at 7:27 AM, Ivan Lazar Miljenovic wrote: Bill Atkins watk...@alum.rpi.edu writes: When I run cabal update on my Mac (Snow Leopard, Intel), I get: % cabal update Downloading the latest package list from hackage.haskell.org cabal: Codec.Compression.Zlib: incompatible zlib version I'm going to randomly guess that the version of the C zlib library that Cabal was indirectly built against is different to the one on your machine. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] strange errors with unix-compat
Hello, when compiling unix-compat I get this: 4 of 4] Compiling System.PosixCompat.Extensions ( dist/build/System/PosixCompat/Extensions.hs, dist/build/System/PosixCompat/Extensions.o ) cbits/HsUnixCompat.c: In function `unix_major': cbits/HsUnixCompat.c:4:0: warning: implicit declaration of function `major' cbits/HsUnixCompat.c: In function `unix_minor': cbits/HsUnixCompat.c:8:0: warning: implicit declaration of function `minor' cbits/HsUnixCompat.c: In function `unix_makedev': cbits/HsUnixCompat.c:12:0: warning: implicit declaration of function `makedev' /usr/gnu/bin/ar: creatin and an ghci -package gives me this: GHCi, version 6.10.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Loading package syb ... linking ... done. Loading package base-3.0.3.1 ... linking ... done. Loading package unix-2.3.2.0 ... linking ... done. ghc: /home/guenni/.cabal/lib/unix-compat-0.1.2.1/ghc-6.10.4/HSunix-compat-0.1.2.1.o: unknown symbol `major' Loading package unix-compat-0.1.2.1 ... linking ... ghc: unable to load package `unix-compat-0.1.2.1' How can I fix this? Günther ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
Jeremy Shaw jer...@n-heptane.com writes: I don't really see this listed on your list, but maybe I missed it. Happstack has been affected by QuickCheck 1 - QuickCheck 2, parsec 2 - 3, and HaXml 1.13 - 1.20. Those packages are common, and people often want to use happstack with other libraries that also use those packages. The problem is that if we upgrade to the newer versions, then people can't use happstack with libraries that use the old version. For example, when we upgrade to QuickCheck 2, gitit no longer installed, because some dependency of gitit still used (and perhap still does) QuickCheck 1. My understanding is that this is caused by a limitation in ghc-pkg which can't tell the difference between re-exposed and only-used-internally dependencies. I recall having a discussion with either you or someone else from the happstack team about why it isn't applicable there, but the QuickCheck problem can be solved in the general case by having its dependency be a compile-time-only option which is disabled by default. However, this is definitely a major problem with parsec, HaXml, etc. and probably what I consider the main argument _against_ keeping the same name for fgl, though this can occur with packages even with a relatively minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API change was minor but until all package maintainers upgraded their packages to work with 1.7 there would be some inconsistencies). -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I recall having a discussion with either you or someone else from the happstack team about why it isn't applicable there, but the QuickCheck problem can be solved in the general case by having its dependency be a compile-time-only option which is disabled by default. Not really. Cabal likes to recompile things, and it won't remember that I compiled another library with quickcheck enabled. So if library B depends on library A with quickcheck enabled, it may still happen that after I install library A with quickcheck enabled, cabal will decide to recompile A again when building library B, and it will build A without quickcheck, causing B to fail... However, this is definitely a major problem with parsec, HaXml, etc. and probably what I consider the main argument _against_ keeping the same name for fgl, though this can occur with packages even with a relatively minor API change (e.g. haskell-src-exts going from 1.6 to 1.7; the API change was minor but until all package maintainers upgraded their packages to work with 1.7 there would be some inconsistencies). Right. Minor dependencies have the same issue. The only difference is that it is generally less work for maintainers to update their code. So maybe it happens faster/more often. But, we still run into that issue with happstack as well. We have fixed it by sending patches upstream. Since they are small patches it is usually easy to get them created and applied than something like HaXml 1.13 - 1.19. - jeremy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and cons
Jeremy Shaw jer...@n-heptane.com writes: On Tue, Jun 8, 2010 at 7:06 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: I recall having a discussion with either you or someone else from the happstack team about why it isn't applicable there, but the QuickCheck problem can be solved in the general case by having its dependency be a compile-time-only option which is disabled by default. Not really. Cabal likes to recompile things, and it won't remember that I compiled another library with quickcheck enabled. So if library B depends on library A with quickcheck enabled, it may still happen that after I install library A with quickcheck enabled, cabal will decide to recompile A again when building library B, and it will build A without quickcheck, causing B to fail... You of course mean cabal-install, not Cabal when talking about recompiling things (I know, I'm being picky, but still...). Also, that problem is the reason why I recognise that for happstack can't at the moment have the QuickCheck dependency optional. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
From: Stephen Tetley stephen.tet...@gmail.com Hello all While new libraries develop at pace, their documentation rarely does; so I'd have to disagree with John's claim that re-naming libraries makes development by new users harder. I'd argue that having tutorials not work for later revisions is more confusing than having various packages doing the same thing. I'd also contend that beginners are better off lagging behind the cutting edge and using Parsec 2, QuickCheck 1, Haskore-vintage, as the earlier version all have comprehensive documentation - Parsec 2 and Haskore have extensive manual/tutorials, QuickCheck 1 was small enough that the original QuickCheck paper covered its use. Lagging behind the cutting edge is one thing, but learning possibly-deprecated or soon-to-be-obsolete interfaces is another. I would contend that in each case the intention is for the earlier version to be superseded because of significant (hopefully user-driven) benefits provided by the new design. Now beginners are in the very frustrating situation of having invested time with a codebase that they learn is obsolete. Depending on the significance of the changes, some amount of that knowledge can be carried forward, but it's a disheartening position to be in and I would expect a few could give up entirely at that point. I think that's worse than floundering around with no documentation at all. Of course a better solution is for maintainers to update their manuals! An advantage of separate names (both for the package name and module name-space) is that its easier to have both packages installed at the same time - the old one to work with while learning the package, the new one if other installed packages depend on it. This can still be done with package-hiding but its less straight-forward. With proper .cabal files and dependency bounds this isn't an issue. If you're working in ghci I think it's the same amount of work either way, at least with my workflow. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
On Tue, Jun 8, 2010 at 6:28 PM, John Lato jwl...@gmail.com wrote: From: Stephen Tetley stephen.tet...@gmail.com Hello all While new libraries develop at pace, their documentation rarely does; so I'd have to disagree with John's claim that re-naming libraries makes development by new users harder. I'd argue that having tutorials not work for later revisions is more confusing than having various packages doing the same thing. I'd also contend that beginners are better off lagging behind the cutting edge and using Parsec 2, QuickCheck 1, Haskore-vintage, as the earlier version all have comprehensive documentation - Parsec 2 and Haskore have extensive manual/tutorials, QuickCheck 1 was small enough that the original QuickCheck paper covered its use. Lagging behind the cutting edge is one thing, but learning possibly-deprecated or soon-to-be-obsolete interfaces is another. I would contend that in each case the intention is for the earlier version to be superseded because of significant (hopefully user-driven) benefits provided by the new design. Now beginners are in the very frustrating situation of having invested time with a codebase that they learn is obsolete. Depending on the significance of the changes, some amount of that knowledge can be carried forward, but it's a disheartening position to be in and I would expect a few could give up entirely at that point. I think that's worse than floundering around with no documentation at all. Of course a better solution is for maintainers to update their manuals! Or write translator tools for upgrading to the new API :) Pipe dream? Maybe. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tricks with GMap -- question about conflicts w/ indexed type families
Ryan Newton wrote:
What I would next *like* to do is something like the following:
import qualified Data.IntMap as DI
instance FitInWord t = GMapKey t where
data GMap t v = GMapInt (DI.IntMap v) deriving Show
The problem is that there's already a more general instance of GMapKey
that handles pairs by representing them as nested GMaps:
instance (GMapKey a, GMapKey b) = GMapKey (a, b) where
data GMap (a, b) v= GMapPair (GMap a (GMap b v))
Ideally, I want both of these to coexist (and to prioritize the more
specific one). With normal type classes, OverlappingInstances can
handle this, but with type families I get an error like the
following:
First of all, if we forget about data families, OverlappingInstances
still won't give us the desired behavior. GHC chooses overlapping
instances based only on the instance head type, disregarding all
constraints. Therefore, when asked to choose an instance for
GMapKey (Int16,Int16), GHC would choose the second instance as it is
more specific: the type (a,b) is more specific that the type t. Again,
the constraints such as FitInWord are not used when choosing instances.
This issue is discussed in detail at
Choosing a type-class instance based on the context
http://okmij.org/ftp/Haskell/types.html#class-based-overloading
and on the Wiki Page
http://haskell.org/haskellwiki/GHC/AdvancedOverlap
These pages explain how can we make class constraints bear on the
instance selection.
But we still have the second problem: data families do not permit
overlapping declarations. At first blush, it appears impossible to
define GMapKey for specific pairs and default to the generic GMap
instance for general pairs. Fortunately, a solution exists, shown
below. The idea is to define an auxiliary type class (without data
families). Such a type class permits overlapping instances and so
makes possible the desired behavior of specific instances with the
generic default.
{-# LANGUAGE FlexibleInstances, FlexibleContexts #-}
{-# LANGUAGE MultiParamTypeClasses, FunctionalDependencies #-}
{-# LANGUAGE TypeFamilies #-}
{-# LANGUAGE UndecidableInstances #-}
{-# LANGUAGE OverlappingInstances #-}
module GM where
import Data.Int
import Data.Word
import Data.Bits
import qualified Data.IntMap as IM
-- = Begin a simplified GMap package
-- A simplified class GMapKey
class GMapKey t where
data GMap t :: * - *
empty :: GMap t v
lookup :: t - GMap t v - Maybe v
instance GMapKey Int16 where
data GMap Int16 v = GMI16 (IM.IntMap v)
empty = GMI16 $ IM.empty
lookup k (GMI16 m) = IM.lookup (fromIntegral k) m
instance GMapKey Int32 where
data GMap Int32 v = GMI32 (IM.IntMap v)
empty = GMI32 $ IM.empty
lookup k (GMI32 m) = IM.lookup (fromIntegral k) m
-- Generic instance for pairs
instance (GMapKey a, GMapKey b) = GMapKey (a, b) where
data GMap (a, b) v= GMapPair (GMap a (GMap b v))
empty = GMapPair $ empty
lookup k (GMapPair m) = error Invoking the generic instance for pairs
-- = End the simplified GMap package
-- The following is an optimization, which should appear in a different
-- module. The optimization should not disturb the original GMap code.
-- The following optimization is Ryan Newton's code
-- A class for values that fit within one word
class FitInWord v where
toWord :: v - Word
fromWord :: Word - v
instance FitInWord (Int16,Int16) where
toWord (a,b) = shiftL (fromIntegral a) 16 + (fromIntegral b)
fromWord n = (fromIntegral$ shiftR n 16,
fromIntegral$ n .. 0x)
-- Now we wish to define optimized instances of GMapKey for
-- pairs of items that fit within a word.
-- The following answers Ryan Newton's question
-- Define our own product type, to avoid overlapping instances with the
-- general GMapKey for pairs
-- It's a newtype: it has no run-time overhead
newtype OptimalPair a b = OptimalPair (a,b)
instance FitInWord (a,b) = GMapKey (OptimalPair a b) where
data GMap (OptimalPair a b) v = GMapInt (IM.IntMap v) deriving Show
empty = GMapInt IM.empty
lookup (OptimalPair k) (GMapInt m) = IM.lookup (fromIntegral$ toWord k) m
-- Auxiliary class to choose the appropriate pair
class ChoosePairRepr a b pr | a b - pr where
choose_pair :: (a,b) - pr
choosen_pair :: pr - (a,b)
instance ChoosePairRepr Int16 Int16 (OptimalPair Int16 Int16) where
choose_pair = OptimalPair
choosen_pair (OptimalPair p) = p
-- Repeat the above for all other optimal pairs:
-- (Int8, Int16), (Int16, Int8), etc.
-- Template Haskell is very good to generate all such boiler-plate instances
-- Choose a generic pair for all other pairs of values
instance pr ~ (a,b) = ChoosePairRepr a b pr where
choose_pair = id
choosen_pair = id
-- tests
-- A specific instance is chosen
test1 = let m = empty in
GM.lookup (choose_pair (1::Int16,2::Int16)) m
-- Nothing
-- A general pair instance is chosen
test2 = let m =
Re: [Haskell-cafe] Re: Rewriting a famous library and using the same name: pros and consf
On 9 June 2010 12:11, Jason Dagit da...@codersbase.com wrote: Or write translator tools for upgrading to the new API :) Pipe dream? Maybe. Too an extent, yes: the types are more generalised so it's going to be difficult to do automatic translations. However, Thomas has demonstrated that you can write any instance of the new class as an instance of the old classes and vice versa just using class methods... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
