Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps
On Fri, Sep 28, 2012 at 5:36 PM, Francesco Mazzoli wrote: > At Fri, 28 Sep 2012 17:19:36 -0700, > Alexander Solla wrote: > > Well, then what exactly is the problem? Are you getting an error? > > ...well yes. The error I get with the posted class declarations is > >Not in scope: type variable `b' > > at the line with > >class Foo a b => Bar a where > > Which I get because all the type vars in the LHS must be referenced on the > RHS > (or so it seems). > Yes, indeed. > > Now, in my case the problem does not stop there, because I also want to > reference the tyvar on the LHS in a type signature of a method, since in > that > case there is a fundep on b (`a -> b'), which makes `b' decidable if you > have > `a' and `Foo a b'. > Only with respect to type inference. > > > You don't need to bring 'b' into scope. You will already have real > types in > > scope. > > > > instance Foo A B > > instance Bar A where foo A B = C > > Again, I'm not sure what you mean here. I wouldn't have replied with that line of thought if you had just told us what the problem was in the first place. I /was/ saying that you can use explicit type annotations to disambiguate instances. Most of us haven't memorized the Haskell 2010 report. We let the compiler tell us what's wrong and either learn why, or how to fix it. So post your errors. By the way, it is rather rude to publicly post a private email... Now, on to your real problem. Use TypeFamilies instead: class Foo a where type BarThing a :: * class Foo a => Bar a where foo :: a -> BarThing a -> b This is pretty pointless, since you can just refactor into the nearly equivalent: class Foo a class Foo a => Bar a where type BarThing a :: * foo :: a -> BarThing a -> c It may or may not matter to which family the type synonym belongs. What is the problem you are actually trying to solve? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps
At Fri, 28 Sep 2012 17:19:36 -0700, Alexander Solla wrote: > Well, then what exactly is the problem? Are you getting an error? ...well yes. The error I get with the posted class declarations is Not in scope: type variable `b' at the line with class Foo a b => Bar a where Which I get because all the type vars in the LHS must be referenced on the RHS (or so it seems). Now, in my case the problem does not stop there, because I also want to reference the tyvar on the LHS in a type signature of a method, since in that case there is a fundep on b (`a -> b'), which makes `b' decidable if you have `a' and `Foo a b'. > You don't need to bring 'b' into scope. You will already have real types in > scope. > > instance Foo A B > instance Bar A where foo A B = C Again, I'm not sure what you mean here. -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps
On Fri, Sep 28, 2012 at 5:04 PM, Francesco Mazzoli wrote: > CCing the list back. > > At Fri, 28 Sep 2012 13:30:52 -0700, > Alexander Solla wrote: > > What is the problem, exactly? It looks to me like UndecidableInstances > and > > ScopedTypeVariables (on foo, or its arguments) would be enough. > > I'm not sure what you mean. I don't see the need for > UndecidableInstances, and > there is no way I can see to bring the `b' into scope in the type sig for > foo, > ScopedTypeVariables or not - unless I'm missing something. Well, then what exactly is the problem? Are you getting an error? You don't need to bring 'b' into scope. You will already have real types in scope. instance Foo A B instance Bar A where foo A B = C tryIt = (foo :: A -> B -> C) A B ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Class constraints with "free" type variables and fundeps
CCing the list back. At Fri, 28 Sep 2012 13:30:52 -0700, Alexander Solla wrote: > What is the problem, exactly? It looks to me like UndecidableInstances and > ScopedTypeVariables (on foo, or its arguments) would be enough. I'm not sure what you mean. I don't see the need for UndecidableInstances, and there is no way I can see to bring the `b' into scope in the type sig for foo, ScopedTypeVariables or not - unless I'm missing something. > Also note that as stated, foo's type "is a bottom" (more specifically, is a > function onto bottom, since c is free in the class, and so foo must be > parametrically polymorphic in its return type, and so is devoid of "real" > Haskell values). Hopefully that is just an artefact of the translation to > Foo's and Bar's. Yeah the type for `foo' is irrelevant, I just needed to put something there. -- Francesco * Often in error, never in doubt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a parallel mapM?
On Fri, Sep 28, 2012 at 11:01 AM, Greg Fitzgerald wrote: > > > I also tried Control.Parallel.Strategies [2]. While that route works, > I had to use unsafePerformIO. Considering that IO is for sequencing > effects and my IO operation doesn't cause any side-effects (besides > hogging a file handle), is this a proper use of unsafePerformIO? > That's actually a perfectly fine use for unsafePerformIO, since the IO action you are performing is pure and therefore safe (modulo your file handle stuff). unsafePerformIO is a problem when the IO action being run has side effects and their order of evaluation matters (since unsafePerformIO will cause them to be run in an "unpredictable" order) One common use for unsafePerformIO is to run a query against an external library. It has to be done in the IO monad, but it is a "pure" computation insofar as it has no side-effects that matter. Doing this lets us promote values defined in external libraries to bona fide pure Haskell values. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a parallel mapM?
> Check out the parallel combinators in parallel-io: Cool, that's the library I'm looking for! I see it uses 'numCapabilities' to get the command-line value for '-N' and not 'getNumCapabilities' to query the system for how many cores are available. So using the 'Local' module, this works: parMapM f xs = do n <- getNumCapabilities withPool n $ \pool -> parallel pool (map f xs) Thanks, Greg On Fri, Sep 28, 2012 at 11:58 AM, Patrick Mylund Nielsen wrote: > Check out the parallel combinators in parallel-io: > http://hackage.haskell.org/packages/archive/parallel-io/0.3.2/doc/html/Control-Concurrent-ParallelIO-Global.html > > On Fri, Sep 28, 2012 at 1:01 PM, Greg Fitzgerald wrote: >> >> I'm new to concurrent programming in Haskell. I'm looking for a >> drop-in replacement for 'mapM' to parallelize a set of independent IO >> operations. I hoped 'mapConcurrently' might be it, but I need >> something that will only spawn as many threads as I have CPUs >> available [1]. >> >> I also tried Control.Parallel.Strategies [2]. While that route works, >> I had to use unsafePerformIO. Considering that IO is for sequencing >> effects and my IO operation doesn't cause any side-effects (besides >> hogging a file handle), is this a proper use of unsafePerformIO? >> >> >> Attempt 1 >> -- >> >> import System.Process(readProcess) >> import Control.Concurrent.Async(mapConcurrently) >> >> main :: IO [String] >> main = mapConcurrently (\n -> readProcess "echo" ["test: " ++ show n] >> "") [0..1000] >> >> >> $ ghc --version >> The Glorious Glasgow Haskell Compilation System, version 7.6.1 >> >> $ runghc test.hs >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: runInteractiveProcess: pipe: Too many open files >> test.hs: echo: createProcess: resource exhausted (Too many open files) >> >> >> Attempt 2 >> -- >> >> import System.Process(readProcess) >> import Control.Parallel.Strategies(parMap, rpar) >> import System.IO.Unsafe(unsafePerformIO) >> >> main :: IO [String] >> main = myMapConcurrently (\n -> readProcess "echo" ["test: " ++ show >> n] "") [0..1000] >> where >> myMapConcurrently f = return . parMap rpar (unsafePerformIO . f) >> >> $ runghc test.hs > /dev/null && echo Success >> Success >> >> >> Thanks, >> Greg >> >> ___ >> 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] a parallel mapM?
On 28/09/12 19:58, Patrick Mylund Nielsen wrote: Check out the parallel combinators in parallel-io: http://hackage.haskell.org/packages/archive/parallel-io/0.3.2/doc/html/Control-Concurrent-ParallelIO-Global.html also http://hackage.haskell.org/packages/archive/spawn/latest/doc/html/Control-Concurrent-Spawn.html#v:parMapIO combined with http://hackage.haskell.org/packages/archive/spawn/latest/doc/html/Control-Concurrent-Spawn.html#v:pool might be a solution Claude -- http://mathr.co.uk ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a parallel mapM?
Check out the parallel combinators in parallel-io: http://hackage.haskell.org/packages/archive/parallel-io/0.3.2/doc/html/Control-Concurrent-ParallelIO-Global.html On Fri, Sep 28, 2012 at 1:01 PM, Greg Fitzgerald wrote: > I'm new to concurrent programming in Haskell. I'm looking for a > drop-in replacement for 'mapM' to parallelize a set of independent IO > operations. I hoped 'mapConcurrently' might be it, but I need > something that will only spawn as many threads as I have CPUs > available [1]. > > I also tried Control.Parallel.Strategies [2]. While that route works, > I had to use unsafePerformIO. Considering that IO is for sequencing > effects and my IO operation doesn't cause any side-effects (besides > hogging a file handle), is this a proper use of unsafePerformIO? > > > Attempt 1 > -- > > import System.Process(readProcess) > import Control.Concurrent.Async(mapConcurrently) > > main :: IO [String] > main = mapConcurrently (\n -> readProcess "echo" ["test: " ++ show n] > "") [0..1000] > > > $ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.6.1 > > $ runghc test.hs > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: runInteractiveProcess: pipe: Too many open files > test.hs: echo: createProcess: resource exhausted (Too many open files) > > > Attempt 2 > -- > > import System.Process(readProcess) > import Control.Parallel.Strategies(parMap, rpar) > import System.IO.Unsafe(unsafePerformIO) > > main :: IO [String] > main = myMapConcurrently (\n -> readProcess "echo" ["test: " ++ show > n] "") [0..1000] > where > myMapConcurrently f = return . parMap rpar (unsafePerformIO . f) > > $ runghc test.hs > /dev/null && echo Success > Success > > > Thanks, > Greg > > ___ > 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] Call for discussion: OverloadedLists extension
On 12-09-26 08:07 PM, wren ng thornton wrote: On 9/25/12 1:57 PM, Sjoerd Visscher wrote: Maybe we could make a literal [a,b,c] turn into unpack [a,b,c]# where [a,b,c]# is a statically-allocated vector? I'm kinda surprised this isn't already being done. Just doing this seems like it'd be a good undertaking, regardless of whether we get overloaded list literals. Just storing the literal as a C-like array and inflating it to a list/array/vector at runtime seems like it should be a big win for code that uses a lot of literals. Why? I'm surprised that this is an issue at all. If list literals you are talking about are constant, wouldn't GHC apply constant folding and construct the list only the first time it's needed? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Discovery of unnecessary build-depends
Is there a tool available that will tell me if the cabal file for my library or application has any unnecessary build-depends? I have a habit of developing new modules within an application and then moving them out to separate libraries. For instance, I might move module Foo out of my application and into a new or existing library package. If Foo was the only module in my application to explicitly import any modules from the Bar package, I would like to know that I can now remove the dependency on Bar from my application's build-depends in the cabal file. My strategy right now would be to search my whole application for other imports of any of the modules from the Bar package, or just remove Bar from build-depends and check if the application still compiles. Neither solution is particularly scalable or satisfying. Cheers, Jason Whittle ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a parallel mapM?
I'm new to concurrent programming in Haskell. I'm looking for a drop-in replacement for 'mapM' to parallelize a set of independent IO operations. I hoped 'mapConcurrently' might be it, but I need something that will only spawn as many threads as I have CPUs available [1]. I also tried Control.Parallel.Strategies [2]. While that route works, I had to use unsafePerformIO. Considering that IO is for sequencing effects and my IO operation doesn't cause any side-effects (besides hogging a file handle), is this a proper use of unsafePerformIO? Attempt 1 -- import System.Process(readProcess) import Control.Concurrent.Async(mapConcurrently) main :: IO [String] main = mapConcurrently (\n -> readProcess "echo" ["test: " ++ show n] "") [0..1000] $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.6.1 $ runghc test.hs test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: runInteractiveProcess: pipe: Too many open files test.hs: echo: createProcess: resource exhausted (Too many open files) Attempt 2 -- import System.Process(readProcess) import Control.Parallel.Strategies(parMap, rpar) import System.IO.Unsafe(unsafePerformIO) main :: IO [String] main = myMapConcurrently (\n -> readProcess "echo" ["test: " ++ show n] "") [0..1000] where myMapConcurrently f = return . parMap rpar (unsafePerformIO . f) $ runghc test.hs > /dev/null && echo Success Success Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ticketimer - haskell project on Gruender-Garage contest!
I'd like to announce ticketimer.com -- it's a website that is not done yet. With ticketimer you can choose films for your local cinema. People can buy tickets in advance and promote the films they like. Do we need to eat this blockbuster stuff all the time? See how to vote for a change on http://www.indiegogo.com/ticketimer?a=1301421 We are going to use Yesod as a main weapon. Anton ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Class constraints with "free" type variables and fundeps
I would expect this to work, maybe with some additional notation (a la
ScopedTypeVariables)
{-# LANGUAGE FunctionalDependencies #-}
{-# LANGUAGE MultiParamTypeClasses #-}
class Foo a b | a -> b
class Foo a b => Bar a where
foo :: a -> b -> c
The type family equivalent works as expected:
{-# LANGUAGE TypeFamilies #-}
class Foo a where
type T a :: *
class Bar a where
foo :: a -> T a -> c
I can't use type families because the `Foo' I'm using is in an external library.
Is there any way to achieve what I want without adding `b' to `Bar'?
--
Francesco * Often in error, never in doubt
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GHC 6.13 and GHC 7.6 in parallel on Linux
>How is it possible to run 2 different versions of GHC if you installed the binary packages in standard locations, look in /usr/local/bin/ghc* : you have ghc-6.12.3, ghc-7.6.1 etc. and each one knows how to find their libraries. you can even say "cabal install --with-ghc=ghc-7.6.1 foo" ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sylvia, a lambda calculus visualizer
> Sylvia is a lambda calculus visualizer. Such a thing is certainly nice to have. I use this one for teaching: http://joerg.endrullis.de/lambdaCalculator.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Call for discussion: OverloadedLists extension
Michael Snoyman wrote:
Heinrich Apfelmus wrote:
Michael Snoyman wrote:
Note that I wasn't necessarily advocating such a pragma. And a lot of
my XML code actually *does* use two IsString instances at the same
time, e.g.:
Element ("img" :: Name) (singleton ("href" :: Name) ("foo.png" ::
Text)) [NodeComment ("No content inside an image" :: Text)]
In this particular case, would it make sense to use smart constructors
instead?
The idea is that you can put the polymorphism in two places: either make the
"output" polymorphic, or make the "input" polymorphic. The latter would
correspond to a type
element :: (IsString name, IsString s, IsMap map)
=> name -> map name s -> [Element]
element name map = Element (toName name) (toMap map)
One benefit would be that the function will accept any list as a map, not
just list literals.
Just to clarify: this would be a *replacement* for OverloadedStrings
usage, right? If used in conjunction with OverloadedStrings, we'd run
into the too-much-polymorphism issue you describe in your initial
email in this thread, since `element "foo'` would become `element
(fromString "foo")` which would become `Element ((toName . fromString)
"foo")`, and `toName . fromString` makes it ambiguous what the
intermediate data type is.
Yes, indeed, it would be an alternative approach.
Assuming this is meant are a replacement, I see two downsides.
Firstly, this would work for construction, but not for deconstruction.
Currently, I can do something like:
handleList :: Element -> Element
handleList (Element "ul" _ _) = ...
handleList e = e
Good point. On the other hand, there is another extension, ViewPatterns,
which solves the problem of pattern matching on abstract data types in
full generality, allowing things like
handleList (viewAsStrings -> Element "ul" _ _) = ...
While more intrusive, the benefit of this extension is that a lot of
other code could likely become neater as well.
The other is that we've only solved one specific case by providing a
replacement function. In order to keep code just as terse as it is
now, we'd have to provide a whole slew of replacement functions. For
example, consider the code:
handleList (Element "ul" attrs _) = case Map.lookup "class" attrs of
If we get rid of OverloadedStrings, then we need to either provide a
replacement `lookup` function which performs the conversion from
String to Name, or change all lookup calls to explicitly perform that
lookup.
Ah, I see. Since the Name type is abstract, I feel it's alright to add
the polymorphism to functions like element , but Map.lookup is indeed
a problem.
One option would be to make a new type NameMap specifically for Name
as key, but that seems a little overkill. The other option is to bite
the bullet and add the conversion by hand Map.lookup (name "class") .
In this case, I think I would go with a lightweight first option and
simply give a new name to the Map.lookup combination and use the
opportunity to sneak in some polymorphism.
getAttribute name = Map.lookup (toText name)
In my experience, turning all data types into abstractions works quite
well, but I can see that you can't avoid an annoying conversion if you
just want to use a quick Map.lookup .
Best 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] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
The GLUT-backend calls system.exit when the window is closed, because 'exitMainLoop' is only defined within freeglut, which is not by default installed on non-linux platforms. There is hence no real point in running gloss applications with the GLUT-backend from GHCi. I'll try to find a mountain lion install, and test if there's a difference between GLUT and GLFW On Sep 28, 2012, at 7:56 AM, Carter Schonwald wrote: > do these problems also happen if your'e using the glut backend? (because if > its only glfw that has problems, then its something wrong in the ffi code, > but if its both, that suggests there may be some sort of systematic problem?) > > @Lyndon, that sounds like a bug... especially since scotty seems to have no C > code in package... have you filed a bug report with the maintainers thats > reproducible? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
