Re: [GHC] #1835: Provide information of the instance environment
#1835: Provide information of the instance environment
---+
Reporter: guest | Owner: igloo
Type: feature request | Status: patch
Priority: normal| Milestone: _|_
Component: Template Haskell |Version: 6.8.1
Resolution:| Keywords:
Testcase:| Blockedby:
Difficulty: Unknown | Os: Unknown/Multiple
Blocking:| Architecture: Unknown/Multiple
Failure: None/Unknown |
---+
Comment(by Ashley Yakeley):
{{{
class C a
instance C a = C [a]
}}}
If I lookup an instance for C [Int], how I discover that C Int is
context for it? Do I have to reify C and search its instances attempting
to type-match?
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1835#comment:20
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4102: Bit manipulation built-ins
#4102: Bit manipulation built-ins -+-- Reporter: uzytkownik|Owner: Type: feature request | Status: new Priority: normal|Milestone: 6.16.1 Component: libraries/base| Version: 6.12.2 Keywords:| Testcase: Blockedby:| Difficulty: Os: Unknown/Multiple | Blocking: Architecture: Unknown/Multiple | Failure: None/Unknown -+-- Comment(by gwicke): I have moved the code to a separate repository now, you can retrieve it with mercurial using: hg clone http://dev.wikidev.net/hg/bits-extras/ Tar/Zip etc download is also available at this url. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4102#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #3563: A couple of additions to Data.Bits
#3563: A couple of additions to Data.Bits
-+--
Reporter: porges|Owner:
Type: proposal | Status: new
Priority: normal|Milestone: Not GHC
Component: libraries/base| Version: 6.11
Keywords:| Testcase:
Blockedby:| Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
-+--
Changes (by gwicke):
* cc: gabr...@… (added)
Comment:
I have created a package with bindings to GCC's built-in bit operations,
which normally exploit native instructions and are thus faster than an
implementation in terms of current Data.Bits primitives:
* Browse: http://dev.wikidev.net/hg/bits-extras/file/tip
* Checkout using Mercurial: {{{hg clone http://dev.wikidev.net/hg/bits-
extras}}}
This fills my current needs, but is just a stop-gap until GHC has full
support for these operations. Ticket #4102 discusses native support for
these higher-level operations in GHC.
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/3563#comment:4
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1835: Provide information of the instance environment
#1835: Provide information of the instance environment ---+ Reporter: guest | Owner: igloo Type: feature request | Status: patch Priority: normal| Milestone: _|_ Component: Template Haskell |Version: 6.8.1 Resolution:| Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by SamAnklesaria): You can easily look up whether `[Int]` is an instance of `C` with `isClassInstance`. But there's no easy way at the moment to find out which instance makes that true; the most you can do, as you said, is reify the class to get all the instances and hunt around. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1835#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #1835: Provide information of the instance environment
#1835: Provide information of the instance environment ---+ Reporter: guest | Owner: igloo Type: feature request | Status: patch Priority: normal| Milestone: _|_ Component: Template Haskell |Version: 6.8.1 Resolution:| Keywords: Testcase:| Blockedby: Difficulty: Unknown | Os: Unknown/Multiple Blocking:| Architecture: Unknown/Multiple Failure: None/Unknown | ---+ Comment(by illissius): Just having isClassInstance fulfills my immediate needs; I don't know what I'll want or need in the future. If I could, I'd like to have a pony and the ability to map in the reverse direction, i.e. from types to the classes they're instances of. (But presumably that can also be added separately later.) Thanks for implementing this. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/1835#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #4237: -dcore-lint error after simplifier iteration 1 when profiling
#4237: -dcore-lint error after simplifier iteration 1 when profiling
-+--
Reporter: wkahl |Owner:
Type: bug | Status: infoneeded
Priority: high |Milestone: 6.14.1
Component: Compiler | Version: 6.12.3
Keywords: profiling, simplifier, core-lint | Testcase:
Blockedby: 4172, 4186| Difficulty:
Os: Linux | Blocking:
Architecture: x86_64 (amd64)| Failure: Compile-time
crash
-+--
Comment(by wkahl):
What does ``this patch'' refer to exactly? Is there an easy way to apply
it to a 6.12.3 source distribution?
Installing HEAD currently fails with
{{{
echo 'pgmgcc=/usr/bin/gcc'
/usr/local/packages/ghc-6.13/bin/haddock-6.13.20100813
cat utils/haddock/haddock.wrapper
/usr/local/packages/ghc-6.13/bin/haddock-6.13.20100813
chmod +x
/usr/local/packages/ghc-6.13/bin/haddock-6.13.20100813
/usr/bin/install -c -m 755 -d
/usr/local/packages/ghc-6.13/share/doc/ghc/html
cp -R utils/haddock/html
/usr/local/packages/ghc-6.13/share/doc/ghc/html
/usr/bin/install -c -m 755 -d
/usr/local/packages/ghc-6.13/lib/ghc-6.13.20100813/html
for i in utils/haddock/html/*; do \
/usr/bin/install -c -m 644 $i
/usr/local/packages/ghc-6.13/lib/ghc-6.13.20100813/html; \
done
/usr/bin/install: omitting directory `utils/haddock/html/Classic.theme'
/usr/bin/install: omitting directory `utils/haddock/html/Ocean.std-theme'
/usr/bin/install: omitting directory `utils/haddock/html/Snappy.theme'
make[1]: *** [install_utils/haddock_data] Error 1
make: *** [install] Error 2
}}}
...
Wolfram
--
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4237#comment:3
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] Gtk2Hs 0.11.1 released
Dear all, after a few months of shaking out bugs, we've released a new patch- level version of Gtk2Hs, the binding to the Gtk+ GUI library suite. Notable changes: - several bug fixes with respect to concurrency on a variety of platforms - linking problems in ghci have been resolved - pango now includes functions to draw text on Cairo surfaces; this makes it possible to render Unicode text into PDF/PS/SVG/PNG documents without the need for the GUI part in the gtk package - we included the demos in the tar balls (we forgot that last time...) - other bug fixes Please see our web-site http://www.haskell.org/gtk2hs/ for further information and read http://code.haskell.org/gtk2hs/INSTALL if you plan to give it a go! Cheers, Axel ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Gtk2Hs 0.11.1 released
Thanks for the release! The following packages are deprecated: * gnomevfs (replaced by gio) I am using the file-monitoring feature of gnomevfs, but I find no replacement in gio. What is my best move? Thanks again, JP. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Re: gtk2hs with old gtk2
Johannes Waldmann waldm...@imn.htwk-leipzig.de writes: Andy Stewart lazycat.manatee at gmail.com writes: Just cabal install is enough. Hm. That's what bootstrap.sh does, and it builds tools, then glib, but then: Preprocessing library gio-0.11.0... gtk2hsC2hs: Errors during expansion of binding hooks: ./System/GIO/Types.chs:584: (column 12) [ERROR] Unknown identifier! Cannot find a definition for `Emblem' in the header file. Because GEmblem is need Glib 2.18, mabye your glib is too old. You can use command 'pkg-config --modversion glib-2.0' check your glib version. Can you update your glib library? -- Andy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Is bumping the version number evil, if it's not mandated by the PVP?
Hello, I wonder whether (and how) I should increase the version number of a library when the API does not change but the implementation gets more efficient. Should I bump a.b.C or even a.B to signal that it's worth using the new version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically? When bumping only a.b.c.D, the new version is not installed as a dependency if the old version already is installed (unless the new version is explicitly demanded.) It seems bumping a.b.c.D has advantages for some users and disadvantages for others. Hence, I guess I should make a major version bump. Is it bad habit to make a major version bump if the API does not change? Maybe I should simply change the API too ;) Cheers, Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sifflet visual programming language, release 1.0!
gdwe...@iue.edu wrote: About Sifflet - Sifflet is a visual, functional programming language intended as an aid for learning about recursion. * A picture explains Sifflet better than words: please see the screenshot showing how to evaluate 3!: http://mypage.iu.edu/~gdweber/software/sifflet/home.html This looks extremely cool. Hopefully I'll be able to test this out a bit later (assuming it works on Windows)... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Johan Tibell wrote: On Fri, Aug 13, 2010 at 4:24 PM, Kevin Jardine kevinjard...@gmail.com mailto:kevinjard...@gmail.com wrote: One of the more puzzling aspects of Haskell for newbies is the large number of libraries that appear to provide similar/duplicate functionality. I agree. Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. Those libraries have benchmarks and have been well tuned by experienced Haskelleres and should be the fastest and most memory compact in most cases. There are still a few cases where String beats Text but they are being worked on as we speak. Interesting. I've never even heard of Data.Text. When did that come into existence? More importantly: How does the average random Haskeller discover that a package has become available that might be relevant to their work? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
* Bryan O'Sullivan: If you know it's text and not binary data you are working with, you should still use Data.Text. There are a few good reasons. 1. The API is more correct. For instance, if you use Text.toUpper on a string containing latin1 ß (eszett, sharp S), you'll get the two-character sequence SS, which is correct. Using Char8.map Char.toUpper here gives the wrong answer. Data.Text ist still incorrect for some scripts: $ LANG=tr_TR.UTF-8 ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude import Data.Text Prelude Data.Text toUpper $ pack i Loading package array-0.3.0.0 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package deepseq-1.1.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package text-0.7.2.1 ... linking ... done. I Prelude Data.Text ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ATs vs FDs
As I understand it, ATs were invented because FDs are evil and must never be used ever for any purpose. However, it doesn't seem to be possible to use ATs to do the same things that FDs can do. You can use ATs to write type functions, which take one type and return another type. This allows you to express type relationships in a very elegant way. However, what it does /not/ seem to allow you to do is express one-to-one relationships. For example, I'd like to be able to say that the next vector up from a Vector3 is a Vector4, and the next vector down is a Vector2. And I can say that. What I can't say is that the *only* next vector up is a Vector4. And thus, all my code is littered with ambiguous type warnings because although /currently/ there's only one class instance, somebody could come along some day and write another one. What am I missing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Andrew Coppin andrewcop...@btinternet.com writes: Interesting. I've never even heard of Data.Text. When did that come into existence? The first version hit Hackage in February last year... More importantly: How does the average random Haskeller discover that a package has become available that might be relevant to their work? Look on Hackage; subscribe to mailing lists (where package maintainers should really write announcement emails), etc. It's rather surprising you haven't heard of text: it is for benchmarking this that Bryan wrote criterion; there's emails on -cafe and blog posts that mention it on a semi-regular basis, etc. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 12:15 PM, Florian Weimer f...@deneb.enyo.de wrote: * Bryan O'Sullivan: If you know it's text and not binary data you are working with, you should still use Data.Text. There are a few good reasons. 1. The API is more correct. For instance, if you use Text.toUpper on a string containing latin1 ß (eszett, sharp S), you'll get the two-character sequence SS, which is correct. Using Char8.map Char.toUpper here gives the wrong answer. Data.Text ist still incorrect for some scripts: $ LANG=tr_TR.UTF-8 ghci GHCi, version 6.12.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude import Data.Text Prelude Data.Text toUpper $ pack i Loading package array-0.3.0.0 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package deepseq-1.1.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package text-0.7.2.1 ... linking ... done. I Prelude Data.Text Yes. We need locale support for that one. I think Bryan is planning to add it. -- Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is bumping the version number evil, if it's not mandated by the PVP?
Sebastian Fischer s...@informatik.uni-kiel.de writes: Hello, I wonder whether (and how) I should increase the version number of a library when the API does not change but the implementation gets more efficient. If the API remains the same (and the behaviour of the functions does as well), then according to the PVP the minimum required is to bump a.b.c.D. Should I bump a.b.C or even a.B to signal that it's worth using the new version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically? I think this is the best approach overall, as the effects will be noticed by users immediately (rather than waiting for maintainers to notice there's a new version and be bothered to check if they can make their library use that new version: for example, HXT is using a version of tagsoup that is two major versions out of date). Making a big hue and cry about it on the mailing lists, planet.haskell.org, etc. might help draw attention to the nice new shiny performance with the added bonus of code using that library not having to change. Hence, I guess I should make a major version bump. Is it bad habit to make a major version bump if the API does not change? It depends on how many people use your library; if the number is small enough and manageable enough then you can try to get into contact with maintainers that use your library and make sure they expand the constraints on your package such that the new version is available to be used. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] ATs vs FDs
-- Forwarded message -- From: Gábor Lehel illiss...@gmail.com Date: 2010/8/14 Subject: Re: [Haskell-cafe] ATs vs FDs To: Andrew Coppin andrewcop...@btinternet.com You're missing equality constraints for classes. In other words: class (a ~ Smaller (Bigger a), a ~ Bigger (Smaller a)) = Vector a where type Bigger a; type Smaller a FDs and TFs are equivalent in theory, however their implementation in GHC has shortcomings on (I believe) both sides. In this case, GHC unfortunately doesn't yet support equality constraints in class contexts, which you would need to do some of the things FDs can do. I believe there are workarounds for this in some cases, including one which uses plain type classes to encode not-quite-equality, and one where you just add the constraints to every method of the class instead, but I don't know the details. On Sat, Aug 14, 2010 at 12:19 PM, Andrew Coppin andrewcop...@btinternet.com wrote: As I understand it, ATs were invented because FDs are evil and must never be used ever for any purpose. However, it doesn't seem to be possible to use ATs to do the same things that FDs can do. You can use ATs to write type functions, which take one type and return another type. This allows you to express type relationships in a very elegant way. However, what it does /not/ seem to allow you to do is express one-to-one relationships. For example, I'd like to be able to say that the next vector up from a Vector3 is a Vector4, and the next vector down is a Vector2. And I can say that. What I can't say is that the *only* next vector up is a Vector4. And thus, all my code is littered with ambiguous type warnings because although /currently/ there's only one class instance, somebody could come along some day and write another one. What am I missing? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Work is punishment for failing to procrastinate effectively. -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is bumping the version number evil, if it's not mandated by the PVP?
[CC'ing café again] On Aug 14, 2010, at 12:25 PM, Max Rabkin wrote: On Sat, Aug 14, 2010 at 11:13 AM, Sebastian Fischer s...@informatik.uni-kiel.de wrote: Hello, I wonder whether (and how) I should increase the version number of a library when the API does not change but the implementation gets more efficient. Should I bump a.b.C or even a.B to signal that it's worth using the new version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically? My understanding is that the PVP only describes the *minimum* version bump, not the maximum. There is a third option though: give the updated version two version numbers, one with an a.b.c.D bump so that reverse dependencies get the performance improvement, and one with an a.b.C bump so that users see a new version as worthwhile. That's an interesting idea! In my case I'll probably bump version a.b.c.D with unchanged API but better performance and additionally release a new major version with a new API as well (as I planned to extend the API independently). Thanks! Sebastian -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Ivan Lazar Miljenovic wrote: Andrew Coppin andrewcop...@btinternet.com writes: More importantly: How does the average random Haskeller discover that a package has become available that might be relevant to their work? Look on Hackage; subscribe to mailing lists (where package maintainers should really write announcement emails), etc. OK. I guess I must have missed that one... It's rather surprising you haven't heard of text: it is for benchmarking this that Bryan wrote criterion; there's emails on -cafe and blog posts that mention it on a semi-regular basis, etc. Well, I suppose I don't do a lot of text processing work... If all you're trying to do is parse commands from an interactive terminal prompt, [Char] is probably good enough. (What I do do is process big chunks of binary data - which is what ByteString is intended for.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
Andrew Coppin andrewcop...@btinternet.com writes: As I understand it, ATs were invented because FDs are evil and must never be used ever for any purpose. However, it doesn't seem to be possible to use ATs to do the same things that FDs can do. You can use ATs to write type functions, which take one type and return another type. This allows you to express type relationships in a very elegant way. However, what it does /not/ seem to allow you to do is express one-to-one relationships. For example, I'd like to be able to say that the next vector up from a Vector3 is a Vector4, and the next vector down is a Vector2. And I can say that. What I can't say is that the *only* next vector up is a Vector4. And thus, all my code is littered with ambiguous type warnings because although /currently/ there's only one class instance, somebody could come along some day and write another one. I assume you mean something like this? , | class NextOneUpFD this previous | this - previous where ... | | instance NextOneUpFD Vector3 Vector4 where ... ` If so, how does this not solve the issue? , | class NextOneUpAT v where | type Next v | ... | | instance NextOneUpAT Vector3 where | type Next Vector3 = Vector4 | ... ` -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
Ivan Lazar Miljenovic wrote: I assume you mean something like this? , | class NextOneUpFD this previous | this - previous where ... | | instance NextOneUpFD Vector3 Vector4 where ... ` More like class NextPrevFD next prev | next - prev, prev - next where... but yeah, that's the general idea. If so, how does this not solve the issue? , | class NextOneUpAT v where | type Next v | ... | | instance NextOneUpAT Vector3 where | type Next Vector3 = Vector4 | ... ` Can I use that to go both up and down? Would the types be unambiguous? I guess I'll have to go try it out... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is bumping the version number evil, if it's not mandated by the PVP?
On Sat, Aug 14, 2010 at 11:13:19AM +0200, Sebastian Fischer wrote: I wonder whether (and how) I should increase the version number of a library when the API does not change but the implementation gets more efficient. Should I bump a.b.C or even a.B to signal that it's worth using the new version or should I bump only a.b.c.D such that packages that depend on a.b get installed with the new version automatically? When bumping only a.b.c.D, the new version is not installed as a dependency if the old version already is installed (unless the new version is explicitly demanded.) It seems bumping a.b.c.D has advantages for some users and disadvantages for others. How would bumping the major version change that? Let's suppose a package depending on your declares a version constraint a.b.* (which would be good practice). If you bump the patch level, anyone installing the other package with get the latest version of your package; if you bump the major version, they won't, until the maintainer of the other package releases a new version to update their dependencies. (Some maintainers might be annoyed by that; if you annoy maintainers too much, they might look for less annoying dependencies.) Whenever you bump a version number, you are signalling that the new version is worth using. If you bump the patchlevel, you're also signalling that the new version is compatible with the old, so using it is a no-brainer. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
On 14 August 2010 11:19, Andrew Coppin andrewcop...@btinternet.com wrote: As I understand it, ATs were invented because FDs are evil and must never be used ever for any purpose. However, it doesn't seem to be possible to use ATs to do the same things that FDs can do. You might want to read the Language and Program Design for Functional Dependencies paper by Mark P. Jones and Iavor Diatchki. In some situations fundeps are much cleaner than type funs, and cleanliness is virtuous surely? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
Andrew Coppin andrewcop...@btinternet.com writes: Ivan Lazar Miljenovic wrote: I assume you mean something like this? , | class NextOneUpFD this previous | this - previous where ... | | instance NextOneUpFD Vector3 Vector4 where ... ` More like class NextPrevFD next prev | next - prev, prev - next where... but yeah, that's the general idea. Oh, I wasn't sure you could do that. If so, how does this not solve the issue? , | class NextOneUpAT v where | type Next v | ... | | instance NextOneUpAT Vector3 where | type Next Vector3 = Vector4 | ... ` Can I use that to go both up and down? Would the types be unambiguous? I guess I'll have to go try it out... Depends on how you use it; it might need to have a type Previous v in there as well, but I'm not sure how well that will cope when you get to the end of the line. One thing to note: GHC does not currently support superclass constraints, so it isn't possible to have something like: class (NextOneUpAT v1, NextOneUpAT v2, Next v1 ~ Next v2) = ... But you _can_ do so in a type signature for a function. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Andrew Coppin andrewcop...@btinternet.com writes: Well, I suppose I don't do a lot of text processing work... If all you're trying to do is parse commands from an interactive terminal prompt, [Char] is probably good enough. Neither do I, yet I've heard of it... ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Removing polymorphism from type classes (viz. Functor) (Again)
I was inspired by George Pollard's posthttp://www.haskell.org/pipermail/haskell-cafe/2009-July/063981.htmlat haskell-cafe and tried to implement the non-polymorphic Functor class ( I named it Functor' ). I changed some names and added reasonable constraints. type family NewPt f a class Functor' f where type Point f map ∷ (a ~ Point f, b ~ Point g, g ~ NewPt f b, Functor' g) ⇒ (a → b) → f → g I would like to be able to write: type OldPt f = NewPt f (Point f) class (f ~ OldPt f) ⇒ Functor' f ... but ghc says it's not implemented yet (version 6.12.1). However, it's not the main problem. Now I can write some instances: type instance NewPt [a] b = [b] instance Functor' [a] where type Point [a] = a map = fmap type instance NewPt ByteString a = ByteString instance Functor' ByteString where type Point ByteString = Word8 map = BS.map But I can't write instance for Set: type instance NewPt (Set a) b = Set b instance Ord a ⇒ Functor' (Set a) where type Point (Set a) = a map = Set.map ghci complains: Could not deduce (Ord a1) from the context (g ~ NewPt (Set a) a1, a1 ~ Point g, Functor' g) arising from a use of `Set.map' at ... The type of Set.map is Set.map :: (Ord a, Ord b) = (a - b) - Set a - Set b (Ord a) is in the instance context, and what about b? Type of map for Set instance would be: original: map ∷ (a ~ Point f, b ~ Point g, g ~ NewPt f b, Functor' g) ⇒ (a → b) → f → g substitute: f → Set a, g → Set b map :: Functor' (Set b) ⇒ (a →b) →Set a →Set b (Ord b) must be deduced from (Functor (Set b)) but it doesn't. I don't know whether it's my mistake somewhere or ghc problem. (Sorry for my English, it's not perfect). -- All the best, Alexey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing polymorphism from type classes (viz. Functor) (Again)
Alexey Karakulov ankaraku...@gmail.com writes: (Ord b) must be deduced from (Functor (Set b)) but it doesn't. I don't know whether it's my mistake somewhere or ghc problem. I've come across this problem as well; the best solution I've seen so far is the one taken by Ganesh in his rmonad library: http://hackage.haskell.org/package/rmonad -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Right, but if you use Prelude.interact, as in my example, you don't have to worry about the EOF checking yourself - it's all handled for you. And if you use a functional style, your code will be simpler and more testable - otherwise you might as well just use an imperative language. Here's a slightly better version (uses splitAt): maxLineLength :: Int maxLineLength = 72 wrapLine :: String - [String] wrapLine = [] wrapLine line | length line = maxLineLength= [line] | otherwise= let (line, rest) = splitAt maxLineLength line in line : wrapLine rest main :: IO () main = interact $ unlines . concatMap wrapLine . lines On Saturday Aug 14, 2010, at 12:38 AM, michael rice wrote: Hi Bill, Each quote of the input is on a single line. I want to unwrap lines greater than 72 characters, i.e., break them into several lines each = 72 characters, but I don't want to break up words. and I want to retain the blank lines. So, my output is correct except for the error message. Michael My input data However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not trouble yourself much to get new things, whether clothes or friends. Things do not change, we change. Sell your clothes and keep your thoughts. God will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a man to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was hoeing in a village garden, and I felt that I was more distinguished by that circumstance that I should have been by any epaulet I could have worn. -Thoreau My output unwrap: stdin: hGetLine: end of file here's my eof message However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not trouble yourself much to get new things, whether clothes or friends. Things do not change, we change. Sell your clothes and keep your thoughts. God will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a man to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was hoeing in a village garden, and I felt that I was more distinguished by that circumstance that I should have been by any epaulet I could have worn. -Thoreau Your output == However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not t rouble yourself much to get new things, whether clothes or friends. Thin gs do not change, we change. Sell your clothes and keep your thoughts. G od will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a ma n to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was h oeing in a village garden, and I felt that I was more distinguished by t hat circumstance that I should have been by any epaulet I could have wor n. -Thoreau === --- On Fri, 8/13/10, Bill Atkins watk...@alum.rpi.edu wrote: From: Bill Atkins watk...@alum.rpi.edu Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Friday, August 13, 2010, 11:13 PM Not sure if I understood what you're trying to do, but development will be easier if you minimize your IO, e.g. : maxLineLength :: Int maxLineLength = 72 wrapLine :: String - [String] wrapLine = [] wrapLine line | length line = maxLineLength= [line] | otherwise= take maxLineLength line : wrapLine (drop maxLineLength line) main :: IO () main = interact $ unlines . concatMap wrapLine . lines Now wrapLine is pure and you can use it more easily using GHCi. Removing dependencies on IO usually makes your problem easier to test and understand and your code simpler. In your example, the EOF probably happens on the call to getLine after input has run out. By using Prelude.interact, we can ignore details like that and rely on already-written functions. HTH, Bill On Friday Aug 13, 2010, at 9:38 PM, michael rice wrote: The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? Michael == unwrap.hs == main = do line -
Re: [Haskell-cafe] Re: philosophy of Haskell
On Saturday Aug 14, 2010, at 12:50 AM, Conal Elliott wrote: And the IO monad is what Jerzy asked about. I'm pointing out that the state monad does not capture concurrency, and the EDSL model does not capture FFI. (Really, it depends which EDSL model. I haven't seen one that can capture FFI. And maybe not concurrency either.) So which model captures the way the IO monad works? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
On Sat, Aug 14, 2010 at 9:59 AM, Bill Atkins watk...@alum.rpi.edu wrote: | otherwise = let (line, rest) = splitAt maxLineLength line in line : wrapLine rest I haven't tested myself, but does this work at all? If I am reading it correctly, this is the same as let (foo, rest) = splitAt maxLineLength foo in foo : wrapLine rest In other words, no mention of wrapLine's argument 'line', and a recursive call that will bottom out and be the same as 'undefined' :). GHC would warn you, though, if you used -Wall. That expression should read: let (thisLine, rest) = splitAt maxLineLength line in thisLine : wrapLine rest Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Oof, that's what I get for making just one little change without testing. You're right. On Saturday Aug 14, 2010, at 9:17 AM, Felipe Lessa wrote: On Sat, Aug 14, 2010 at 9:59 AM, Bill Atkins watk...@alum.rpi.edu wrote: | otherwise= let (line, rest) = splitAt maxLineLength line in line : wrapLine rest I haven't tested myself, but does this work at all? If I am reading it correctly, this is the same as let (foo, rest) = splitAt maxLineLength foo in foo : wrapLine rest In other words, no mention of wrapLine's argument 'line', and a recursive call that will bottom out and be the same as 'undefined' :). GHC would warn you, though, if you used -Wall. That expression should read: let (thisLine, rest) = splitAt maxLineLength line in thisLine : wrapLine rest Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Hi Filipe, Bill Your corrected version works, while the original didn't, but it still produces incorrect output: However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not t rouble yourself much to get new things, whether clothes or friends. Thin gs do not change, we change. Sell your clothes and keep your thoughts. G od will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a ma n to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was h oeing in a village garden, and I felt that I was more distinguished by t hat circumstance that I should have been by any epaulet I could have wor n. -Thoreau I don't want to break lines in the middle of words and I want to retain the original structure of the text with respect to blank lines between individual quotes. THe only thing in the input text that should change are the lines longer than 72 characters, and they should be reformatted to one or more lines less than or equal to 72 characters. Michael --- On Sat, 8/14/10, Felipe Lessa felipe.le...@gmail.com wrote: From: Felipe Lessa felipe.le...@gmail.com Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: Bill Atkins watk...@alum.rpi.edu Cc: michael rice nowg...@yahoo.com, haskell-cafe@haskell.org Date: Saturday, August 14, 2010, 9:17 AM On Sat, Aug 14, 2010 at 9:59 AM, Bill Atkins watk...@alum.rpi.edu wrote: | otherwise = let (line, rest) = splitAt maxLineLength line in line : wrapLine rest I haven't tested myself, but does this work at all? If I am reading it correctly, this is the same as let (foo, rest) = splitAt maxLineLength foo in foo : wrapLine rest In other words, no mention of wrapLine's argument 'line', and a recursive call that will bottom out and be the same as 'undefined' :). GHC would warn you, though, if you used -Wall. That expression should read: let (thisLine, rest) = splitAt maxLineLength line in thisLine : wrapLine rest Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: gtk2hs with old gtk2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/10 02:20 , Andy Stewart wrote: Cannot find a definition for `Emblem' in the header file. Because GEmblem is need Glib 2.18, mabye your glib is too old. You can use command 'pkg-config --modversion glib-2.0' check your glib version. Can you update your glib library? I ran up against this here; I can't mandate that our older SuSE systems be upgraded to a newer distribution (our faculty don't like change, in general), so if 2.18 is really needed then it's pretty much the end of the line for gtk2hs as far as we're concerned. :( - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxmnswACgkQIn7hlCsL25VoswCg1JTNHlfiWcSnY3ZU4IdfZX19 AtAAn1zt0z9a+KmeD47ByXxM62PQqI4T =c4qG -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
Andrew Coppin wrote: Ivan Lazar Miljenovic wrote: If so, how does this not solve the issue? , | class NextOneUpAT v where | type Next v | ... | | instance NextOneUpAT Vector3 where | type Next Vector3 = Vector4 | ... ` Can I use that to go both up and down? Would the types be unambiguous? I guess I'll have to go try it out... Actually, this seems to work just fine as-is. (Famous last words...) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/10 01:29 , Kevin Jardine wrote: I think that this kind of programming detail should be handled internally (even if necessary by switching automatically from UTF-8 to UTF-16 depending upon the language). This is going to carry a heavy speed penalty. I'm using Haskell so that I can write high level code. In my view I should not have to care if the people using my application write in Farsi, Quechua or Tamil. Ideally yes, but arguably the existing Unicode representations don't allow this to be done nicely. (Of course, arguably there is no nice way to do it; UTF-16 is the best you can do as a workable generic setting.) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxmqaEACgkQIn7hlCsL25WmOQCfYEjkem99o5IpwxnD7bNaDYyG 768AoK17I605DqDxIdnFUE7MK2ktMtrN =lOPK -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Question about memory usage
I was reading this article: http://scienceblogs.com/goodmath/2009/11/writing_basic_functions_in_has.php And came to the part where it shows: fiblist = 0 : 1 : (zipWith (+) fiblist (tail fiblist)) Very interesting stuff for somebody who comes from an imperative world of course. But then I read that Once it's been referenced, then the list up to where you looked is concrete - the computations *won't* be repeated. and I started wondering how that works. Because this seems to mean that functions could have unknown (to the caller) memory requirements. How does one, programming in Haskell, keep that in check? And when does that memory get reclaimed? Cheers, -Tako ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about memory usage
Tako Schotanus wrote: fiblist = 0 : 1 : (zipWith (+) fiblist (tail fiblist)) Very interesting stuff for somebody who comes from an imperative world of course. Oh yes, that old chestnut. There's a page on the wiki somewhere with a whole collection of these cryptic one-liners - Pascal's triangle, the prime numbers, the Fibonacci numbers, etc. But then I read that Once it's been referenced, then the list up to where you looked is concrete - the computations /won't/ be repeated. and I started wondering how that works. fiblist is a global variable. It points to a list calculation expression. When a list cell is calculated, the calculation node is overwritten with the result of the calculation. When you access the list, you look at each cell; if it's already done, you just use it. If it's not done, execute it and then use it. (How it actually works below that is a problem for the runtime engine to figure out, and varies by Haskell implementation. For example, GHC uses the spineless tagless G-machine.) Because this seems to mean that functions could have unknown (to the caller) memory requirements. Yes. How does one, programming in Haskell, keep that in check? ...and here begins an entire textbook that nobody has published yet. And when does that memory get reclaimed? It's called garbage collection. The memory is reclaimed when it becomes unreachable becuase there are no pointers to it left. In the example above, fiblist is a global variable, so the answer to when does it get freed? would be never. (I believe it's called a CAF leak.) Whether this is very cool or a major performance issue depends on your point of view; you're trading space for time. (Then again, the Fibonacci numbers can be computed in O(1) time, and nobody ever needs Fibonacci numbers in the first place, so this is obviously example code.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about memory usage
On Sat, 14 Aug 2010, Tako Schotanus wrote: I was reading this article: http://scienceblogs.com/goodmath/2009/11/writing_basic_functions_in_has.php And came to the part where it shows: fiblist = 0 : 1 : (zipWith (+) fiblist (tail fiblist)) But then I read that Once it's been referenced, then the list up to where you looked is concrete - the computations won't be repeated. It is so implemented. If you *really* wanted a weak reference that could be garbage collected and rebuilt (you don't), it could be made to happen. and I started wondering how that works. Because this seems to mean that functions could have unknown (to the caller) memory requirements. This is true in any programming language or runtime. Nothing special has happened: you could implement the same thing in C/C++/Java/Python, but it would take 10-100 lines of code. How does one, programming in Haskell, keep that in check? And when does that memory get reclaimed? Haskell is garbage collected, as soon as the fiblist is not longer reachable, and the runtime wants to reclaim the memory, it will. If fiblist is a top-level declaration it will always be reachable. Friendly! --Lane ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Quoth Brandon S Allbery KF8NH allb...@ece.cmu.edu, -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/10 01:29 , Kevin Jardine wrote: I think that this kind of programming detail should be handled internally (even if necessary by switching automatically from UTF-8 to UTF-16 depending upon the language). It seems like the right thing, described in the wrong words - wouldn't it be a more sensible ideal, to simply `switch' depending on the character encoding? I mean, to start with, you'd surely wish for some standardization, so that the difference between UTF-8 and UTF-16 is essentially internal, while you use the same API indifferently. Second, a key requirement to effectively work with external data is support for multiple character encodings. E.g., if Text is internally UTF-16, it still must be able to input and output UTF-8, and presumably also UTF-16 where appropriate. So given full support for _both_ encodings (for example, Text implementation for `native' UTF-8), and support for input data of _either_ encoding as encountered at run time ... then the internal implementation choice should simply follow the external data. For Chinese inputs you'd be running UTF-16 functions, for French UTF-8. Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
What's wrong with fun-deps? The associated type synonym syntax is prettier, but I didn't tknow that fun-deps were evil. Do you have any links? Take care, Antoine On Aug 14, 2010 5:19 AM, Andrew Coppin andrewcop...@btinternet.com wrote: As I understand it, ATs were invented because FDs are evil and must never be used ever for any purpose. However, it doesn't seem to be possible to use ATs to do the same things that FDs can do. You can use ATs to write type functions, which take one type and return another type. This allows you to express type relationships in a very elegant way. However, what it does /not/ seem to allow you to do is express one-to-one relationships. For example, I'd like to be able to say that the next vector up from a Vector3 is a Vector4, and the next vector down is a Vector2. And I can say that. What I can't say is that the *only* next vector up is a Vector4. And thus, all my code is littered with ambiguous type warnings because although /currently/ there's only one class instance, somebody could come along some day and write another one. What am I missing? ___ 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] ATs vs FDs
I think that was exaggeration for effect. FDs aren't evil, but TFs do the same thing in a nicer way, and there's a long-term effort to move over from one to the other, and ideally get TFs into Haskell' at some point. But there's no problem with using FDs if you need them or just like them better. (Obviously as long as TFs aren't fully implemented you can't use them for everything). (All of this is AFAIK, etc.) On Sat, Aug 14, 2010 at 6:01 PM, Antoine Latter aslat...@gmail.com wrote: What's wrong with fun-deps? The associated type synonym syntax is prettier, but I didn't tknow that fun-deps were evil. Do you have any links? Take care, Antoine On Aug 14, 2010 5:19 AM, Andrew Coppin andrewcop...@btinternet.com wrote: As I understand it, ATs were invented because FDs are evil and must never be used ever for any purpose. However, it doesn't seem to be possible to use ATs to do the same things that FDs can do. You can use ATs to write type functions, which take one type and return another type. This allows you to express type relationships in a very elegant way. However, what it does /not/ seem to allow you to do is express one-to-one relationships. For example, I'd like to be able to say that the next vector up from a Vector3 is a Vector4, and the next vector down is a Vector2. And I can say that. What I can't say is that the *only* next vector up is a Vector4. And thus, all my code is littered with ambiguous type warnings because although /currently/ there's only one class instance, somebody could come along some day and write another one. What am I missing? ___ 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 -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Try this one (http://gist.github.com/524460): import Data.Char maxLineLength :: Int maxLineLength = 72 trim :: String - String trim = reverse . dropSpaces . reverse . dropSpaces where dropSpaces = dropWhile isSpace none :: (a - Bool) - [a] - Bool none f = not . any f reverseBreak :: (a - Bool) - [a] - ([a], [a]) reverseBreak f xs = (reverse before, reverse after) where (after, before) = break f $ reverse xs wrapLine :: String - [String] wrapLine = [[]] wrapLine line | length line = maxLineLength= [line] | none isSpace line = beforeMax : wrapLine afterMax | otherwise = beforeSpace : (wrapLine $ afterSpace ++ afterMax) where (beforeMax, afterMax)= splitAt maxLineLength line (beforeSpace, afterSpace) = reverseBreak isSpace beforeMax main :: IO () main = interact $ unlines . concatMap (map trim . wrapLine) . lines On Saturday Aug 14, 2010, at 9:41 AM, michael rice wrote: Hi Filipe, Bill Your corrected version works, while the original didn't, but it still produces incorrect output: However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not t rouble yourself much to get new things, whether clothes or friends. Thin gs do not change, we change. Sell your clothes and keep your thoughts. G od will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a ma n to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was h oeing in a village garden, and I felt that I was more distinguished by t hat circumstance that I should have been by any epaulet I could have wor n. -Thoreau I don't want to break lines in the middle of words and I want to retain the original structure of the text with respect to blank lines between individual quotes. THe only thing in the input text that should change are the lines longer than 72 characters, and they should be reformatted to one or more lines less than or equal to 72 characters. Michael --- On Sat, 8/14/10, Felipe Lessa felipe.le...@gmail.com wrote: From: Felipe Lessa felipe.le...@gmail.com Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: Bill Atkins watk...@alum.rpi.edu Cc: michael rice nowg...@yahoo.com, haskell-cafe@haskell.org Date: Saturday, August 14, 2010, 9:17 AM On Sat, Aug 14, 2010 at 9:59 AM, Bill Atkins watk...@alum.rpi.edu wrote: | otherwise= let (line, rest) = splitAt maxLineLength line in line : wrapLine rest I haven't tested myself, but does this work at all? If I am reading it correctly, this is the same as let (foo, rest) = splitAt maxLineLength foo in foo : wrapLine rest In other words, no mention of wrapLine's argument 'line', and a recursive call that will bottom out and be the same as 'undefined' :). GHC would warn you, though, if you used -Wall. That expression should read: let (thisLine, rest) = splitAt maxLineLength line in thisLine : wrapLine rest Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
On Sat, Aug 14, 2010 at 12:33 PM, Bill Atkins watk...@alum.rpi.edu wrote: Try this one (http://gist.github.com/524460) I noticed that Bill's solution doesn't seem to work if the input text is infinite. I found a different solution, which avoids the use of reverse, and will work even if the input is infinite, as long as the words themselves are finite in length. (http://hpaste.org/fastcgi/hpaste.fcgi/view?id=29048) module Main where import Data.List combineNonEmpty :: (t - Bool) - t - ([t] - t) - [t] - [t] combineNonEmpty isNull zero cat [] = [] combineNonEmpty isNull zero cat xs = let (ys, zs) = break isNull xs rest = if null zs then [] else zero : combineNonEmpty isNull zero cat (tail zs) in if null ys then rest else cat ys : rest textToParagraphs :: String - [String] textToParagraphs = combineNonEmpty null [] (concat . intersperse' ) . lines intersperse' :: a - [a] - [a] intersperse' a [] = [] intersperse' a (x:xs) = x : (if null xs then [] else a : intersperse' a xs) wordWrap :: Int - [String] - [[String]] wordWrap maxLineLength [] = [] wordWrap maxLineLength ws = let lengths = scanl1 (\a b - a + b + 1) $ map length ws wordCount = length $ takeWhile (= maxLineLength) lengths wordCount' = if wordCount = 1 then wordCount else 1 (xs, rest) = splitAt wordCount' ws in xs : wordWrap maxLineLength rest wrapParagraph :: Int - String - [String] wrapParagraph maxLineLength str = let ws = words str in if null ws then [] else map unwords $ wordWrap maxLineLength ws wrapText :: Int - String - String wrapText maxLineLength = unlines . concat . map (wrapParagraph maxLineLength) . textToParagraphs main :: IO () main = interact (wrapText 72) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Hi Bill, Very clever. You are an inspiration. Michael --- On Sat, 8/14/10, Bill Atkins watk...@alum.rpi.edu wrote: From: Bill Atkins watk...@alum.rpi.edu Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: michael rice nowg...@yahoo.com Cc: Felipe Lessa felipe.le...@gmail.com, haskell-cafe@haskell.org Date: Saturday, August 14, 2010, 12:33 PM Try this one (http://gist.github.com/524460): import Data.Char maxLineLength :: Int maxLineLength = 72 trim :: String - String trim = reverse . dropSpaces . reverse . dropSpaces where dropSpaces = dropWhile isSpace none :: (a - Bool) - [a] - Bool none f = not . any f reverseBreak :: (a - Bool) - [a] - ([a], [a]) reverseBreak f xs = (reverse before, reverse after) where (after, before) = break f $ reverse xs wrapLine :: String - [String] wrapLine = [[]] wrapLine line | length line = maxLineLength = [line] | none isSpace line = beforeMax : wrapLine afterMax | otherwise = beforeSpace : (wrapLine $ afterSpace ++ afterMax) where (beforeMax, afterMax) = splitAt maxLineLength line (beforeSpace, afterSpace) = reverseBreak isSpace beforeMax main :: IO () main = interact $ unlines . concatMap (map trim . wrapLine) . lines On Saturday Aug 14, 2010, at 9:41 AM, michael rice wrote: Hi Filipe, Bill Your corrected version works, while the original didn't, but it still produces incorrect output: However mean your life is, meet it and live it: do not shun it and call it hard names. Cultivate poverty like a garden herb, like sage. Do not t rouble yourself much to get new things, whether clothes or friends. Thin gs do not change, we change. Sell your clothes and keep your thoughts. G od will see that you do want society. Men have become the tools of their tools. I know of no more encouraging fact than the unquestioned ability of a ma n to elevate his life by conscious endeavor. I once had a sparrow alight upon my shoulder for a moment, while I was h oeing in a village garden, and I felt that I was more distinguished by t hat circumstance that I should have been by any epaulet I could have wor n. -Thoreau I don't want to break lines in the middle of words and I want to retain the original structure of the text with respect to blank lines between individual quotes. THe only thing in the input text that should change are the lines longer than 72 characters, and they should be reformatted to one or more lines less than or equal to 72 characters. Michael --- On Sat, 8/14/10, Felipe Lessa felipe.le...@gmail.com wrote: From: Felipe Lessa felipe.le...@gmail.com Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: Bill Atkins watk...@alum.rpi.edu Cc: michael rice nowg...@yahoo.com, haskell-cafe@haskell.org Date: Saturday, August 14, 2010, 9:17 AM On Sat, Aug 14, 2010 at 9:59 AM, Bill Atkins watk...@alum.rpi.edu wrote: | otherwise = let (line, rest) = splitAt maxLineLength line in line : wrapLine rest I haven't tested myself, but does this work at all? If I am reading it correctly, this is the same as let (foo, rest) = splitAt maxLineLength foo in foo : wrapLine rest In other words, no mention of wrapLine's argument 'line', and a recursive call that will bottom out and be the same as 'undefined' :). GHC would warn you, though, if you used -Wall. That expression should read: let (thisLine, rest) = splitAt maxLineLength line in thisLine : wrapLine rest Cheers, -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ATs vs FDs
On Aug 14, 2010, at 9:01 AM, Antoine Latter wrote: What's wrong with fun-deps? The associated type synonym syntax is prettier, but I didn't tknow that fun-deps were evil. Do you have any links? They're not evil, they are tricky and can lead to non-termination, inconsistency, etc. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.118.6217rep=rep1type=pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about memory usage
In the example above, fiblist is a global variable, so the answer to when does it get freed? would be never. (I believe it's called a CAF leak.) Is that actually true? I've heard lots of references to this, but I'm not sure it is true. Sure, it's harder for it to get collected when everyone can potentially access it, but the mechanisms for checking who holds pointers to a value are still valid for CAFS, and collection can still work on them, I think. The commentary at http://is.gd/ehEuL seems to suggest that CAFs can be garbage collected, too. My apologies for confusing the issue, if this is not correct, though! Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
andrewcoppin: Interesting. I've never even heard of Data.Text. When did that come into existence? More importantly: How does the average random Haskeller discover that a package has become available that might be relevant to their work? In this case, Data.Text has been announced on this very list several times: Text 0.7 announcement http://www.haskell.org/pipermail/haskell-cafe/2009-December/070866.html Text 0.5 announcement http://www.haskell.org/pipermail/haskell-cafe/2009-October/067517.html Text 0.2 announcement http://www.haskell.org/pipermail/haskell-cafe/2009-May/061800.html Text 0.1 annoucnement http://www.haskell.org/pipermail/haskell-cafe/2009-February/056723.html As well as on Planet Haskell several times: Finally! Fast Unicode support for Haskell http://www.serpentine.com/blog/2009/02/27/finally-fast-unicode-support-for-haskell/ Streaming Unicode support for Haskell: text 0.2 http://www.serpentine.com/blog/2009/05/22/streaming-unicode-support-for-haskell-text-02/ Case conversion and text 0.3 http://www.serpentine.com/blog/2009/06/07/case-conversion-and-text-03/ As well as being presented at Anglo Haskell http://www.wellquite.org/non-blog/AngloHaskell2008/tom%20harper.pdf It is mentioned repeatedly in the quarterly Hackage status posts: vector and text are quickly rising as the preferred arrays and unicode libraries http://donsbot.wordpress.com/2010/04/03/the-haskell-platform-q1-2010-report/ text has made it into the top 30 libraries http://donsbot.wordpress.com/2010/06/30/popular-haskell-packages-q2-2010-report/ Ranked 31st most popular package by June 2010. http://code.haskell.org/~dons/hackage/Jun-2010/popular.txt Ranked 41st most popular package by April 2010. http://www.galois.com/~dons/hackage/april-2010/popularity.csv Ranked 345th by August 2009 http://www.galois.com/~dons/hackage/august-2009/popularity-august-2009.html And discussed on Reddit Haskell many times: http://www.reddit.com/r/haskell/comments/8qfvw/doing_unicode_case_conversion_and_error_recovery/ http://www.reddit.com/r/haskell/comments/80smp/datatext_fast_unicode_bytestrings_with_stream/ http://www.reddit.com/r/haskell/comments/80smp/datatext_fast_unicode_bytestrings_with_stream/ http://www.reddit.com/r/haskell/comments/ade08/the_performance_of_datatext/ So, to stay up to date, but without drowning in data. Do one of: * Pay attention to Haskell Cafe announcements * Follow the Reddit Haskell news. * Read the quarterly reports on Hackage * Follow Planet Haskell -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing polymorphism from type classes (viz. Functor) (Again)
On Sat, Aug 14, 2010 at 2:27 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: Alexey Karakulov ankaraku...@gmail.com writes: (Ord b) must be deduced from (Functor (Set b)) but it doesn't. I don't know whether it's my mistake somewhere or ghc problem. I've come across this problem as well; the best solution I've seen so far is the one taken by Ganesh in his rmonad library: http://hackage.haskell.org/package/rmonad -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com Thanks for the link, but RFunctor typeclass is still (more or less) polymorphic, so I couldn't write ByteString instance for it. (Really I don't care about ByteString, but it's good example). However, I could try to use Suitable+Constraints concept for non-polymorphic functors. -- All the best, Alexey ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Fri, Aug 13, 2010 at 10:43 AM, Johan Tibell johan.tib...@gmail.com wrote: Here's a rule of thumb: If you have binary data, use Data.ByteString. If you have text, use Data.Text. Those libraries have benchmarks and have been well tuned by experienced Haskelleres and should be the fastest and most memory compact in most cases. There are still a few cases where String beats Text but they are being worked on as we speak. It's a good rule, but I don't know how helpful it is to someone doing XML processing. From what I can tell, the only XML library that uses Data.Text is libxml-sax, although tagsoup can probably be easily extended to use it. HXT, HaXml, and xml all use [Char] internally. -- Dave Menendez d...@zednenem.com http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing polymorphism from type classes (viz. Functor) (Again)
The non-type-changing map can be implemented as a type class - in my graphics lib Wumpus, I call it pointwise: class Pointwise sh where type Pt sh :: * pointwise :: (Pt sh - Pt sh) - sh - sh I think other people have posted it to the cafe under a different name, before I did: http://www.haskell.org/pipermail/haskell-cafe/2010-July/079784.html If I was doing Wumpus again though, I'd probably do with Pointwise. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Removing polymorphism from type classes (viz. Functor) (Again)
On 14 August 2010 20:27, Stephen Tetley stephen.tet...@gmail.com wrote: If I was doing Wumpus again though, I'd probably do with Pointwise. Ahem, do without Pointwise Originally the types I operated on with Pointwise were more complicated than they are now and Pointwise seemed a benefit. But as I got a better understanding of the domain I was working in, I could simply my types; after doing this Pointwise has become rather superfluous. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Question about memory usage
First of all, thanks to the people who responded :) On Sat, Aug 14, 2010 at 17:49, Christopher Lane Hinson l...@downstairspeople.org wrote: On Sat, 14 Aug 2010, Tako Schotanus wrote: I was reading this article: http://scienceblogs.com/goodmath/2009/11/writing_basic_functions_in_has.php And came to the part where it shows: fiblist = 0 : 1 : (zipWith (+) fiblist (tail fiblist)) But then I read that Once it's been referenced, then the list up to where you looked is concrete - the computations won't be repeated. It is so implemented. If you *really* wanted a weak reference that could be garbage collected and rebuilt (you don't), it could be made to happen. I understand, if you don't want to keep the memory tied up you either define the reference locally or you use another algorithm. and I started wondering how that works. Because this seems to mean that functions could have unknown (to the caller) memory requirements. This is true in any programming language or runtime. Nothing special has happened: you could implement the same thing in C/C++/Java/Python, but it would take 10-100 lines of code. Sure, although the memory use would normally be more obvious and it would actually be more work to make the result globally permanent. (the difference between the 10 lines and the 100 lines you refer to probably) How does one, programming in Haskell, keep that in check? And when does that memory get reclaimed? Haskell is garbage collected, as soon as the fiblist is not longer reachable, and the runtime wants to reclaim the memory, it will. If fiblist is a top-level declaration it will always be reachable. Ok, makes sense. Just to make this clear, I'm not complaining nor suggesting there is anything wrong with the way Haskell does things (minds immeasurably superior to mine working on this stuff, I'm not going to pretend to know better), it's just one of those surprises for somebody who has no experience yet with Haskell. Thanks, -Tako ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
On 14/08/10 02:30, Lennart Augustsson wrote: So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened. The handle is in fact not reachable from the roots, because the thread that points to it is also not reachable. More about it in this ticket: http://hackage.haskell.org/trac/ghc/ticket/2161 Some rationale from that ticket: You may argue that a reference from a thread, even an unreachable one, should keep a ForeignPtr alive. But it's equally valid to argue the reverse: a reference from a finalizer should keep a thread alive - you don't want a thread to be considered deadlocked if it can be unblocked by a finalizer. We can't have both, because then a cycle between a finalizer and a thread would never be collected even when both were unreachable. So while we can flip this decision, it would have other undesirable consequences. I suppose I don't really have a good handle on how often you want one behaviour vs. the other - feedback welcome. Either way the GC has to do two extra phases after tracing from the roots: trace from the finalizers and then the unreachable threads, or vice versa. Cheers, Simon On Fri, Aug 13, 2010 at 10:53 AM, Simon Marlowmarlo...@gmail.com wrote: On 12/08/2010 21:59, Yitzchak Gale wrote: Wei Hu wrote: nonTermination _ = blackhole where blackhole = blackhole My original example was actually: process :: String -String process = let x = x in x Ah yes, that works too. But other similar versions don't, like this one: process :: String -String process _ = let x = x in x Hence why I added the tail in my version. So what happens is this: - the recursive definition causes the main thread to block on itself (known as a black hole) - the program is deadlocked (no threads to run), so the runtime invokes the GC to see if any threads are unreachable - the GC finds that (a) the main thread is unreachable and blocked on a blackhole, so it gets a NonTermination exception (b) the Handle is unreachable, so its finalizer is started - the finalizer runs first, and closes the Handle - the main thread runs next, and the exception handler for writeFile tries to close the Handle, which has already been finalized Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. Cheers, Simon ___ 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] Re: A GHC error message puzzle
On 13/08/10 17:00, Tillmann Rendel wrote: Simon Marlow wrote: Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. That sounds like a work-around to me, not a fix, because it would not fix more complicated exception handlers. I don't think there's a problem with more complicated exception handlers. The fix is to make the finalized Handle look like a closed Handle; it's a fix to the finalizer, not the exception handler, so it's not a workaround for this one particular symptom. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is bumping the version number evil, if it's not mandated by the PVP?
Sebastian Fischer wrote: Hello, I wonder whether (and how) I should increase the version number of a library when the API does not change but the implementation gets more efficient. I think it depends on how much more efficient. Constant factors of improvement are always nice, but they aren't (usually) earth shattering and so are probably only worth a D bump. Asymptotic improvements may very well be worth a C or B bump--- especially if they introduce the possibility of new bugs due to large code changes (i.e., you haven't _proven_ bug-for-bug compatibility). But it also depends on the audience. For example, some libraries are defined as being an efficient implementation of Foo rather than being, say, an implementation of a particular data type or a particular high-level API for writing nice code. If your library is _defined_ by its performance characteristics, then a C or B bump would be appropriate since the complexity is effectively part of the API even though it isn't captured in the type system. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: Darcs hacking sprint (15-17 Oct, Orleans)
Hello Haskellers! The Darcs Team will soon be hosting its fifth hacking sprint this October. We would be delighted if you could join us. http://wiki.darcs.net/Sprints/2010-10 Details --- When: 15-17 October 2010 Where: Orleans, France WhoAnybody who wants to hack on Darcs (or Camp, Focal, etc) Beginners especially welcome! Why: Darcs aims to have bi-annual hacking sprints so that we can get together on a regular basis, hold design discussions, hack up a storm and have a lot fun. What: We'll be starting work on the next release after the upcoming Darcs 2.5. Could we see a much fast darcs over networks? Friendlier darcs annotate? Exciting times ahead... We intend to set aside at least one Darcs hacker for mentoring beginners, so if you're new to Haskell or to Darcs hacking, here's a good chance to plunge in and start working on a real world project. How: Email me ko...@darcs.net to let me know you're interested! Keep in mind that we do have funds to help pay for travel expenses; just let me know if you'd like to come :-) Thanks -- Thanks to team Florent Becker and University of Orleans for generously offering to host this event! Thanks also to donors from the fundraising drive this year. We'll be using that money to help Darcs hackers get to Orleans Supporting Darcs Darcs is a very happy member of the Software Freedom Conservancy. Among other things, the Software Freedom Conservancy makes it easy for open source projects to raise funds and hold assets (as part of a legal entity). For more information on supporting Darcs, see http://darcs.net/donations.html See you there! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, please try +44 (0)1273 64 2905. pgpUc8l7r1aOe.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Slightly humorous: Headhunters toolbox (example for Germany)
Hi list, stumbled across that: http://www.google.com/insights/search/?hl=de#q=haskellgeo=DEcmpt=q Greetz Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
Lennart Augustsson wrote: So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened. Simon Marlow wrote: The handle is in fact not reachable from the roots, because the thread that points to it is also not reachable. I think I agree with Lennart here. A thread with an active exception handler is not permanently unreachable, only temporarily unreachable, unless we know that it is impossible for any exception to be thrown at it that it is capable of catching. In this case, the handler can catch a NonTermination, so it is not unreachable. A keyboard interrupt is another possibility. If we know that things are really stuck it could still be helpful for us to throw the NonTermination, but that doesn't mean that the handle should be considered unreachable at the time. It is very important to do the best we can to allow people's exception handlers to run successfully, especially in a bracket. That is a much higher priority than protecting people from hanging their app when they write poor exception handlers. By finalizing the handle, you are significantly lowering the chance of exception handlers being able to do a proper job. I do agree, though, that hClose should be less finicky about finalized handles, which would solve the problem in this particular case. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Sean Leather wrote: Which one do you use for strings in HTML or XML in which UTF-8 has become the commonly accepted standard encoding? UTF-8 is only becoming the standard for non-CJK languages. We are told by members of our community in CJK countries that UTF-8 is not widely adopted there, and there is no sign that it ever will be. And one should be aware that the proportion of CJK in global Internet traffic is growing quickly. But of course, that is still a legitimate question for some situations in which full internationalization will not be needed. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
Simon Marlow wrote: Really hClose shouldn't complain about a finalized handle, I'll see if I can fix that. That sounds like a work-around to me, not a fix, because it would not fix more complicated exception handlers. I don't think there's a problem with more complicated exception handlers. The fix is to make the finalized Handle look like a closed Handle; it's a fix to the finalizer, not the exception handler, so it's not a workaround for this one particular symptom. Given the documentation of bracket, I would expect the following to write to the file. main = bracket (openFile output WriteMode) (\handle - do hPutStr handle I want this to be written in any case hClose handle) blackhole blackhole = blackhole But currently, hPutStr complains about a finalized handle, and with your fix, it would complain about a closed handle, which is hardly better. Tillmann ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Yitzchak Gale wrote: Sean Leather wrote: Which one do you use for strings in HTML or XML in which UTF-8 has become the commonly accepted standard encoding? UTF-8 is only becoming the standard for non-CJK languages. We are told by members of our community in CJK countries that UTF-8 is not widely adopted there, and there is no sign that it ever will be. And one should be aware that the proportion of CJK in global Internet traffic is growing quickly. So then, what is the standard? Being not familiar with this area, I googled a bit, and I don't see a consensus. But I also noticeably don't see UTF-16. So, if this is the case, then a similar question still arises for CJK text: What format/library to use for it (assuming one doesn't want a performance penalty for translating between Data.Text's internal format and the target format)? It appears that there are no ideal answers to such questions. Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
On Sat, Aug 14, 2010 at 2:38 AM, michael rice nowg...@yahoo.com wrote: The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? Michael While many other people have shown you why you need not necessarily answer this question, I think it'd be helpful for you to hear the answer anyway. Your message is being produced because you are trying to getLine when there is no input left. This raises an exception, which, because it is not handled by your program, prints a diagnostic message and exits. Strangely, it prints this before the output of your program - this isn't terribly important, but for the sake of completeness, it's because of the different buffering characteristics of stdout and stderr, which confusingly mean that even though your program produces output and then produces an error, the error is printed immediately while the output waits until the program is terminated to be produced. I think. Something like that, anyway. So, how do you avoid the exception? You can use System.IO.isEOF [1] to check if there is input available on the standard input handle: main = do eof - isEOF when (not eof) realMain -- when from Control.Monad, see also: unless where realMain = do realStuff Or you can let getLine throw the exception, but catch it and deal with it yourself, rather than letting it kill your program. Catching it is a little less simple, but is considerably more flexible and powerful. The exceptions situation in Haskell is somewhat complicated by the fact that the mechanism used by haskell98 has been improved upon, but the new extensible mechanism is incompatible with the old so both have to hang around. Have a look at Control.Exception [2] and System.IO.Error [3]. In either case you have 'catch' as a sort of basic operation, and more convenient things like 'try' which sort of turn an exception into a pure Either result. I'd do something like this: main = do result - try getLine case result of Left err - return () -- or do something diagnostic Right - putStrLn main Right line - doStuffWith line On a more general note, your main function looks a little suspect because it *always* recurses into itself - there's no termination condition. A question nearly as important as how does my program know what to do is how does it know when to stop :) [1] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/System-IO.html#v%3AisEOF [2] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/Control-Exception.html [3] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/System-IO-Error.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/10 19:07 , Ben Millwood wrote: Strangely, it prints this before the output of your program - this isn't terribly important, but for the sake of completeness, it's because of the different buffering characteristics of stdout and stderr, which confusingly mean that even though your program produces output and then produces an error, the error is printed immediately while the output waits until the program is terminated to be produced. I think. Something like that, anyway. My guess is he's redirecting stdout and stderr to the same file, and stderr happens to get flushed by the Haskell runtime before stdout (possibly because a flush is performed regardless when an exception is printed). It is, as you note, not really relevant to the actual logic error leading to the exception. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxnJBUACgkQIn7hlCsL25X7jACgzk4uCCP/1LBDfgtRU0vfobZI +BgAn2oabimC8tKOII6xBC+LM41oTpqd =q1sj -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Sean Leather wrote: So then, what is the standard? ...I also noticeably don't see UTF-16. Right there are a handful of language-specific 16-bit encodings that are popular, from what I understand. So, if this is the case, then a similar question still arises for CJK text: What format/library to use for it (assuming one doesn't want a performance penalty for translating between Data.Text's internal format and the target format)? It appears that there are no ideal answers to such questions. Right. If you know you'll be in a specific encoding - whether UTF-8, Latin1, one of the CJK encodings, or whatever, it might sometimes make sense to skip Data.Text and do the IO as raw bytes using ByteString and then encode/decode manually only when needed. Otherwise, Data.Text is probably the way to go. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 3:46 PM, Sean Leather leat...@cs.uu.nl wrote: So then, what is the standard? There isn't one. There are many national standards: - China: GB-2312, GBK and GB18030 - Taiwan: Big5 - Japan: JIS and Shift-JIS (0208 and 0213 variants) and EUC-JP - Korea: KS-X-2001, EUC-KR, and ISO-2022-KR In general, Unicode uptake is increasing rapidly: http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html Being not familiar with this area, I googled a bit, and I don't see a consensus. But I also noticeably don't see UTF-16. So, if this is the case, then a similar question still arises for CJK text: What format/library to use for it (assuming one doesn't want a performance penalty for translating between Data.Text's internal format and the target format)? In my opinion, this performance penalty hand-wringing is mostly silly. We're talking a pretty small factor of performance difference in most of these cases. Even the biggest difference, between ByteString and String, is usually much less than a factor of 100. Your absolute first concern should be correctness, for which you should (a) use text and (b) assume that any performance issues are being actively worked on, especially if you report concrete problems and how to reproduce them. In the unlikely event that you need to support non-Unicode encodings, they are readily available via text-icu. The only significant change to the text API that lies ahead is an introduction of locale support in a few critical places, so that we can do the right thing for languages like Turkish. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Thanks for the caveats. I originally tried to write some pure functions to break up the long strings into ones of acceptable length, to no avail. The solution I submitted was a frustrated attempt to solve the problem *somehow* so I'd have something that worked to refer to. I can see the benefit of separating IO from pure and will approach similar problems from that standpoint in the future. Michael --- On Sat, 8/14/10, Ben Millwood hask...@benmachine.co.uk wrote: From: Ben Millwood hask...@benmachine.co.uk Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: michael rice nowg...@yahoo.com Cc: haskell-cafe@haskell.org Date: Saturday, August 14, 2010, 7:07 PM On Sat, Aug 14, 2010 at 2:38 AM, michael rice nowg...@yahoo.com wrote: The program below takes a text file and unwraps all lines to 72 columns, but I'm getting an end of file message at the top of my output. How do I lose the EOF? Michael While many other people have shown you why you need not necessarily answer this question, I think it'd be helpful for you to hear the answer anyway. Your message is being produced because you are trying to getLine when there is no input left. This raises an exception, which, because it is not handled by your program, prints a diagnostic message and exits. Strangely, it prints this before the output of your program - this isn't terribly important, but for the sake of completeness, it's because of the different buffering characteristics of stdout and stderr, which confusingly mean that even though your program produces output and then produces an error, the error is printed immediately while the output waits until the program is terminated to be produced. I think. Something like that, anyway. So, how do you avoid the exception? You can use System.IO.isEOF [1] to check if there is input available on the standard input handle: main = do eof - isEOF when (not eof) realMain -- when from Control.Monad, see also: unless where realMain = do realStuff Or you can let getLine throw the exception, but catch it and deal with it yourself, rather than letting it kill your program. Catching it is a little less simple, but is considerably more flexible and powerful. The exceptions situation in Haskell is somewhat complicated by the fact that the mechanism used by haskell98 has been improved upon, but the new extensible mechanism is incompatible with the old so both have to hang around. Have a look at Control.Exception [2] and System.IO.Error [3]. In either case you have 'catch' as a sort of basic operation, and more convenient things like 'try' which sort of turn an exception into a pure Either result. I'd do something like this: main = do result - try getLine case result of Left err - return () -- or do something diagnostic Right - putStrLn main Right line - doStuffWith line On a more general note, your main function looks a little suspect because it *always* recurses into itself - there's no termination condition. A question nearly as important as how does my program know what to do is how does it know when to stop :) [1] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/System-IO.html#v%3AisEOF [2] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/Control-Exception.html [3] http://hackage.haskell.org/packages/archive/base/4.2.0.1/doc/html/System-IO-Error.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unwrapping long lines in text files
Nope. No redirection. Michael --- On Sat, 8/14/10, Brandon S Allbery KF8NH allb...@ece.cmu.edu wrote: From: Brandon S Allbery KF8NH allb...@ece.cmu.edu Subject: Re: [Haskell-cafe] Unwrapping long lines in text files To: haskell-cafe@haskell.org Date: Saturday, August 14, 2010, 7:17 PM -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 8/14/10 19:07 , Ben Millwood wrote: Strangely, it prints this before the output of your program - this isn't terribly important, but for the sake of completeness, it's because of the different buffering characteristics of stdout and stderr, which confusingly mean that even though your program produces output and then produces an error, the error is printed immediately while the output waits until the program is terminated to be produced. I think. Something like that, anyway. My guess is he's redirecting stdout and stderr to the same file, and stderr happens to get flushed by the Haskell runtime before stdout (possibly because a flush is performed regardless when an exception is printed). It is, as you note, not really relevant to the actual logic error leading to the exception. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxnJBUACgkQIn7hlCsL25X7jACgzk4uCCP/1LBDfgtRU0vfobZI +BgAn2oabimC8tKOII6xBC+LM41oTpqd =q1sj -END PGP SIGNATURE- ___ 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] Re: String vs ByteString
On Sat, Aug 14, 2010 at 16:38, Bryan O'Sullivan b...@serpentine.com wrote: In my opinion, this performance penalty hand-wringing is mostly silly. We're talking a pretty small factor of performance difference in most of these cases. Even the biggest difference, between ByteString and String, is usually much less than a factor of 100. This attitude towards performance, that it doesn't really matter as long as something happens *eventually*, is what pushed me away from Python and towards more performant languages like Haskell in the first place. Sure, you might not notice a few extra seconds when parsing some file on your quad-core developer desktop, but those seconds turn into 20 minutes of lost battery power when running on smaller systems. Having to convert the internal data structure between [Char], (Ptr Word16), and (Ptr Word8) can quickly cause user-visible problems. Libraries which will (by their nature) see heavy use, such as bytestring and text, ought to have much attention paid to their performance characteristics. A factor of 2-3x might be the difference between being able to use a library, and having to rewrite its functionality to be more efficient. In the unlikely event that you need to support non-Unicode encodings, they are readily available via text-icu. Unfortunately, text-icu is hardcoded to use libicu 4.0, which was released well over a year ago and is no longer available in many distributions. I sent you a patch to support newer versions a few months ago, but never received a response. Meanwhile, libicu is up to 4.4 by now. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: improve-0.0.8
ImProve [1] is a imperative programming language for high assurance applications. Using Yices [2], ImProve verifies programs will always adhere to assertion specifications, irrespective of program input. If it is possible for an assertion not to be upheld, ImProve will emit a counter example in the form of a program trace, which illustrates how the assertion could be violated. This release improves the means to annotate programs for debugging (see 'label'). Also, the model checker now includes a pass to remove irrelevant statements, thus speeding up verification and making counter example traces easier to read. At Eaton, we have started using ImProve on critical chunks of code in our hybrid vehicles. To date we have ImProve generated C successfully running in a new prototype vehicle. In addition to finding a handful of minor bugs, ImProve has revealed two specification ambiguities arising from multiple, conflicting requirements. Due to the nature of the conflict, it is highly unlikely that the defects would have been identified with conventional testing. -Tom [1] http://hackage.haskell.org/package/improve [2] http://yices.csl.sri.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Bryan O'Sullivan wrote: In general, Unicode uptake is increasing rapidly: http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html These Google graphs are the oft-quoted source of Unicode's growing dominance. But the data for those graphs is taken from Google's own web indexing. Google is a U.S. company that appears to have a strong Western culture bias - viz. their recent high-profile struggles with China. Google is far from being the dominant market leader in CJK countries that they are in Western countries. Their level of understanding of those markets is clearly not the same. It could be this really is true for CJK countries as well, or it could be that the data is skewed by Google's web indexing methods. I won't believe that source until it is highly corroborated with data and opinions that are native to CJK countries, from sources that do not have a vested interest in Unicode adoption. What we have heard in the past from members of our own community in CJK countries does not agree at all with Google's claims, but that may be changing. It would be great to hear more from them. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 5:11 PM, John Millikin jmilli...@gmail.com wrote: This attitude towards performance, that it doesn't really matter as long as something happens *eventually*, is what pushed me away from Python and towards more performant languages like Haskell in the first place. But wait, wait - I'm not at all contending that performance doesn't matter! In fact, I spent a couple of months working on criterion precisely because I want to base my own performance work on extremely solid data, and to afford the same opportunity to other people. So far in this thread, there's been exactly one performance number posted, by Daniel. Not only have I already thanked him for it, I immediately used (and continue to use) it to improve the performance of the text library in that instance. More broadly, what I am recommending is simple: - Use a good library. - Expect good performance out of it. - Measure the performance you get out of your application. - If it's not good enough, and the fault lies in a library you chose, report a bug and provide a test case. In the case of the text library, it is often (but not always) competitive with bytestring, and I improve it when I can, especially when given test cases. My goal is for it to be the obvious choice on several fronts: - Cleanliness of API, where it's already better, but could still improve - Performance, which is not quite where I want it (target: parity with, or better than, bytestring) - Quality, where text has slightly more test coverage than bytestring However, just text alone is a big project, and I could get a lot more done if I was both coding and integrating patches than if coding alone :-) So patches are very welcome. In the unlikely event that you need to support non-Unicode encodings, they are readily available via text-icu. Unfortunately, text-icu is hardcoded to use libicu 4.0, which was released well over a year ago and is no longer available in many distributions. I sent you a patch to support newer versions a few months ago, but never received a response. Yes, that's quite embarrassing, and I am quite apologetic about it, especially since I just asked for help in the preceding paragraph. If it's any help, there's a story behind my apparent sloth: I overenthusiastically accepted a patch from another contributor a few months before yours, and his changes left the text-icu darcs repo in a mess from which I have yet to rescue it. I do still have your patch, and I'll probably abandon my attempts to clean up the other one, as it was more work than I cared to clean it up. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 5:39 PM, Yitzchak Gale g...@sefer.org wrote: It could be this really is true for CJK countries as well, or it could be that the data is skewed by Google's web indexing methods. I also wouldn't be surprised if the picture for web-based text is quite different from that for other textual data. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Yitzchak Gale wrote: Bryan O'Sullivan wrote: In general, Unicode uptake is increasing rapidly: http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html These Google graphs are the oft-quoted source of Unicode's growing dominance. But the data for those graphs is taken from Google's own web indexing. Note also that all those encodings near the bottom are remaining relatively constant. UTF8 is taking its market share from ASCII and Western European encodings, not so much from other encodings (as yet). As Bryan mentioned, Unicode doesn't have wide acceptance in CJK countries. These days, Japanese websites seem to have finally started to standardize--- in that they use HTTP/HTML headers to say which encoding the pages are in (and generally use JIS or Shift-JIS). This is a big step up from a decade ago when non-commercial sites pretty invariably required fiddling with the browser to get rid of mojibake. Japan hasn't been bitten by the i18n/l10n bug and they don't have a strong F/OSS community to drive adoption either. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Quoth Bryan O'Sullivan b...@serpentine.com, In the case of the text library, it is often (but not always) competitive with bytestring, and I improve it when I can, especially when given test cases. My goal is for it to be the obvious choice on several fronts: - Cleanliness of API, where it's already better, but could still improve - Performance, which is not quite where I want it (target: parity with, or better than, bytestring) - Quality, where text has slightly more test coverage than bytestring That sounds great, and I'm looking forward to using Text in my application - at least, where I think it would help with respect to correctness. I can't imagine I would unpack all my data right off the socket, or disk, and use Text throughout my application, because I'm skeptical that unpacking megabytes of data from 8 to 16 bits can be done without noticeable impact on resources. I wouldn't imagine I would be filing a bug report on that, because it's a given - if I have a big data load, obviously I should be using ByteString. Am I confused about this? It's why I can't see Text ever being simply the obvious choice. [Char] will continue to be the obvious choice if you want a functional data type that supports pattern matching etc. ByteString will continue to be the obvious choice for big data loads. We'll have a three way choice between programming elegance, correctness and efficiency. If Haskell were more than just a research language, this might be its most prominent open sore, don't you think? Donn Cave, d...@avvanta.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 22:07, Donn Cave d...@avvanta.com wrote: Am I confused about this? It's why I can't see Text ever being simply the obvious choice. [Char] will continue to be the obvious choice if you want a functional data type that supports pattern matching etc. ByteString will continue to be the obvious choice for big data loads. We'll have a three way choice between programming elegance, correctness and efficiency. If Haskell were more than just a research language, this might be its most prominent open sore, don't you think? I don't see why [Char] is obvious -- you'd never use [Word8] for storing binary data, right? [Char] is popular because it's the default type for string literals, and due to simple inertia, but when there's a type based on packed arrays there's no reason to use the list representation. Also, despite the name, ByteString and Text are for separate purposes. ByteString is an efficient [Word8], Text is an efficient [Char] -- use ByteString for binary data, and Text for...text. Most mature languages have both types, though the choice of UTF-16 for Text is unusual. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Excerpts from John Millikin's message of Sun Aug 15 01:32:51 -0400 2010: Also, despite the name, ByteString and Text are for separate purposes. ByteString is an efficient [Word8], Text is an efficient [Char] -- use ByteString for binary data, and Text for...text. Most mature languages have both types, though the choice of UTF-16 for Text is unusual. Given that both Python, .NET, Java and Windows use UTF-16 for their Unicode text representations, I cannot really agree with unusual. :-) Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sun, Aug 15, 2010 at 8:39 AM, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from John Millikin's message of Sun Aug 15 01:32:51 -0400 2010: Also, despite the name, ByteString and Text are for separate purposes. ByteString is an efficient [Word8], Text is an efficient [Char] -- use ByteString for binary data, and Text for...text. Most mature languages have both types, though the choice of UTF-16 for Text is unusual. Given that both Python, .NET, Java and Windows use UTF-16 for their Unicode text representations, I cannot really agree with unusual. :-) When I'm writing a web app, my code is sitting on a Linux system where the default encoding is UTF-8, communicating with a database speaking UTF-8, receiving request bodies in UTF-8 and sending response bodies in UTF-8. So converting all of that data to UTF-16, just to be converted right back to UTF-8, does seem strange for that purpose. Remember, Python, .NET and Java are all imperative languages without referential transparency. I doubt saying they do something some way will influence most Haskell coders much ;). Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 22:39, Edward Z. Yang ezy...@mit.edu wrote: Excerpts from John Millikin's message of Sun Aug 15 01:32:51 -0400 2010: Also, despite the name, ByteString and Text are for separate purposes. ByteString is an efficient [Word8], Text is an efficient [Char] -- use ByteString for binary data, and Text for...text. Most mature languages have both types, though the choice of UTF-16 for Text is unusual. Given that both Python, .NET, Java and Windows use UTF-16 for their Unicode text representations, I cannot really agree with unusual. :-) Python doesn't use UTF-16; on UNIX systems it uses UCS-4, and on WIndows it uses UCS-2. The difference is important because: Python: len(\U0001dd1e) == 2 Haskell: length (pack \x0001dd1e) Java, .NET, Windows, JavaScript, and some other languages use UTF-16 because when Unicode support was added to these systems, the astral characters had not been invented yet, and 16 bits was enough for the entire Unicode character set. They originally used UCS-2, but then moved to UTF-16 to minimize incompatibilities. Anything based on UNIX generally uses UTF-8, because Unicode support was added later after the problems of UCS-2/UTF-16 had been discovered. C libraries written by UNIX users use UTF-8 almost exclusively -- this includes most language bindings available on Hackage. I don't mean that UTF-16 is itself unusual, but it's a legacy encoding -- there's no reason to use it in new projects. If text had been started 15 years ago, I could understand, but since it's still in active development the use of UTF-16 simply adds baggage. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
On Sat, Aug 14, 2010 at 22:54, John Millikin jmilli...@gmail.com wrote: Haskell: length (pack \x0001dd1e) Apologies -- this line ought to be: Haskell: Data.Text.length (Data.Text.pack \x0001dd1e) == 1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
