Is any of the existing Generics packages able to work without compiler extensions, that is Haskell 98? I mean, it is ok if the developer of the generic parts of a library needs compiler extensions or extra tools, but the user who calls 'cabal install' shall not need them and the developer, who does not touch generic definitions, should not need them as well. I think this could be done with pragmas in the following way: class C a where f :: a -> [Int] {-# GENERICDEFAULT f {| Unit |} Unit = [] #-} {-# GENERATEDINSTANCEBEGIN Automatically generated - Do not edit! #-} instance C () where f () = [] {-# GENERATEDINSTANCEEND Automatically generated - Do not edit! #-} Now, by running a tool, the part between the GENERATEDINSTANCE pragmas can generated or updated. Everything outside the pragmas can be Haskell 98. It does not only avoid extensions of the building compiler, but also extensions of a programmer's brain. Because for programmers it is often easier to understand a set of instances and see the common patterns, than to understand generic code that builds the instances.
Hi Henning,
Uniplate might be the answer you are looking for -
http://community.haskell.org/~ndm/uniplate
Uniplate is simple (only multi parameter type classes, and even then
only in a very simple usage), fast (one of the fastest generics
libraries) and concise (probably the most concise generics library).
It's also not as powerful as most of the other generics libraries, but
I find it does about 98% of the generics tasks I need. Uniplate is
used extensively in virtually all my tools, for example HLint.
As an example, I guess your function returns all the Int's embedded
within a data type, at any level? If so, uniplate already has the
universeBi method which does that for you, and doesn't require you to
do anything.
Thanks, Neil
2010/1/16 Henning Thielemann
Is any of the existing Generics packages able to work without compiler extensions, that is Haskell 98? I mean, it is ok if the developer of the generic parts of a library needs compiler extensions or extra tools, but the user who calls 'cabal install' shall not need them and the developer, who does not touch generic definitions, should not need them as well.
I think this could be done with pragmas in the following way:
class C a where f :: a -> [Int] {-# GENERICDEFAULT f {| Unit |} Unit = [] #-}
{-# GENERATEDINSTANCEBEGIN Automatically generated - Do not edit! #-} instance C () where f () = [] {-# GENERATEDINSTANCEEND Automatically generated - Do not edit! #-}
Now, by running a tool, the part between the GENERATEDINSTANCE pragmas can generated or updated. Everything outside the pragmas can be Haskell 98.
It does not only avoid extensions of the building compiler, but also extensions of a programmer's brain. Because for programmers it is often easier to understand a set of instances and see the common patterns, than to understand generic code that builds the instances.
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Neil, Monday, January 18, 2010, 10:56:00 PM, you wrote:
Uniplate might be the answer you are looking for - http://community.haskell.org/~ndm/uniplate
it's brilliant! some people has the talent to discover complex things and you have the talent to make complex things simple. it's first and only generics library that i can easily learn and remember can you give a permission to translate http://community.haskell.org/~ndm/darcs/uniplate/uniplate.htm to Russian for http://fprog.ru/ online functional programming journal? -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat,
Uniplate might be the answer you are looking for - http://community.haskell.org/~ndm/uniplate
it's brilliant! some people has the talent to discover complex things and you have the talent to make complex things simple. it's first and only generics library that i can easily learn and remember
I'm very glad you like it :-)
can you give a permission to translate http://community.haskell.org/~ndm/darcs/uniplate/uniplate.htm to Russian for http://fprog.ru/ online functional programming journal?
Yes, that sounds great. However, I'm currently not a particular fan of the manual in it's current state - it isn't that well written and some bits need expanding. How about I revamp it, then let you know? I can probably do it within the next few weeks. Thanks, Neil
Hello Neil, Tuesday, January 19, 2010, 10:15:15 PM, you wrote:
can you give a permission to translate http://community.haskell.org/~ndm/darcs/uniplate/uniplate.htm to Russian for http://fprog.ru/ online functional programming journal?
Yes, that sounds great. However, I'm currently not a particular fan of the manual in it's current state - it isn't that well written and some bits need expanding. How about I revamp it, then let you know? I can probably do it within the next few weeks.
it would be even better. i just finished reading your paper - tutorial doesn't emphasize some details i've found there, in particular restrictions of Uniplate and how these are particularly overcomed by BiPlate. i.e. it may be derived from tutorial but wasn't obvious for me before i've read the paper -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Hi Bulat,
The intention was always that the manual should be an up-to-date
version that contains everything people need to use the library, but
not the internal details. The paper was revised in to my thesis
chapter, which is probably the best description of the internals of
Uniplate. The thesis chapter is reasonably complete, but the manual
isn't - I'll move some of the interesting material across -
particularly on Biplate.
Thanks, Neil
2010/1/19 Bulat Ziganshin
Hello Neil,
Tuesday, January 19, 2010, 10:15:15 PM, you wrote:
can you give a permission to translate http://community.haskell.org/~ndm/darcs/uniplate/uniplate.htm to Russian for http://fprog.ru/ online functional programming journal?
Yes, that sounds great. However, I'm currently not a particular fan of the manual in it's current state - it isn't that well written and some bits need expanding. How about I revamp it, then let you know? I can probably do it within the next few weeks.
it would be even better. i just finished reading your paper - tutorial doesn't emphasize some details i've found there, in particular restrictions of Uniplate and how these are particularly overcomed by BiPlate. i.e. it may be derived from tutorial but wasn't obvious for me before i've read the paper
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
Neil Mitchell schrieb:
Hi Henning,
Uniplate might be the answer you are looking for - http://community.haskell.org/~ndm/uniplate
Thanks for the pointer!
Uniplate is simple (only multi parameter type classes, and even then only in a very simple usage), fast (one of the fastest generics libraries) and concise (probably the most concise generics library). It's also not as powerful as most of the other generics libraries, but I find it does about 98% of the generics tasks I need. Uniplate is used extensively in virtually all my tools, for example HLint.
Must a package import Uniplate, if it uses Uniplate generics, or is it a preprocessor like I sketched?
As an example, I guess your function returns all the Int's embedded within a data type, at any level? I abstracted the Bin example from GHC's generic extension introduction:
http://www.haskell.org/ghc/docs/latest/html/users_guide/generic-classes.html
Hi Henning,
Uniplate is simple (only multi parameter type classes, and even then only in a very simple usage), fast (one of the fastest generics libraries) and concise (probably the most concise generics library). It's also not as powerful as most of the other generics libraries, but I find it does about 98% of the generics tasks I need. Uniplate is used extensively in virtually all my tools, for example HLint.
Must a package import Uniplate, if it uses Uniplate generics, or is it a preprocessor like I sketched?
Uniplate is a library, not a preprocessor. To depend on uniplate simply add it to your cabal file, and import the correct module. There is no preprocessor, and there are no wacky extensions. If you restrict yourself to some part of the library it's even totally Haskell 98, but none of it's not Haskell 2011.
As an example, I guess your function returns all the Int's embedded within a data type, at any level?
I abstracted the Bin example from GHC's generic extension introduction:
That's one thing Uniplate can't do. But if you want a preprocessor to generate Binary instances can I recommend Derive (http://community.haskell.org/~ndm/derive). Thanks, Neil
participants (3)
-
Bulat Ziganshin -
Henning Thielemann -
Neil Mitchell