Re: [Haskell-cafe] Problem with forall type in type declaration
Anyone could help on this?
On Fri, May 4, 2012 at 11:12 PM, Magicloud Magiclouds
wrote:
> Sorry to use Monad as the example, I meant this one:
> run :: MonadTrans m => m IO a -> IO a
>
> And Daniel, I do not think adding another type "b" a good idea. Since
> "run" could actually return any inside type (depending on another
> function that passed to it). Even simple as different tuples would
> destroy this solution.
>
> On Fri, May 4, 2012 at 10:05 PM, Daniel Díaz Casanueva
> wrote:
>> If one parameter is not enough, you always can add more:
>>
>> Test m a b = Test { f :: m IO a -> IO b }
>>
>> This way, if
>>
>> run :: m IO a -> IO a
>>
>> then
>>
>> Test run :: Test m a a
>>
>> But for other type for your run function
>>
>> run' :: m IO a -> IO b
>>
>> you get
>>
>> Test run' :: Test m a b
>>
>> So you can have different types in input and output. Anyway, your type 'm'
>> is applied to other two types (m IO a), so it cannot be a monad, because
>> monads have arity 1 as type constructors, i.e. monads have kind (* -> *). Is
>> perhaps 'm' some kind of monad transformer?
>>
>> Well, that's all I can say from your explanation of the problem! Hope it
>> helps!
>>
>> Daniel Díaz.
>
>
>
> --
> 竹密岂妨流水过
> 山高哪阻野云飞
>
> And for G+, please use magiclouds#gmail.com.
--
竹密岂妨流水过
山高哪阻野云飞
And for G+, please use magiclouds#gmail.com.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell-Type-Exts -- Typechecker as a Library
Hello Haskell Cafe! Recently, I got my proposal “Haskell-Type-Exts”--submitted to haskell community--accepted for Google SoC 2012! I have the luxury (thanks to Haskell.org GSoC committee) to develop a typechecker[1] for ASTs extracted by HSE[2] during this summer. HSE is one of the most widely used (if not the most popular) standalone parsers for Haskell 2010 plus a wide variety of extensions. HSE is written (and maintained) by Niklas Broberg and he is also mentoring this project. To be realistic, it is a rather challenging project and support of the community is vitally important to achieve the goals. I have a weblog accessible at http://cleantypecheck.wordpress.com/ dedicated to this topic. I plan to use it as the main media to communicate with people interested. Also, you can contact me directly through [shayan at chalmers d0t se]. If you see yourself as a potential user of the tool or by any reason you are interested , I'd highly appreciate if you would take a look at the following post and leave your comment/suggestions: http://cleantypecheck.wordpress.com/2012/05/03/inquiry/ Thanks! /Shayan [1] http://hackage.haskell.org/package/haskell-type-exts [2] http://hackage.haskell.org/package/haskell-src-exts ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] correction
Correction to my last letter: Run on the second terminal > ./iface --> Run on the second terminal > ./a.out -- Sergei mech...@botik.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: hspec-1.1.0
Hi, I'm glad to announce a new release of hspec[1]. Detailed release notes are at [2]. Introductory documentation is at [3]. Cheers, Simon [1] http://hackage.haskell.org/package/hspec-1.1.0 [2] https://github.com/hspec/hspec/blob/master/CHANGES.markdown [3] http://hspec.github.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Correspondence between libraries and modules
Alvaro Gutierrez wrote: > I've only dabbled in Haskell, so please excuse my ignorance: why isn't > there a 1-to-1 mapping between libraries and modules? > > As I understand it, a library can provide any number of unrelated modules, > and conversely, a single module could be provided by more than one > library. I can see how this affords library authors more flexibility, but > at a cost: there is no longer a single, unified view of the library > universe. (The alternative would be for every module to be its own, > hermetic library.) So I'm very interested in the rationale behind that > aspect of the library system. I am probably repeating arguments brought forward by others, but I really like that the Haskell module name space is ordered along functionality rather than authorship. If I ever manage to complete an implementaton of the EPICS pvData project in Haskell, it will certainly inherit the Java module naming convention and thus will contain modules named Org.Epics.PvData.XXX, *but* if I need to add utility functions to the API that are generic list processing functions they will certainly live in the Data.List.* name space and if I need to add type level stuff (which is likely) it will be published under Data.Type.* etc. This strikes me as promoting re-use: makes it far easier and more likely to factor out these things into a separate general purpose library or maybe even integrate them into a widely known standard library. It also gives you a much better idea what the thing you export is doing than if it is from, say, Org.Epics.PvData.Util. Finally, it gives the package author an incentive to actually do the refactoring that makes it obvious where the function belongs to, functionally. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Fixed point newtype confusion
Thanks Wren!
When I try
> fix term
ghci complains of an ambiguous type variable.
I have to specify
> term :: (Expr (Expr (Expr (Fix Expr
for it to work.
Is there a way around this?
On Sun, May 6, 2012 at 4:04 PM, wren ng thornton wrote:
> On 5/6/12 8:59 AM, Sebastien Zany wrote:
>
>> Hi,
>>
>> Suppose I have the following types:
>>
>> data Expr expr = Lit Nat | Add (expr, expr)
>>> newtype Fix f = Fix {unFix :: f (Fix f)}
>>>
>>
>> I can construct a sample term:
>>
>> term :: Expr (Expr (Expr expr))
>>> term = Add (Lit 1, Add (Lit 2, Lit 3))
>>>
>>
>> But isn't quite what I need. What I really need is:
>>
>> term' :: Fix Expr
>>> term' = Fix . Add $ (Fix . Lit $ 1, Fix . Add $ (Fix . Lit $ 2, Fix . Lit
>>>
>> $ 3))
>>
>> I feel like there's a stupidly simple way to automatically produce term'
>> from term, but I'm not seeing it.
>>
>
> There's the smart constructors approach to building term' in the first
> place, but if someone else is giving you the term and you need to convert
> it, then you'll need to use a catamorphism (or similar).
>
> That is, we already have:
>
>Fix :: Expr (Fix Expr) -> Fix Expr
>
> but we need to plumb this down through multiple layers:
>
>fmap Fix :: Expr (Expr (Fix Expr)) -> Expr (Fix Expr)
>
>fmap (fmap Fix) :: Expr (Expr (Expr (Fix Expr)))
>-> Expr (Expr (Fix Expr))
>
>...
>
> If you don't know how many times the incoming term has been unFixed, then
> you'll need a type class to abstract over the n in fmap^n Fix. How exactly
> you want to do that will depend on the application, how general it should
> be, etc. The problem, of course, is that we don't have functor composition
> for free in Haskell. Francesco's suggestion is probably the easiest:
>
>instance Functor Expr where
>fmap _ (Lit i) = Lit i
>fmap f (Add e1 e2) = Add (f e1) (f e2)
>
>class FixExpr e where
>fix :: e -> Fix Expr
>
>instance FixExpr (Fix Expr) where
>fix = id
>
>instance FixExpr e => FixExpr (Expr e) where
>fix = Fix . fmap fix
>
> Note that the general form of catamorphisms is:
>
>cata :: Functor f => (f a -> a) -> Fix f -> a
>cata f = f . fmap (cata f) . unFix
>
> so we're just defining fix = cata Fix, but using induction on the type
> term itself (via type classes) rather than doing induction on the value
> term like we usually would.
>
> --
> Live well,
> ~wren
>
>
> __**_
> 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] Fixed point newtype confusion
To slightly alter the question, is there a way to define a class
> class (Functor f) => Fixpoint f x where
> ...
so that I can define something with a type signature that looks like
> something :: (Fixpoint f x) => ... x ...
which will accept any
> argument :: F (F (F ... (F a) ... ))
in place of x?
Or alternatively could something analogous be done with type families?
Thanks,
Sebastien
On Mon, May 7, 2012 at 5:45 PM, Sebastien Zany <
sebast...@chaoticresearch.com> wrote:
> Thanks Wren!
>
> When I try
> > fix term
> ghci complains of an ambiguous type variable.
>
> I have to specify
> > term :: (Expr (Expr (Expr (Fix Expr
> for it to work.
>
> Is there a way around this?
>
> On Sun, May 6, 2012 at 4:04 PM, wren ng thornton wrote:
>
>> On 5/6/12 8:59 AM, Sebastien Zany wrote:
>>
>>> Hi,
>>>
>>> Suppose I have the following types:
>>>
>>> data Expr expr = Lit Nat | Add (expr, expr)
newtype Fix f = Fix {unFix :: f (Fix f)}
>>>
>>> I can construct a sample term:
>>>
>>> term :: Expr (Expr (Expr expr))
term = Add (Lit 1, Add (Lit 2, Lit 3))
>>>
>>> But isn't quite what I need. What I really need is:
>>>
>>> term' :: Fix Expr
term' = Fix . Add $ (Fix . Lit $ 1, Fix . Add $ (Fix . Lit $ 2, Fix .
Lit
>>> $ 3))
>>>
>>> I feel like there's a stupidly simple way to automatically produce term'
>>> from term, but I'm not seeing it.
>>>
>>
>> There's the smart constructors approach to building term' in the first
>> place, but if someone else is giving you the term and you need to convert
>> it, then you'll need to use a catamorphism (or similar).
>>
>> That is, we already have:
>>
>>Fix :: Expr (Fix Expr) -> Fix Expr
>>
>> but we need to plumb this down through multiple layers:
>>
>>fmap Fix :: Expr (Expr (Fix Expr)) -> Expr (Fix Expr)
>>
>>fmap (fmap Fix) :: Expr (Expr (Expr (Fix Expr)))
>>-> Expr (Expr (Fix Expr))
>>
>>...
>>
>> If you don't know how many times the incoming term has been unFixed, then
>> you'll need a type class to abstract over the n in fmap^n Fix. How exactly
>> you want to do that will depend on the application, how general it should
>> be, etc. The problem, of course, is that we don't have functor composition
>> for free in Haskell. Francesco's suggestion is probably the easiest:
>>
>>instance Functor Expr where
>>fmap _ (Lit i) = Lit i
>>fmap f (Add e1 e2) = Add (f e1) (f e2)
>>
>>class FixExpr e where
>>fix :: e -> Fix Expr
>>
>>instance FixExpr (Fix Expr) where
>>fix = id
>>
>>instance FixExpr e => FixExpr (Expr e) where
>>fix = Fix . fmap fix
>>
>> Note that the general form of catamorphisms is:
>>
>>cata :: Functor f => (f a -> a) -> Fix f -> a
>>cata f = f . fmap (cata f) . unFix
>>
>> so we're just defining fix = cata Fix, but using induction on the type
>> term itself (via type classes) rather than doing induction on the value
>> term like we usually would.
>>
>> --
>> Live well,
>> ~wren
>>
>>
>> __**_
>> 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] Fixed point newtype confusion
On 5/7/12 8:55 PM, Sebastien Zany wrote: To slightly alter the question, is there a way to define a class class (Functor f) => Fixpoint f x where ... You can just do that (with MPTCs enabled). Though the usability will be much better if you use fundeps or associated types in order to constrain the relation between fs and xs. E.g.: -- All the following require the laws: -- > fix . unfix == id -- > unfix . fix == id -- With MPTCs and fundeps: class (Functor f) => Fixpoint f x | f -> x where fix :: f x -> x unfix :: x -> f x class (Functor f) => Fixpoint f x | x -> f where fix :: f x -> x unfix :: x -> f x class (Functor f) => Fixpoint f x | f -> x, x -> f where fix :: f x -> x unfix :: x -> f x -- With associated types: -- (Add a type/data family if you want both Fix and Pre.) class (Functor f) => Fixpoint f where type Fix f :: * fix :: f (Fix f) -> Fix f unfix :: Fix f -> f (Fix f) class (Functor f) => Fixpoint f where data Fix f :: * fix :: f (Fix f) -> Fix f unfix :: Fix f -> f (Fix f) class (Functor (Pre x)) => Fixpoint x where type Pre x :: * -> * fix :: Pre x x -> x unfix :: x -> Pre x x class (Functor (Pre x)) => Fixpoint x where data Pre x :: * -> * fix :: Pre x x -> x unfix :: x -> Pre x x Indeed, that last one is already provided in the fixpoint[1] package, though the names are slightly different. The differences between using "x -> f", "f -> x", or both, and between using "data" or "type", are how it affects inference. That is, implicitly there are two relations on types: Fix \subseteq * \cross * Pre \subseteq * \cross * And we need to know: (1) are these relations functional or not? And, (2) are they injective or not? The answers to those questions will affect how you can infer one of the types (f or x) given the other (x or f). [1] http://hackage.haskell.org/package/fixpoint -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can Haskell outperform C++?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > Can anyone provide a code in Haskell that performs better in terms > of execution speed than a well-written C/C++ program? http://shootout.alioth.debian.org/ compares a lot of programming languages on a lot of problems. Haskell is never as fast as C++, but for some problems it comes close. Also I challenge anyone to improve one of the haskell programs there. It'd be cool if we could make haskell get a higher rank. I recently managed to improve the Fasta algorithm, but not by much. Also I think the benchmarks don't use llvm flag. It says somewhere that they don't measure llvm because they don't have time. But I think they are refering to clang. So maybe someone should tell them to turn on the llvm flag since it makes a lot of haskell programs faster. Silvio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPqKicAAoJEDLsP+zrbatWmSIP+gNSI61KMvY2VRsWRhd7+j5U YAO3CnBTt6lSbMNplFf5AZnbPnY3NVJSG2ZUN12n7ZcaOawmwub3H+N9e0XTXv38 vOEGzFb/t/OTIx4GHXiWz6kZfzyiTVQpEhzoqx/ZX4KZqrUBt5ZuSpmWtPrPXCfF joCZiBZIwxfOkI/l1zsb8vW3Xaqxs9dfRQOJEf7GLB5zGXwUA2ZLWG5HYvAUHu0G 9xB9cBgaX7HKdBwo3af2WZEFznZnZ1LUpc8TuacL54wVmLpLNJU2EaeqH2LsH0R3 VxX9yU1TIQUBubDa1Tui73xJ2L4Ns7AVD7Kx14yK5cu61wpz/KeUOU/wgedp+wNe o54alfqzrfOC+GAJGJFg+3aIkXuij4j1jTXZ+/3ya7nofcBZwtqoZUWCvjYSoEaI xecxuHLCK2pd3zwPk7ZUnG0Mo0vu4ZpVKpCs4u8nPRzVl0101mGkHSVTVXjVP8R/ d3AIPwy74B4nvCk9gohxHwtsvsmzxoRZr7E5XkGDTQdbj0Ly5bJfBW3c1X/jvq9c FHvxCspERGf6S+aX9L6lg9v3/aje/av2q0zUL7jizA4no3q7D/ZvWkmIWF5ySyRh +QrC39I6GHDMvxXn0HIp9m2226sNGL4vpvBTgucJWJcHUX+FdytFIe7VQ0ZvdXvx IjxCrgMAPVy5/TH44PP+ =TaFj -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
