- Haskell-Cafe - Haskell.org

Is there a nice place for extra stuff for Category?
by David Feuer 25 Feb '16

25 Feb '16

1. An explanation of a monoid as a category with exactly one object newtype Cat c a = Cat {getCat :: c a a} instance Category c => Monoid (c a) newtype Mon m a b = Mon {getMon :: m} instance Monoid m => Category (Mon m) --This would be more precisely written -- data Mon m a b where -- Mon :: m -> Mon a a -- but that hurts performance without seeming to offer much in return 2. newtype Op c a b = Op {getOp :: c b a} instance Category c => Category (Op c) instance Bifunctor c => Bifunctor (Op c) instance Bifunctor c => Functor (Op c a) instance Profunctor c => Contravariant (Op c a) I see that Control.Category.Dual in the categories package offers a version of this last defined as *data* for some reason.

1 0

Re: [Haskell-cafe] Manual type-checking in graphs: Avoidable?
by Jeffrey Brown 25 Feb '16

25 Feb '16

It is possible! Off-list, Matt Parsons explained how to do it. With his permission I have copied that email below: On Sat, Feb 20, 2016 at 9:14 PM, Matt <parsonsmatt(a)gmail.com> wrote: > Phantom types can help disambiguate: > > data Hamster > data Person > > data Node a where > HNode :: String -> Node Hamster > PNode :: String -> Node Person > > type G = Gr (Some Node) String > > Your API functions will have the type: > > getPersonHamsters :: Node Person -> [Node Hamster] > getPersonHamsters (PNode personName) = ... > > Since the only way to construct a `Node Person` is with the `PNode` > constructor, you don't even have to check for the `HNode` constructor, and > it's a type error to provide it to the function. > > You'll need to wrap in `Some` to store in the graph and unwrap/pattern > match on the `Some` to get the data back out. This'll provide some > additional safety by constraining surface area of the less-strongly-typed > interface, but it won't take care of it entirely. > > Matt Parsons > > On Sat, Feb 20, 2016 at 9:27 PM, Jeffrey Brown <jeffbrown.the(a)gmail.com> > wrote: > >> Clever! That answers my first question, but still leaves me unmotivated. >> Would GADTs allow me to offload some kind of work onto the compiler that I >> currently have to do myself? >> >> On Sat, Feb 20, 2016 at 2:00 PM, Matt <parsonsmatt(a)gmail.com> wrote: >> >>> The pattern I've seen is: >>> >>> data Some f where >>> Some :: f a -> Some f >>> >>> type G = Gr (Some Box') String >>> >>> Ordinarily you lose the information about the `a`, but when you have a >>> GADT, that allows you to recover type information. So you can match on: >>> >>> f :: Some Box' -> String >>> f (Some (Bi i)) = show (i + 1) >>> f (Some (Bs s)) = s >>> >>> Matt Parsons >>> >>> On Sat, Feb 20, 2016 at 4:16 PM, Jeffrey Brown <jeffbrown.the(a)gmail.com> >>> wrote: >>> >>>> Interesting! I have two questions. >>>> >>>> (1) Given that Graph is of kind * -> * -> *, rather than (* -> *) -> * >>>> -> *, how can I use a GADT? The first graph using existentials defined >>>> earlier in this thread looked like: >>>> >>>> data Box = forall s. Show s => Box s >>>> type ExQuantGraph = Gr Box String >>>> >>>> If instead I use a GADT: >>>> >>>> data Box' a where >>>> Bi :: Int -> Box' Int >>>> Bs :: String -> Box' String >>>> >>>> then I can't define a graph on >>>> >>>> type G = Gr Box' String >>>> >>>> because Box is not a concrete type. I could specify (Box a) for some a, >>>> but then I lose the polymorphism that was the purpose of the GADT. >>>> >>>> (2) Would a GADT be better than what I'm already doing? Currently I >>>> define a Mindmap[1] as a graph where the nodes are a wrapper type called >>>> Expr ("expression"): >>>> >>>> type Mindmap = Gr Expr _ -- the edge type is irrelevant >>>> data Expr = Str String | Fl Float >>>> | Tplt [String] | Rel | Coll >>>> | RelSpecExpr RelVarSpec deriving(Show,Read,Eq,Ord) >>>> >>>> I do a lot of pattern matching on those constructors. If I used a GADT >>>> I would still be pattern matching on constructors. So do GADTs offer some >>>> advantage? >>>> >>>> [1] >>>> https://github.com/JeffreyBenjaminBrown/digraphs-with-text/blob/master/src/… >>>> >>>> On Sat, Feb 20, 2016 at 11:59 AM, Benjamin Edwards < >>>> edwards.benj(a)gmail.com> wrote: >>>> >>>>> if you are willing to have a closed universe, you can pattern match on >>>>> a gadt to do do the unpacking >>>>> >>>>> On Sat, 20 Feb 2016 at 19:19 Jeffrey Brown <jeffbrown.the(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Yes, that is my point. Existentials cannot be unwrapped. >>>>>> >>>>>> On Sat, Feb 20, 2016 at 4:18 AM, Kosyrev Serge < >>>>>> _deepfire(a)feelingofgreen.ru> wrote: >>>>>> >>>>>>> Jeffrey Brown <jeffbrown.the(a)gmail.com> writes: >>>>>>> > After further study I believe existentials are not (at least alone) >>>>>>> > enough to solve the problem. >>>>>>> .. >>>>>>> > getInt :: ShowBox -> Int >>>>>>> > getInt (SB i) = i >>>>>>> > >>>>>>> > will not compile, because it cannot infer that i is an Int: >>>>>>> >>>>>>> You take a value of an existentially quantified type (which means it >>>>>>> can be anything at all, absent some extra context) and *proclaim* it >>>>>>> is an integer. >>>>>>> >>>>>>> On what grounds should the compiler accept your optimistic >>>>>>> restriction? >>>>>>> >>>>>>> -- >>>>>>> с уважениeм / respectfully, >>>>>>> Косырев Сергей >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Jeffrey Benjamin Brown >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe(a)haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Jeffrey Benjamin Brown >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe(a)haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >> >> >> -- >> Jeffrey Benjamin Brown >> > > -- Jeffrey Benjamin Brown

1 0

Problems with attoparsec (or maybe URI.ByteString)
by Brian Hurt 25 Feb '16

25 Feb '16

What I'm trying to do is write a function with the signature: data Urls = Txt Text.Text | Url Text.Text URI.URI deriving (Show) parseUrls :: Text.Text -> Either String [ Urls ] parseUrls text = ... Given a text block, it finds all the URLs, and breaks things into either URLs, or blocks of text which are not URLs. The full text is attached, for those who are interested. But the problem I'm hitting is using the Attoparsec parser URI.ByteString exports. When I do: *Base.DetectURL AP> AP.parseOnly (URI.uriParser URI.laxURIParserOptions) " http://foo/bar" Right (...) So, that works. But when I add a single space on the end of the string: *Base.DetectURL AP> AP.parseOnly (URI.uriParser URI.laxURIParserOptions) " http://foo/bar " Left "Failed reading: MalformedPath" It fails. Note that this isn't a problem with parseOnly- the real code looks like: parseAllUris :: AP.Parser (Bldr.Builder, [ Urls ]) parseAllUris = msum [ aUri, noUri, finished ] where finished = return (mempty, []) aUri = do (txt, url) <- AP.match $ URI.uriParser URI.laxURIParserOptions (bldr, us) <- msum [ noUri, finished ] return $ (mempty, (Url (E.decodeUtf8 txt) url : prependText bldr us)) noUri = do c <- AP.anyChar (bldr, us) <- parseAllUris return $ ((Bldr.charUtf8 c) `mappend` bldr, us) And this has the problem as well- parsing a URL with anything following it fails, and it doesn't detect any URLs. The parseOnly is just the easy way to demonstrate it. So, my question is, is there some way in attoparsec to tell it to just parse as much as makes sense, and leave the rest? Alternatively, is this a problem with the way URI.ByteString module constructed it's parser, and a different parser could work? Or, worst of all, is this a problem with the way that URIs are defined and no conforming parser will work? Thanks. Brian

2 1

installing the Haskell Platform on Redhat without admin access
by Victor Miller 25 Feb '16

25 Feb '16

I'd like to install the latest version of the Haskell Platform for my own use on a redhat system. I don't have admin access so I can't run "sudo yum" as outlined on the haskell.org download page. How can I do this? Victor

2 1

Hedis 0.7.0 release warning
by Kostiantyn Rybnikov 24 Feb '16

24 Feb '16

Hi! I've released hedis 0.7.0 with one change which might affect some of you, so I thought it makes sense to notify cafe. To fix the issue #23 [0] we decided that it's ok to sacrifice pipelining between runRedis calls, so from now on, there won't be pipelining in that scenario. I want to thank Kirill Zaborsky for the fix in pr #45 [1] Best regards, Kostia [0]: https://github.com/informatikr/hedis/issues/23 [1]: https://github.com/informatikr/hedis/pull/45

1 0

Free and cofree
by David Laing 24 Feb '16

24 Feb '16

Hi all, A little while back I gave a talk at YOW Lambda Jam and wrote some posts on combing free monads and cofree comonads (inspired by some posts by Ed Kmett and Dan Piponi). I shared them on reddit, but recently realised that there might be some folks on this list who might be interested in the material. For those interested people, it's all here: http://dlaing.org/cofun/ The "coming soon" posts will turn up eventually, although not until I'm done preparing my proposal for this year's Lambda Jam :) Cheers, Dave

1 0

Typeclassopedia exercises - my own answers published.
by David Banas 23 Feb '16

23 Feb '16

Hi all, I’ve published my own answers to some of the exercises in Brent Yorgey’s Typeclassopedia: Github hosted HTML preview: http://htmlpreview.github.io/?https://github.com/capn-freako/Haskell_Misc/b… Github source repository: https://github.com/capn-freako/Haskell_Misc/tree/v0.5/Typeclassopedia Thanks to Conal Elliott and Phil Ruffwind for their help. -db

1 0

Compile times and separate compilation
by Tom Ellis 22 Feb '16

22 Feb '16

Random thought about compile times: could separate compilation be made even more fine-grained by taking it to the level of individual top-level identifiers, rather than modules? This would probably help slow recompiles a lot. Tom

4 4

Fw: new important message
by dek5＠yandex.ru 22 Feb '16

22 Feb '16

Hello! New message, please read <http://stagetwo.co.uk/round.php?630lm> dek5(a)yandex.ru

1 0

Haskell ITA meetup in Florence, Italy (2016-03-26)
by Luca Molteni 22 Feb '16

22 Feb '16

Hello everyone I'd like to announce that on March 26 (2016-03-26) we're going to host the third meetup of the Haskell ITA user group (http://www.haskell-ita.it/) near Florence, Italy. This time we're going to focus more on the practical part rather than the talks, we're going to form some little group in order to create some small project or contribute to some open source library (Stack was proposed, but any suggestion is welcome). It's important if you decide to attend that you have the development environment already configured, you can use this guide (in italian) to do it: http://haskell-ita.it/2015/01/Installare_Haskell/ There will be people from all Italy, and we'll use the italian language during all the event. Here's the link for the registration: https://metooo.io/e/haskell-day-firenze Italian version will follow --- Iscrivetevi qui: https://metooo.io/e/haskell-day-firenze Questo è il terzo evento del gruppo dei programmatori Haskell Italiani. A differenza dei due precedenti, vogliamo concentrarci un po' più sull'aspetto pratico, quindi ci saranno un sacco di occasioni di sperimentare la programmazione funzionale pura direttamente sul proprio portatile. La proposta è di fare dei gruppetti di lavoro ristretti (2-6 persone, ideale 3-4) per lavorare su qualcosa di concreto, approfondire la conoscenza del linguaggio attraverso il confronto e divertirsi un po'. È importante avere già l'ambiente preparato seguendo questa guida: http://haskell-ita.it/2015/01/Installare_Haskell/ Il numero e quali talk al mattino è ancora da decidere e qualsiasi proposta è benvenuta, maggiori informazioni sul nostro sito: http://haskell-ita.it/2016/02/organizzazione-meetup-marzo-2016/ L.M.

2 2