Re: [Haskell-cafe] definition of the term "combinator"
> Jason Dagit writes: > Where can I find a formal and precise definition of the term > "combinator", A function that uses nothing but its arguments. > as a term used by the Haskell community to describe "something"? I find that Haskellers often use combinator to mean "a function that makes new functions out of other functions", which it can often do as a pure combinator, but isn't always a combinator per se. -- John Wiegley FP Complete Haskell tools, training and consulting http://fpcomplete.com johnw on #haskell/irc.freenode.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] definition of the term "combinator"
On Fri, Aug 23, 2013 at 9:09 PM, damodar kulkarni wrote: > Hello, > The word "combinator" is used several times in the Haskell community. e.g. > parser combinator, combinator library etc. > > Is it exactly the same term that is used in the "combinatory logic" ? > A combinator is a higher-order function that uses *only function > application* and earlier defined combinators to define a result from its > arguments. [1] > > It seems, the term combinator as in, say, "parser combinator", doesn't > have much to do with the "*only function application*" requirement of the > "combinatory logic", per se. > > If the above observation holds, is the term combinator as used in the > Haskell community, properly defined? > > In other words: > > Where can I find a formal and precise definition of the term "combinator", > as a term used by the Haskell community to describe "something"? > Good question. I believe this article addresses the points you raise: http://www.haskell.org/haskellwiki/Combinator ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] definition of the term "combinator"
Hello, The word "combinator" is used several times in the Haskell community. e.g. parser combinator, combinator library etc. Is it exactly the same term that is used in the "combinatory logic" ? A combinator is a higher-order function that uses *only function application* and earlier defined combinators to define a result from its arguments. [1] It seems, the term combinator as in, say, "parser combinator", doesn't have much to do with the "*only function application*" requirement of the "combinatory logic", per se. If the above observation holds, is the term combinator as used in the Haskell community, properly defined? In other words: Where can I find a formal and precise definition of the term "combinator", as a term used by the Haskell community to describe "something"? Ref: http://en.wikipedia.org/wiki/Combinatory_logic Thanks and regards, -Damodar Kulkarni ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell meetups near Lund, Sweden?
Hi, Are there any Haskell or FP meetups near Lund, Sweden? I will be living there from October. Cheers, -- Carlo Hamalainen http://carlo-hamalainen.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monoids induced by Applicative/Alternative/Monad/MonadPlus?
See also this thread from two years ago: http://www.haskell.org/pipermail/haskell-cafe/2011-June/091294.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHC flags: optghc
Hi, I am using GHC version 6.12.1. What is optghc ? I can't find that information anywhere... Thanks, Jose -- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] monoids induced by Applicative/Alternative/Monad/MonadPlus?
On 13-08-22 04:04 PM, Petr Pudlák wrote: Or, if there are no such definitions, where would be a good place to add them? If they are to be added to the base libraries, the Data.Monoid module would be my choice. I did wish I had the AppMonoid instance on several occasions, when using various parser combinator libraries that don't support this reasonable instance of Monoid: > numericLiteral = optionalMonoid (string "+" <|> string "-") ><> some digit ><> optionalMonoid (string "." <> some digit) The problem is, the AppMonoid newtype would not help in that situation unless it also implemented Applicative and Alternative class, as well as the parsing primitives. Without the latter, the above code would look like this: > numericLiteral = optionalMonoid (AppMonoid (string "+" <|> string "-")) ><> some (AppMonoid digit) ><> optionalMonoid (AppMonoid (string ".") > <> some (AppMonoid digit)) The point of the above is that I don't think there is enough justification for these newtypes. The Applicative and Alternative instances are typically used because of the primitives they come with, and newtype wrappings like AppMonoid and AltMonoid can't support those easily. Unless ekmett adds the appropriate instances to his parsers package, they would be too clumsy to use. Petr Dne 08/20/2013 06:55 PM, Petr Pudlák napsal(a): Dear Haskellers, are these monoids defined somewhere? |import Control.Applicative import Data.Monoid newtype AppMonoid m a =AppMonoid (m a) instance (Monoid a,Applicative m) =>Monoid (AppMonoid m a)where mempty =AppMonoid $ pure mempty mappend (AppMonoid x) (AppMonoid y) =AppMonoid $ mappend <$> x <*> y -- With the () monoid for `a` this becames the monoid of effects. newtype AltMonoid m a =AltMonoid (m a) instance Alternative m =>Monoid (AltMonoid m a)where mempty =AltMonoid empty mappend (AltMonoid x) (AltMonoid y) =AltMonoid $ x <|> y| (and similarly for Monad/MonadPlus, until they become subclasses of Applicative?) Best regards, Petr ___ 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] Munich Haskell Meeting, August 26th
Dear all, our monthly Haskell Meeting will take place next week, Monday the 26th of August, at 19h30 in Munich. Please note that we will meet this time at the Max-Emanuel-Brauerei[1]. Last time, much more people showed up than registered and our table was pretty cramped: thus, if you plan to join, *please* add yourself to the Doodle at http://www.doodle.com/wfgkscwhkakf9uqa We also apologize that our website http://www.haskell-munich.de/ is currently unavailable. Please post to high-order-mun...@fs.lmu.de or myself directly if you have any questions. Have a nice weekend and see you soon, chris [1] http://www.max-emanuel-brauerei.de/ -- Christian Neukirchenhttp://chneukirchen.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle vs Hayoo
On 23/08/13 14:57, jabolo...@google.com wrote: >> It's a bit pointless, if I have to know the package, where I want to >> search in. > > Yeah! It does sound a bit pointless. Hoogle should search everything > by default, and then you can refine your search by clicking on the '+' > or '-' on the packages that appear on the left menu. > > Jose > +1 to this, I never even knew this functionality existed. Why not have a checkbox or something along these lines to enable the search in all packages? This wouldn't change the old behaviour by default and it would allow for a wider search. -- Mateusz K. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle vs Hayoo
> It's a bit pointless, if I have to know the package, where I want to > search in. Yeah! It does sound a bit pointless. Hoogle should search everything by default, and then you can refine your search by clicking on the '+' or '-' on the packages that appear on the left menu. Jose -- Jose Antonio Lopes Ganeti Engineering Google Germany GmbH Dienerstr. 12, 80331, München Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores Steuernummer: 48/725/00206 Umsatzsteueridentifikationsnummer: DE813741370 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet Another Forkable Class
On Fri, 2013-08-23 at 08:06 +, o...@okmij.org wrote: > > It will > > arbitrarily pick the first match in the former and fail to compile > in > > the latter case. > Of course we can have duplicate layers. In that case, the dynamically > closest > handler wins -- which sounds about right (think of reset in delimited > control). Did anyone ever consider using type-level literals (strings) to 'name' effects (or transformer layers when using monad stacks)? A stupid example (OTOH) could be updateStats :: (Member (State "min" Int) r, Member (State "max" Int) r) => Int -> Eff r () updateStats i = do min <- askMin max <- askMax when (i < min) $ putMin i when (i > max) $ putMax i where askMin :: Member (State "min" Int) r => Eff r Int askMin = ask putMax :: Member (State "max" Int) r => Int -> Eff r () putMax = put -- askMax, putMin accordingly Using constraint synonyms/ConstraintKinds (e.g. type StateMax r = Member (State "max" Int) r) might reduce some notation overhead. Just a thought. Nicolas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] typeclass constraints
Adam Gundry wrote: > If you leave off the type signature, as you did for sum', the > right thing will be inferred. Thanks Adam and Ivan. Very stupid question... TP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] typeclass constraints
On 23 August 2013 19:23, TP wrote:
> Hi everybody,
>
>
> There is something I do not understand in the way typeclass constraints are
> inferred.
>
>
> 1/ Take the following function definition:
>
> sum' [] = []
> sum' (x:xs) = x + sum' xs
You haven't specified a type signature here, so GHC will derive the
most generic one possible.
>
> GHCI correctly gives:
>
>> :t sum'
> sum' :: Num [a] => [[a]] -> [a]
>
> So it has inferred that the type list has to be an instance of Num for sum'
> to be able to work. It will give an error if we try to use sum' without
> implementing the instance.
>
>
> 2/ Now, take the following definition:
>
>
> {-# LANGUAGE TemplateHaskell #-}
>
> import Language.Haskell.TH
> import Language.Haskell.TH.Syntax
>
> p :: a -> ExpQ
> p n = [| show n |]
You have defined a type signature here, so GHC will try to use it...
except (as you've noted) GHC will then complain that it's wrong.
If GHC auto-magically fixed incorrect type signatures, then one of the
major advantages of the type system (i.e. "specify a type for a
function and then use that to guarantee that the function matches the
specification of what we wanted") will no longer be valid.
>
>
> We obtain an error if we try to load it in GHCI:
>
> No instance for (Lift a) arising from a use of `n'
> Possible fix:
> add (Lift a) to the context of
> the type signature for p :: a -> ExpQ
> In the first argument of `show', namely `n'
> In the Template Haskell quotation [| show n |]
> In the expression: [| show n |]
>
> And indeed, if we use instead:
>
>
> {-# LANGUAGE TemplateHaskell #-}
>
> import Language.Haskell.TH
> import Language.Haskell.TH.Syntax
>
> p :: Lift a => a -> ExpQ
> p n = [| show n |]
>
>
> it works correctly.
>
>
> Why GHC is able to infer the typeclass constraint (Num a) in 1/, but not
> (Lift a) in 2/?
>
>
> Thanks in advance,
>
> TP
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
--
Ivan Lazar Miljenovic
ivan.miljeno...@gmail.com
http://IvanMiljenovic.wordpress.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] typeclass constraints
Hi TP,
The difference is that in your second example, you have specified the
type signature
p :: a -> ExpQ
so GHC checks whether p has this type, and correctly objects that it
doesn't. If you leave off the type signature, as you did for sum', the
right thing will be inferred.
Hope this helps,
Adam
On 23/08/13 10:23, TP wrote:
> Hi everybody,
>
>
> There is something I do not understand in the way typeclass constraints are
> inferred.
>
>
> 1/ Take the following function definition:
>
> sum' [] = []
> sum' (x:xs) = x + sum' xs
>
> GHCI correctly gives:
>
>> :t sum'
> sum' :: Num [a] => [[a]] -> [a]
>
> So it has inferred that the type list has to be an instance of Num for sum'
> to be able to work. It will give an error if we try to use sum' without
> implementing the instance.
>
>
> 2/ Now, take the following definition:
>
>
> {-# LANGUAGE TemplateHaskell #-}
>
> import Language.Haskell.TH
> import Language.Haskell.TH.Syntax
>
> p :: a -> ExpQ
> p n = [| show n |]
>
>
> We obtain an error if we try to load it in GHCI:
>
> No instance for (Lift a) arising from a use of `n'
> Possible fix:
> add (Lift a) to the context of
> the type signature for p :: a -> ExpQ
> In the first argument of `show', namely `n'
> In the Template Haskell quotation [| show n |]
> In the expression: [| show n |]
>
> And indeed, if we use instead:
>
>
> {-# LANGUAGE TemplateHaskell #-}
>
> import Language.Haskell.TH
> import Language.Haskell.TH.Syntax
>
> p :: Lift a => a -> ExpQ
> p n = [| show n |]
>
>
> it works correctly.
>
>
> Why GHC is able to infer the typeclass constraint (Num a) in 1/, but not
> (Lift a) in 2/?
>
>
> Thanks in advance,
>
> TP
>
>
> ___
> 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] typeclass constraints
Hi everybody,
There is something I do not understand in the way typeclass constraints are
inferred.
1/ Take the following function definition:
sum' [] = []
sum' (x:xs) = x + sum' xs
GHCI correctly gives:
> :t sum'
sum' :: Num [a] => [[a]] -> [a]
So it has inferred that the type list has to be an instance of Num for sum'
to be able to work. It will give an error if we try to use sum' without
implementing the instance.
2/ Now, take the following definition:
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
p :: a -> ExpQ
p n = [| show n |]
We obtain an error if we try to load it in GHCI:
No instance for (Lift a) arising from a use of `n'
Possible fix:
add (Lift a) to the context of
the type signature for p :: a -> ExpQ
In the first argument of `show', namely `n'
In the Template Haskell quotation [| show n |]
In the expression: [| show n |]
And indeed, if we use instead:
{-# LANGUAGE TemplateHaskell #-}
import Language.Haskell.TH
import Language.Haskell.TH.Syntax
p :: Lift a => a -> ExpQ
p n = [| show n |]
it works correctly.
Why GHC is able to infer the typeclass constraint (Num a) in 1/, but not
(Lift a) in 2/?
Thanks in advance,
TP
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Conduit : is it possible to write this function?
You can build this up using the >=< operator[1] in stm-conduit, something like: eitherSrc :: MonadResourceBase m => Source (ResourceT m) a -> Source (ResourceT m) b -> Source (ResourceT m) (Either a b) eitherSrc src1 src2 = do join $ lift $ Data.Conduit.mapOutput Left src1 >=< Data.Conduit.mapOutput Right src2 I think this can be generalized to work with more base monads with some tweaks to (>=<). [1] http://haddocks.fpcomplete.com/fp/7.4.2/20130704-120/stm-conduit/Data-Conduit-TMChan.html#v:-62--61--60- On Fri, Aug 23, 2013 at 11:32 AM, Erik de Castro Lopo wrote: > Hi all > > Using the Conduit library is it possible to write the function: > >eitherSrc :: MonadResource m > => Source m a -> Source m b -> Source m (Either a b) > > which combines two sources into new output source such that data being > produced aysnchronously by the original two sources will be returned > as either a Left or Right of tne new source? > > If so, how? > > Cheers, > Erik > -- > -- > Erik de Castro Lopo > http://www.mega-nerd.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] Hoogle vs Hayoo
On Fri, Aug 23, 2013 at 10:12:27AM +0200, Erik Hesselink wrote: > Note that the 'normal' hoogle indexes all (?) of hackage. But by > default it only searches the haskell platform. You can add a package > with '+' to search in that package. E.g. "PublicKey +crypto-api". If the idea behind this, that the haskell platform packages should be the first place to look at, than this could be also achieved by sorting the search results. It's a bit pointless, if I have to know the package, where I want to search in. Greetings, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Conduit : is it possible to write this function?
Hi all Using the Conduit library is it possible to write the function: eitherSrc :: MonadResource m => Source m a -> Source m b -> Source m (Either a b) which combines two sources into new output source such that data being produced aysnchronously by the original two sources will be returned as either a Left or Right of tne new source? If so, how? Cheers, Erik -- -- Erik de Castro Lopo http://www.mega-nerd.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle vs Hayoo
On Thu, Aug 22, 2013 at 9:23 PM, Mateusz Kowalczyk wrote: > On 22/08/13 19:30, jabolo...@google.com wrote: >> Hi, >> >> I noticed Hayoo appears as a link in the toolbox of >> http://hackage.haskell.org and also that Hayoo seems to display better >> results than Hoogle. For example, if you search for 'PublicKey' in >> Hayoo, you will get several results from Hackage libraries, such as, >> 'crypto-pubkey' and 'crypto-api'. However, the same query in Hoogle >> displays no results. >> >> Is Hayoo the default Hackage search engine ? >> Is Hoogle deprecated ? >> What the status ? > > You could also try the Hoogle hosted by FPComplete guys, it indexes more > stuff. Note that the 'normal' hoogle indexes all (?) of hackage. But by default it only searches the haskell platform. You can add a package with '+' to search in that package. E.g. "PublicKey +crypto-api". Regards, Erik ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yet Another Forkable Class
I must stress that OpenUnion1.hs described (briefly) in the paper is only one implementation of open unions, out of many possible. For example, I have two more implementations. A year-old version of the code implemented open unions *WITHOUT* overlapping instances or Typeable. http://okmij.org/ftp/Haskell/extensible/TList.hs The implementation in the paper is essentially the one described in the full HList paper, Appendix C. The one difference is that the HList version precluded duplicate summands. Adding the duplication check to OpenUnion1 takes three lines of code. I didn't add them because it didn't seem necessary, or even desired. I should further stress, OverlappingInstances are enabled only within one module, OpenUnion1.hs. The latter is an internal, closed module, not meant to be modified by a user. No user program needs to declare OverlappingInstances in its LANGUAGES pragma. Second, OverlappingInstances are used only within the closed type class Member. This type class is not intended to be user-extensible; the programmer need not and should not define any more instances for it. The type class is meant to be closed. So Member emulates closed type families implemented in the recent version of GHC. With the closed type families, no overlapping instances are needed. > Simply the fact that the Member class needs -XOverlappingInstances > means that we cannot have duplicate or polymorphic effects. It will > arbitrarily pick the first match in the former and fail to compile in > the latter case. Of course we can have duplicate layers. In that case, the dynamically closest handler wins -- which sounds about right (think of reset in delimited control). The file Eff.hs even has a test case for that, tdup. BTW, I'm not sure of the word 'pick' -- the Member class is a purely compile-time constraint. It doesn't do any picking -- it doesn't do anything at all at run-time. > For example we should be able to project the open sum equivalent of > Either String String into the second String but we cannot with the > implementation in the paper. You inject a String or a String, and you will certainly project a String (the one your have injected). What is the problem then? You can always project what you have injected. Member merely keeps track of what types could possibly be injected/projected. So, String + String indeed should be String. By polymorphic effects you must mean first-class polymorphism (because the already implemented Reader effect is polymorphic in the environment). First of all, there are workarounds. Second, I'm not sure what would be a good example of polymorphic effect (aside from ST-monad-like). > To be honest I'm not so sure about these "effects"... Haskell Symposium will have a panel on effect libraries in Haskell. It seems plausible that effects, one way or the other, will end ip in Haskell. Come to Haskell Symposium, tell us your doubts and concerns. We want to hear them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hoogle vs Hayoo
Mateusz Kowalczyk fuuzetsu.co.uk> writes: > I always thought [hayoo] was just Hoogle with more indexed docs. Wait - there's a semantic difference: hoogle does understand type signatures (e.g., it can specialize them, or flip arguments of functions) while hayoo just treats signatures as strings (it seems). Example: search for [a] -> [a] hoogle: will also return Data.Text.transpose :: [Text] -> [Text] (note: instantiated a to Text) hayoo: will also return Data.List.isInfixOf :: [a] -> [a] -> Bool (note: the type is [a] -> ([a] -> Bool), so it does actually not contain the type from the query) I much prefer hoogle's query semantics. - J.W. PS: but hoogle also returns inits :: [a] -> [[a]] which is not an instance of the query. Why is this? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
