Hello,
I have attached a new version that should work with GHC 6.10, though I have
not tested it.
The older Data.Data uses mkNorepType instead of mkNoRepType. I just changed
the patch to use the older spelling. In GHC = 6.12 this will issue a
warning that the old spelling has been deprecated.
On Fri, Feb 5, 2010 at 9:33 AM, Jeremy Shaw jer...@n-heptane.com wrote:
I have attached a new version that should work with GHC 6.10, though I have
not tested it.
Thanks. I fixed the compilation warning, added a Data instance for lazy
Text, and released 0.7.1.0.
Attached.
Thanks!
- jeremy
On Sun, Jan 31, 2010 at 1:34 AM, Bryan O'Sullivan b...@serpentine.comwrote:
On Tue, Jan 26, 2010 at 10:08 AM, Jeremy Shaw jer...@n-heptane.comwrote:
I think so... none of the other instances do.. but I guess that is not a
very good excuse :)
Send me a final
On Mon, Feb 1, 2010 at 12:08 PM, Jeremy Shaw jer...@n-heptane.com wrote:
Attached.
Data/Text.hs:175:63:
Module `Data.Data' does not export `mkNoRepType'
Can you send a followup patch that works against GHC 6.10.4, please?
___
Haskell-Cafe
On Tue, Jan 26, 2010 at 10:08 AM, Jeremy Shaw jer...@n-heptane.com wrote:
I think so... none of the other instances do.. but I guess that is not a
very good excuse :)
Send me a final darcs patch, and I'll apply it.
___
Haskell-Cafe mailing list
2010/1/26 José Pedro Magalhães j...@cs.uu.nl
Hi Jeremy,
As Neil Mitchell said before, if you really don't want to expose the
internals of Text (by just using a derived instance) then you have no other
alternative than to use String conversion. If you've been using it already
and performance
Hello,
Attached is my new and improved patch to add a Data instance to Data.Text.
The patch just adds:
+-- This instance preserves data abstraction at the cost of inefficiency.
+-- We omit reflection services for the sake of data abstraction.
+
+instance Data Text where
+ gfoldl f z txt = z
On Tue, Jan 26, 2010 at 11:52:34AM -0600, Jeremy Shaw wrote:
+ toConstr _ = error toConstr
+ gunfold _ _= error gunfold
Isn't it better to write
error Data.Text.Text: toConstr
Usually I try to do this as we don't get stack traces for _|_.
--
Felipe.
On Tue, Jan 26, 2010 at 11:55 AM, Felipe Lessa felipe.le...@gmail.comwrote:
On Tue, Jan 26, 2010 at 11:52:34AM -0600, Jeremy Shaw wrote:
+ toConstr _ = error toConstr
+ gunfold _ _= error gunfold
Isn't it better to write
error Data.Text.Text: toConstr
Usually I try to do
Hi
The problem with Data for Text isn't that we have to write a new
instance, but that you could argue that proper handling of Text with
Data would not be using a type class, but have special knowledge baked
in to Data. That's far worse than the Serialise problem mentioned
above, and no one
On Sun, Jan 24, 2010 at 5:49 AM, Neil Mitchell ndmitch...@gmail.com wrote:
Hi,
The problem with Data for Text isn't that we have to write a new
instance, but that you could argue that proper handling of Text with
Data would not be using a type class, but have special knowledge baked
in to
Hi Jeremy,
As Neil Mitchell said before, if you really don't want to expose the
internals of Text (by just using a derived instance) then you have no other
alternative than to use String conversion. If you've been using it already
and performance is not a big problem, then I guess it's ok.
Hi,
The problem with Data for Text isn't that we have to write a new
instance, but that you could argue that proper handling of Text with
Data would not be using a type class, but have special knowledge baked
in to Data. That's far worse than the Serialise problem mentioned
above, and no one
Would it be possible to get a Data instance for Data.Text.Text?
From the last time this came up, I gather that the correctish thing to do
(for reasons too obscure to me) is to teach SYB and its many cousins about
Text, or else there'll be some sort of disturbance in the Force.
No, that's
On Sat, Jan 23, 2010 at 7:57 AM, Neil Mitchell ndmitch...@gmail.comwrote:
No, that's definitely not correct, or even remotely scalable as we
increase the number of abstract types in disparate packages.
Yes.. happstack is facing another aspect of this scalability issue as well.
We have a
On Sat, 23 Jan 2010 16:57:49 -0600, Jeremy Shaw jer...@n-heptane.com wrote:
On Sat, Jan 23, 2010 at 7:57 AM, Neil Mitchell ndmitch...@gmail.comwrote:
No, that's definitely not correct, or even remotely scalable as we
increase the number of abstract types in disparate packages.
Yes..
On Sat, Jan 23, 2010 at 4:57 PM, Jeremy Shaw jer...@n-heptane.com wrote:
On Sat, Jan 23, 2010 at 7:57 AM, Neil Mitchell ndmitch...@gmail.com
wrote:
No, that's definitely not correct, or even remotely scalable as we
increase the number of abstract types in disparate packages.
Yes..
The only safe rule is: if you don't control the class, C, or you don't
control the type constructor, T, don't make instance C T.
I agree in principle, but in the real world you can't live by this rule.
Example, I want to use Uniplate to traverse the tree built by haskell-src-exts,
Using
On Fri, Jan 22, 2010 at 2:24 PM, Jeremy Shaw jer...@n-heptane.com wrote:
Would it be possible to get a Data instance for Data.Text.Text?
From the last time this came up, I gather that the correctish thing to do
(for reasons too obscure to me) is to teach SYB and its many cousins about
Text,
19 matches
Mail list logo
