Hello,
After releaseing new Haskell Platform, many people can now use
RawFilePath (e.g. ByteString) for System.*. However, there is no
System.FilePath.ByteString which manipulates RawFilePath.
How do you guys manipulate RawFilePath as file path?
Is there a plan to implement
On 12 Jun 2012, at 12:52, Dmitry Dzhus d...@dzhus.org wrote:
12.06.2012, 01:08, Roman Leshchinskiy r...@cse.unsw.edu.au:
perhaps the state hack is getting in the way.
I don't quite understand the internals of this yet, but `-fno-state-hack`
leads to great performance in both cases!
How
Hi,
I've forgotten this.
This is OK:
type Job k a = Map k a
And this is OK:
{-# LANGUAGE RankNTypes #-} -- or LiberalTypeSynonyms?
type Job = forall a. forall k. Map k a
Then how to write it like this?
type Job = Map k a
--
竹密岂妨流水过
山高哪阻野云飞
And for G+, please use magiclouds#gmail.com.
On 13 June 2012 19:59, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
Hi,
I've forgotten this.
This is OK:
type Job k a = Map k a
And this is OK:
{-# LANGUAGE RankNTypes #-} -- or LiberalTypeSynonyms?
type Job = forall a. forall k. Map k a
Then how to write it like this?
Do you want to hide the specific types of the job? Presumably to then
define a type JobList = [Job] ?
You can do that with the ExistentialQuantification extension.
type Job = forall k a. Map k a
type JobList = [Job]
??
Note you can't unpack the types k a once you have hidden them. But the
That doesn't require existential quantification, but it'll need Rank-2
types if you ever do anything with Job. Unfortunately, a universally
quantified Job like what you wrote (or what Magicloud seems to want) is
only inhabited by the empty Map.
An existentially quantified Job, as you might get
Mmmmh... no, to do that you need ImpredicativeTypes (which is I believe
about to be deprecated).
You have to declare Job a data, not a type, and use
ExistentialQuantification.
2012/6/13 Ismael Figueroa Palet ifiguer...@gmail.com
Do you want to hide the specific types of the job? Presumably to
http://hpaste.org/69885
The warning in that paste occurs when I attempt
$ cabal update
$ cabal install cabal-dev
This is curious because it wants to install a previous version of mtl.
I can't figure out why. There doesn't seem to be any dependency
between cabal-dev and mtl. According to hackage,
For reference to anyone coming across this:
The issue is that cabal-dev does in fact depend on the old mtl, if one checks
the cabal file. (Thanks to dcoutts_ on #haskell).
The suggestion I received was to use virthualenv.
On Wed, Jun 13, 2012 at 9:20 AM, Edward Amsden eca7...@cs.rit.edu wrote:
We are pleased to announce that a functional programming user group has
recently been formed in Perth, Australia.
Being a small community, we aim to keep the group as inclusive as possible,
and welcome new members from all levels of experience and language
backgrounds. (That said, Haskellers
Hi Todd,
I am over the other side. I help organise the Brisbane Functional
Programming Group.
http://bfpg.org/
Although we discuss FP in general, we have a pretty strong emphasis on
Haskell. Let me know how it goes or if we can help out in any way!
On 14/06/12 00:46, Todd Owen wrote:
We are
It turns out I'm filling in for a cancelled speaker at a local open
source user group, and doing a two-part talk, first on Haskell and
then Snap. For the Haskell part, I'd like a list of current places
the language is used in industry. I recall a few from Reddit stories
and messages here and
On 14 June 2012 02:00, Chris Smith cdsm...@gmail.com wrote:
It turns out I'm filling in for a cancelled speaker at a local open
source user group, and doing a two-part talk, first on Haskell and
then Snap. For the Haskell part, I'd like a list of current places
the language is used in
Thank you all. I just want to wrap some complex types.
So I learn from all info above, I still have to use forall explicitly
On Wed, Jun 13, 2012 at 9:19 PM, Yves Parès yves.pa...@gmail.com wrote:
Mmmmh... no, to do that you need ImpredicativeTypes (which is I believe
about to be
Welcome to issue 231 of the HWN, an issue covering crowd-sourced bits
of information about Haskell from around the web. This issue covers
the week of June 03 to 09, 2012.
Announcements
Paolo Capriotti announced the patchlevel release of GHC 7.4.2. This
release contains a number of bugfixes
Hi there,
Thanks for the reply. To be clear, all I want is to avoid having to
type type variables all over the place. What should I do? My original
code with RankNTypes and ImpredicativeTypes does not work
The type Job = forall k a. M.Map k a works now. But function uses
it does not.
(resending to café, turns out I wasn't subbed from this address.)
Hi Magicloud,
This is correct; because you've hidden the type-variables away by universally
quantifying them, there's no more level of specificity you can get back *out*
of them than just some kind of Map (Job = M.Map k b, where
Hi folks,
I'm happy to announce a new point release of the uuid library, 1.2.6:
http://hackage.haskell.org/package/uuid-1.2.6
The 'uuid' package implements most of RFC 4122[1] including random
generation and generation based on hardware MAC addresses.
I haven't announced a point-release in a
OK. I think I understand a little.
I use Job here just wants to simplify the code. And since I provide
the function as library, I cannot decide what exact type k is. What
should I do?
On Thu, Jun 14, 2012 at 11:23 AM, Arlen Cuss a...@len.me wrote:
(resending to café, turns out I wasn't subbed
On 14 June 2012 14:20, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
OK. I think I understand a little.
I use Job here just wants to simplify the code. And since I provide
the function as library, I cannot decide what exact type k is. What
should I do?
Do you know what the type
I think I need to think this through
On Thu, Jun 14, 2012 at 12:28 PM, Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com wrote:
On 14 June 2012 14:20, Magicloud Magiclouds
magicloud.magiclo...@gmail.com wrote:
OK. I think I understand a little.
I use Job here just wants to simplify the
21 matches
Mail list logo
