Re: [Haskell-cafe] Bathroom reading
On Tue, 2007-08-14 at 17:22 +0200, Bas van Dijk wrote: On 8/14/07, Dougal Stanton [EMAIL PROTECTED] wrote: I'm looking for cool but mind-bending examples of functional brilliance. Maybe: http://www.haskell.org/haskellwiki/Blow_your_mind http://haskell.org/haskellwiki/Research_papers/Functional_pearls The Evolution of a Haskell Programmer is cute: http://www.willamette.edu/~fruehr/haskell/evolution.html -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hints for Euler Problem 11
On Thu, 2007-08-16 at 12:50 -0700, Kim-Ee Yeoh wrote:
Aaron Denney wrote:
On 2007-08-15, Pekka Karjalainen [EMAIL PROTECTED] wrote:
A little style issue here on the side, if I may. You don't need to use
(++) to join multiline string literals.
text = If you want to have multiline string literals \
\in your source code, you can break them up with \
\backslashes. Any whitespace characters between \
\two backslashes will be ignored.
I find the first far more readable. The compiler should be able to
assemble it all at compile time, right?
'Course not. The (++) function like all Haskell functions is only a
/promise/ to do its job. What does assembling at compile time
mean here:
s = I will not write infinite loops ++ s
Let's check, shall we? I've never used core before, but there's a first
time for everything:
% cat C.hs
module Test where
x = Foo ++ Bar
y = Zot ++ y
% ghc -ddump-simpl C.hs
Tidy Core
Test.x :: [GHC.Base.Char]
[GlobalId]
[]
Test.x =
GHC.Base.++
@ GHC.Base.Char (GHC.Base.unpackCString# Foo) (GHC.Base.unpackCString#
Bar)
Rec {
Test.y :: [GHC.Base.Char]
[GlobalId]
[]
Test.y = GHC.Base.++ @ GHC.Base.Char (GHC.Base.unpackCString# Zot) Test.y
end Rec }
If I interpret it correctly, the compiler does approximately nothing -
reasonably enough, since we didn't ask for optimization. With -O:
% ghc -ddump-simpl C.hs -O
Tidy Core
Rec {
Test.y :: [GHC.Base.Char]
[GlobalId]
[Str: DmdType]
Test.y = GHC.Base.unpackAppendCString# Zot Test.y
end Rec }
Test.x :: [GHC.Base.Char]
[GlobalId]
[Str: DmdType]
Test.x = GHC.Base.unpackCString# FooBar
y gets turned into an unpackAppendCString#, which I can only presume is
a sensible way to represent a cyclic list, while x gets concatenated
compile-time.
-k
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] let and fixed point operator
On Thu, 2007-08-30 at 18:17 +0200, Peter Hercek wrote: I find the feature that the construct let x = f x in expr assigns fixed point of f to x annoying. Any alternative? Non-recursive assignments? f x = let x = x * scale in let x = x + transform in g x I think it is often it is better to avoid temporary names. I guess this is a simplified example, but I think it is better to write: f x = g (transform + scale * x) Or even use point-free style to avoid fixpoint? f = g . (+transform) . (* scale) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hawiki articles
On Mon, 2007-09-03 at 14:57 +0200, Henning Thielemann wrote: In the current Haskell Wiki (haskell.org/haskellwiki) I found references to articles of the old Hawiki (haskell.org/hawiki), like OnceAndOnlyOnce and SeparationOfConcerns. Are the files still available somewhere? Ditto for links to HaskellDB. HaskellDB looks nice, but the online documentation is scattered with broken links in all directions. In order of appearance on Google: http://haskelldb.sourceforge.net/ - some good info, but needs maintenance. E.g. broken link to old wiki http://www.haskell.org/haskellDB/ - downloads page claims last update in 1999(!) http://haskell.org/haskellwiki/Libraries_and_tools/Database_interfaces/HaskellDB - more a catalog of historic rather than practical interest I think it's fair to say the situation doesn't actually make it easy to get started with one of the most central Haskell DB interfaces. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: RE: Definition of the Haskell standard library
On Sat, 2007-09-01 at 23:53 +0200, Benjamin Franksen wrote: Sven Panne wrote: Well, on a normal Linux distro a user should *never* have to call cabal (or any of its cousins) directly, the distro's package manager should be the used instead. This is very theoretical. Perfect is the enemy of good? I use debian (stable) and have to install non-deb Haskell libraries all the time. No way distro package maintainers can provide packages for each and every library out there, and even for 'standard' libs (whatever that may mean) sometimes you need a newer or an older version of a certain library (relative to what the distro offers). Ubuntu (which gets most of its packages from Debian) lists 60 GHC-related packages (apt-cache search libghc), which hopefully serves to build a reasonable set of applications. Ideally, Hackage could be provide its libraries as apt/yum repositories - at least for libraries that are reasonably stable and with reasonable quality. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Extending the idea of a general Num to other types?
On Wed, 2007-09-05 at 08:19 +0100, Simon Peyton-Jones wrote: | confusing for new users to have the compiler suggest pointless things | like declaring an instance of Num String or whatever. This also gets my vote for the Error-message-most-likely-to-be-unhelpful-award. IME, this often arises from incorrect use of operators or wrong number of parameters, not missing instances. It's difficult to make error messages helpful. Certainly. But better to err on the side of brevity. when you come across a case where GHC produces an unhelpful message, send it in, along with the program that produced it, Contents of test/error.hs: f x s = x + show s Error message from GHCi: test/error.hs:2:8: No instance for (Num String) arising from use of `+' at test/error.hs:2:8-17 Possible fix: add an instance declaration for (Num String) In the expression: x + (show s) In the definition of `f': f x s = x + (show s) your suggestion for the error message you'd like to have seen. Suggestion: As is, with removal the Possible fix, as it is often misleading (i.e. here, the programmer clearly meant to use '++' and not '+'. Perhaps rephrase to something like String is not an instance of Num? For a newbie, it may not be clear that Num is the class and String is the type. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANNOUNCE: xmonad 0.3
On Wed, 2007-09-05 at 13:02 +1000, Donald Bruce Stewart wrote: The xmonad dev team is pleased to announce the 0.3 release of xmonad. I just wanted to congratulate the team, and say that xmonad is, along with darcs, my favorite mainstream Haskell program. I used to spend days experimenting with different window managers and applets, docks and whatnot; now I get so much more time to do more important stuff - like spamming technical mailing lists with non-technical content. But I digress. Nice work! -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Elevator pitch for Haskell.
WARNING: Learning Haskell is dangerous to your health! :-) I liked that so much I made a hazard image to go with it. http://malde.org/~ketil/Hazard_lambda.svg -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Extending the idea of a general Num to other types?
On Wed, 2007-09-05 at 09:56 +0100, Simon Peyton-Jones wrote: Is your suggestion specific to String? No. then I really might have intended to use Complex as a Num type IME this is much rarer, and I think if a newbie is told that Complex is not (but needs to be) and instance of Num, it is relatively easy to find the relevant information (Looking up 'instance' and/or 'class' in the index of any Haskell text book should do the trick) | rephrase to something like String is not an instance of Num? For a | newbie, it may not be clear that Num is the class and String is the | type. Good point. Not so easy for multi-parameter type classes! E.g. No instance for (Bar String Int). So we could have String is not an instance of class Foo -- single param No instance for (Bar String Int)-- multi-param If you quote things, you can also consider: 'String Int' is not an instance of class 'Bar'. Downside is that 'String Int' by itself may be confusingly unhaskellish. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Elevator pitch for Haskell.
On Wed, 2007-09-05 at 12:06 +0100, Simon Marlow wrote: Ketil Malde wrote: WARNING: Learning Haskell is dangerous to your health! :-) I liked that so much I made a hazard image to go with it. http://malde.org/~ketil/Hazard_lambda.svg Cool! Can we have a license to reuse that image? (I want it on a T-shirt) Hereby licensed free for any imaginable use including creation of derivative works. However, there is no warranty, neither express nor implied of ever understanding category theory. :-) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mutable but boxed arrays?
On Wed, 2007-09-05 at 20:37 +0200, Henning Thielemann wrote: Can someone explain me, why there are arrays with mutable but boxed elements? I, on the other hand, have always wondered why the strict arrays are called unboxed, rather than, well, strict? Strictness seems to be their observable property, while unboxing is just an (admittedly important) implementation optimization. I imagine that it'd be at least as easy to implement the strictness as the unboxedness for non-GHC compilers, and thus increase compatibility. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Elevator pitch for Haskell.
On Wed, 2007-09-05 at 09:54 -0700, Simon Michael wrote: I agree actually. That picture, while very cool, won't help Haskell marketing one bit. :) Avoid success at all costs, remember? Lisp's made with alien technology is much more inviting: http://www.lisperati.com/logo.html . True. Perhaps we can take it, but change the text to advanced Made with V alien technology ? Albert Y.C. Lai wrote: I have also looked at the culture of people 10-20 years younger than me. To wit: I put the lambda-hazard skull on my door, and fifteen minutes later a (admittedly young) colleague was asking about the lambda symbol, and I was extolling the virtues of functional programming. :-) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Tue, 2007-09-11 at 09:10 +0200, Sven Panne wrote: foo :: Binary a = ... - a - ...? This should probably mean foo is using some portable (de-)serialization, but doesn't care about the actual representation, I'm probably missing something, but: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary Endianness
On Tue, 2007-09-11 at 12:01 +0100, Jules Bean wrote: How can the format be portable if the representation isn't unambigously defined? And if it is unabmigously defined, what's wrong with using it for externally defined data formats? It's portable because it works on other machines also running that exact version of Data.Binary, regardless of their CPU architecture (in particular, word size or endianness). That is the precise sense of 'portable' used here. Okay. Data.Binary is not for persistence, then (since the format may change between versions of the library, and presumably between different compilers/RTS), but merely for transient serializing, as over a network connection. This isn't so obvious from the documentation (I myself have blatantly used it for persistence and for reading in externally specified data), and the functions involving FilePaths also tend confusing the issue here. Perhaps it could be made clearer? Another way to avoid abuse of Data.Binary would be to add a unique magic number to each stream, and throw an exception when a mismatching magic number is encountered. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is take behaving correctly?
On Thu, 2007-09-13 at 09:56 +0100, Jules Bean wrote: Neil Mitchell wrote: Hi Although I appluad the semantics of the safe package, I'm not delighted with the idea of replacing our concise elegant standard library names with uglyAndRatherLongCamelCaseNamesThatCouldBePerlOrEvenJava though. Conciseness of expression is a virtue. They aren't that long - merely an extra 4 characters over the standard one to indicate what the specific semantics are. If you can think of better names, then I'm happy to make use of them. No, they're not, and it wasn't intended as a slight against your naming choice. I don't have a better suggestion. Isn't there sort of a tradition for 'unsafe' to mean dangerous territory, beyond mere domain limitations for functions, so to call this 'safe' may be a bit misleading? Similarly, I expect foo and foo' to be equivalent, except for strictness properties, but perhaps an underscore could be used for slightly different behaviors (interpretations, as it were)? tail_ or zip_, anyone? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: getting crazy with character encoding
On Wed, 2007-09-12 at 17:40 -0700, Stefan O'Rear wrote: On Thu, Sep 13, 2007 at 12:23:33AM +, Aaron Denney wrote: Unfortunately, at this point it is a well entrenched bug, and changing the behaviour will undoubtedly break programs. ... There should be another system for getting the exact bytes in and out (as Word8s, say, rather than Chars), I'm pretty sure Hugs does the right thing. ..which makes me wonder what the right thing actually is? Since IO on Unix (or at least on Linux) consists of bytes, I don't see how a Unicode-only interface is ever going to do the 'right thing' for all people. One possible solution might be to have IO functions deal with [Word8] instead of [Char]. If string and character constants were polymorphic, Char and String made aliases for byte-based types, and a new type introduced for Unicode characters, it might even be possible to fix without breaking absolutely all legacy code. But even this would probably only fix the Unix side of things. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Is take behaving correctly?
On Thu, 2007-09-13 at 13:56 +0100, Neil Mitchell wrote: tail = fromJust . tailMay The error messages suffer [..] That's why I supplied tailNote Still, given tailMay, we have: tailDef xs = maybe xs id . tailMay tailNote msg = tailDef (error msg) tailSafe = tailDef [] tail = tailNote tail: empty list which I suppose was Lutz's point? (My rather ugly preference is to #define tail so that an error message contains source code location.) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Sun, 2007-09-16 at 12:13 -0700, David Roundy wrote: On Sat, Sep 15, 2007 at 08:27:02AM +0100, Adrian Hey wrote: Perhaps what you really mean is, you long for a Data.Map.Strict that carries the offically blessed status of being shipped with ghc (reminds me of someone asking for a ghc approved SDL binding a while back :-). Yes, that would be what I mean. It seems Adrian's library is a replacement for Data.Map, only with higher performance and more features. What would the disadvantages be to replacing Data.Map with this implementation? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Observations from ListLike
On Mon, 2007-09-17 at 14:37 -0500, John Goerzen wrote: * It would be really nice if QuickCheck supported I/O and some version of HUnit's TestLabel to generate hierarchical names when failures occur. I've done this for testing IO (reading and writing files): prop_serialize (E s) = let [s'] = unsafePerformIO (do writeFasta /tmp/serialize_test [s] readFasta /tmp/serialize_test) in s == s' I'm not sure if this is kosher, but at least the tests pass :-) I (like everybody else?)'ve written a small driver for the tests, but perhaps I should look at HUnit for a more general framework? -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Building production stable software in Haskell
On Tue, 2007-09-18 at 01:11 +0100, Neil Mitchell wrote: DBM's can differentiate themselves on external database support, Surely this is an opportunity to focus development on a single library with broader support? Currently, we have HSQL and HDBC supplying incompatible low-level interfaces, supporting a different set of back ends. No matter what I choose, I risk having to make a costly conversion later on. XML is not simple and does not interface to third party programs. I can think of at least 4 XML libraries, all of which are quite different. ...and at least some of them come with their own re-implementation of Data.Tree. I think competition and choice can be great, but I also think it is important to have a good default libraries to turn to for, well, production stable software. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library Process (was Building production stable software in Haskell)
On Tue, 2007-09-18 at 11:14 +0100, Malcolm Wallace wrote: I would like to see the same separation forming between the ghc compiler itself (which would minimally include only the small number of libraries needed to build the compiler), and larger distributions which would be maintained by other people, and include much larger collections of packages that the maintainer has tested and verified to work together. I think there is a niche for a subset of the hackage libraries providing an officially sanctioned standard library collection. Currently, hackage includes, well, everything. As such, it is a useful resource, but it would be useful to have a partitioning into two levels, where the SLC would only include libraries that meet specific criteria. Maybe: - considered stable - is portable - relies only on other standard libraries - avoids needless duplication of functionality - with a responsive, named maintainer (not libraries@) - with acceptable documentation and unit tests - required by at least one separate application -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Library Process (was Building production stable software in Haskell)
On Sun, 2007-09-23 at 21:17 -0400, David Menendez wrote: My point was that I'm not aware of any packaging systems that don't have a global installed/not installed bit for each package, which isn't suited to handling Haskell libraries. I don't agree - you are assuming there is a one to one correspondence between Cabal libraries and binary packages. The normal way to resolve this is that each source library gets compiled to multiple binary packages, which optionally can be unified as virtual packages 'providing' specific functionality. E.g. on my system (Ubuntu), I installed the virtual package 'ghc' to get GHC 6.6(.1?) which is actually provided by the package called 'ghc6'. In addition, I have the QuickCheck library installed, from a package named 'libghc6-quickcheck-dev', making room for libhugs-quickcheck-dev' etc. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On Tue, 2007-10-02 at 14:32 -0700, Stefan O'Rear wrote: UTF-8 supports CJK languages too. The only question is efficiency, and I believe CJK is still a relatively uncommon case compared to English and other Latin-alphabet languages. (That said, I live in a country all of whose dominant languages use the Latin alphabet) As for space efficiency, I guess the argument could be made that since an ideogram typically conveys a whole word, it is reasonably to spend more bits for it. Anyway, I am unsure if I should take part in this discussion, as I'm not really dealing with text as such in multiple languages. Most of my data is in ASCII, and when they are not, I'm happy to treat it (treat here meaning mostly ignore) as Latin1 bytes (current ByteString) or UTF-8. The only thing I miss is the ability to use String syntactic sugar -- but IIUC, that's coming? However, increased space usage is not acceptable, and I also don't want any conversion layer which could conceivably modify my data (e.g. by normalizing or error handling). -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: PROPOSAL: New efficient Unicode string library.
On Tue, 2007-10-02 at 21:45 -0400, Brandon S. Allbery KF8NH wrote: Due to the additional complexity of handling UTF-8 -- EVEN IF the actual text processed happens all to be US-ASCII -- will UTF-8 perhaps be less efficient than UTF-16, or only as fast? UTF8 will be very slightly faster in the all-ASCII case, but quickly blows chunks if you have *any* characters that require multibyte. What benchmarks are you basing this on? Doubling your data size is going to cost you if you are doing simple operations (searching, say), but I don't see UTF-8 being particularly expensive - somebody (forget who) implemented UTF-8 on top of ByteString, and IIRC, the benchmarks numbers didn't change all that much from the regular Char8. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke [EMAIL PROTECTED] writes: if this is the official interpretation of cabal package version numbers, could it please be made explicit in a prominent position in the cabal docs? Me too. This is not a criticism nor endorsement of any particular scheme, just a vote in favor of having a - one, single, universal - scheme. of course, i have absolutely no idea how to write stable packages under this interpretation. and the examples in the cabal docs do not explain this, either (neither bar nor foo 1.2 are any good under this interpretation). You need a way to specify foo 1.2 foo 2, which is a suggestion that was tossed around here recently. Also, you'd need foo 1.x for x=2 to be available after foo-2.0 arrives. 'base' aside, I don't think we want a system that requires us to rename a library any time incompatible changes are introduced. The major/minor scheme has worked nicely for .so for ages. I'd like to make the additional suggestion that a major version number of 0 means no compatibility guarantees. Another reason not to change the name of 'base' is that there would be a significant cost to doing so: the name is everywhere, not just in the source code of GHC and its tools, but wiki pages, documentation, and so on. Much like 'fps', now known as 'bytestring', no? I had some problems finding it, true, but the upside is that old stuff is free to reference fps until I can get around to test and update things. how about using a provides/expects system instead of betting on version numbers? if a package X expects the functionality of base-1.0, cabal would go looking not for packages that happen to share the name, but for packages that provide the functionality. base-not-1.0 would know that it doesn't do that. and if there is no single package that reexports the functionality of base-1.0, cabal could even try to consult multiple packages to make ends meet Scrap cabal in favor of 'ghc --make'? :-) Seriously though, how hard would it be to automatically generate a (suggested) build-depends from ghc --make? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith [EMAIL PROTECTED] writes: I think what you're asking for is more than that: you want us to provide base-1.0, base-2.0 and base-3.0 at the same time, so that old packages continue to work without needing to be updated. Yes. That is possible, but much more work for the maintainer. How much more work, really? If the dependencies of your library have similar backwards compatible support, you only have to keep track of backwards-incompatible changes to the compiler, and I think those are relatively few and far apart. Ultimately when things settle down it might make sense to do this kind of thing, but right now I think an easier approach is to just fix packages when dependencies change, and to identify sets of mutually-compatible packages (we've talked about doing this on Hackage before). I'm surprised you think this is easier - There's an awful lot of possible version combinations, and for every library that breaks, there is - at least potentially - a lot of applications that needs updating. Many of those will be web orphans that some curious newbie will download and fail to get to work. (SOE, anybody? FiniteMap to Data.Map?) I think a library is more likely to be supported than an application, and likely to be supported by more and more competent developers. I think it's a no-brainer that old versions of packages should remain available for people to use for 'a long time'. If their dependencies are specified properly they should continue building successfully as time passes. Amen. Presumably it's not usually a problem if indirect package dependencies require incompatible versions of a package. If it is, I think this is a strong argument in favor of package bundles that are released and upgraded together as something resembling a standard library. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Claus Reinke [EMAIL PROTECTED] writes: You need a way to specify foo 1.2 foo 2, which is a suggestion that was tossed around here recently. but what does such a version range say? that i haven't tested any versions outside the range (because they didn't exist when i wrote my package)? or that i have, and know that later versions won't do? IMO, it says that it works with interface version 1, and needs some stuff from sublevel 2, and as long as the foo developers keep their end of the bargain, it will continue to work with new releases in the 1-series. For foo-2, the interface may change, and all bets are off. The dependency could be expressed more in a more succinct (albeit less flexible) manner with a different syntax (e.g. foo-1.2). if that decision is based on version numbers alone, we need to be specific about the meaning of version numbers in dependencies. Yes. and if the major/minor scheme is to be interpreted as Simon summarised, the only acceptable form of a dependency is an explicit version range (the range of versions known to work). I'm happy with expected to work. The major/minor scheme has worked nicely for .so for ages. i'm not so sure about that. it may be better than alternatives, but [..] Also, it sees a lot of testing, at least in current Linux distributions. The point is that the end-user experience is pretty good. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Proposal: register a package as providing several API versions
ChrisK [EMAIL PROTECTED] writes: Once it is possible to have cabal register the hsFoo-3.0.0 also as hsFoo-2 it will be easy to upgrade to hsFoo. No old programs will fail to compile. Who here knows enough about the ghc-pkg database to say how easy or hard this would be? Ignoring disk space, I suppose the motivation is that it will ease the user experience by only having to download, compile and install a single package? And perhaps ease the maintenance a bit for the library author, too. One way to do this would be to have multiple .cabal files in the package, with small differences like different version numbering. You can use a Makefile or other hack to automate switching. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith [EMAIL PROTECTED] writes: 3. Otherwise, major.minor MUST remain the same (other version components MAY change). Is it an option to say SHOULD rather than MUST here? There are other reasons for a version bump than breaking compatibility. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Do you trust Wikipedia?
PR Stanley [EMAIL PROTECTED] writes: Do you trust mathematical materials on Wikipedia? Generally, yes. Another site you might want to cross check with is Wolfram Research's Mathworld: http://mathworld.wolfram.com/ -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Re: Trying to install binary-0.4
Daniel McAllansmith [EMAIL PROTECTED] writes: There are other reasons for a version bump than breaking compatibility. Technical reasons? Well - say I refactor everything, and use algorithms with different run-time complexities, and possibly introduce different bugs than the ones the applications have come to rely on/work around. Even if the interface is type-level compatible, a conservative application would still prefer to link with the old version. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Proposal: register a packageasprovidingseveralAPI versions
Claus Reinke [EMAIL PROTECTED] writes: Incedentally, this reminds me that GHC should have a warning for not using explicit import lists (perhaps only for external package imports). for package-level imports/exports, that sounds useful. Isn't there a secret key combination in haskell-mode for Emacs that populates the import lists automatically? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hiding side effects in a data structure
I've done something similar, I think. Often, I want to output some
kind of progress indicator, just to show that the program is working.
Typically, the program works by lazily evaluating a list (lines from
an input file, say); each element of the list is wrapped with an IO
action that outputs the status when evaluated -- which typically
happens lazily from pure code.
countIO :: String - String - Int - [a] - IO [a]
countIO msg post step xs = sequence $ map unsafeInterleaveIO ((blank
outmsg (0::Int) c):cs)
where (c:cs) = ct 0 xs
output = hPutStr stderr
blank= output ('\r':take 70 (repeat ' '))
outmsg x = output ('\r':msg++show x) hFlush stderr
ct s ys = let (a,b) = splitAt (step-1) ys
next = s+step
in case b of [b1] - map return a ++ [outmsg (s+step)
hPutStr stderr post return b1]
[] - map return (init a) ++ [outmsg
(s+length a) hPutStr stderr post return (last a)]
_ - map return a ++ [outmsg s return
(head b)] ++ ct next (tail b)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] XML parser recommendation?
Hi, I'm struggling to get my HXT-based parser to parse a largish file (300MB), even after breaking into reasonably-sized chunks. The culprit appears to be parsing one element comprising 25K lines of text, which apparently requires more memory than the 2Gb my computer is equipped with. I'm wondering what approach others use for non-toy XML data. Is the problem due to some error I have made, or should I just ignore the XML, and just parse it manually by dissecting bytestrings, or will another XML library serve better? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] will the real quicksort please stand up? (or: sorting a million element list)
[EMAIL PROTECTED] writes: 1. Avoid two pass filtering. 2. Avoid unecessary (++), with an accumulator. For example: Also, I find that 3. Accumulate equal elements, too pa (y:ys) s e b = case compare x y of ... to be a good choice. Otherwise, quicksort easily grows towards quadratic if you have many multiples of the same value. I think this is more common than the other major pitfall, sorting an already sorted list. (But perhaps the three-way case based on 'compare' is more expensive than the two-way () test?) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: XML parser recommendation?
Rene de Visser [EMAIL PROTECTED] writes: If I undertand the coding correctly every tag is stored as a seperate Haskell string. As each byte of a string under GHC takes 12 bytes this alone leads to high memory usage. Not that it detracts from your point, but I guess that is 24 bytes per character on 64 bit machinery? :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] XML parser recommendation?
Ketil Malde [EMAIL PROTECTED] writes: HaXml on my list after TagSoup, which I'm about to get to work, I think (got distracted a bit ATM). As it is, I managed to parse my document using TagSoup. One major obstacle was the need to process a sizeable partition of the file. Using 'partitions' from TagSoup (which is implemented using the 'groupBy (const (not . p))' trick) didn't work, as it requires space proportional to the partition size. My solution (and please forgive me, it is getting late at night here) was to replace it with (slightly different semantics alert): breaks :: (a - Bool) - [a] - [[a]] breaks p (x:xs) = let first = x : takeWhile (not.p) xs rest = dropWhile (not.p) xs in rest `par` first : if null rest then [] else breaks p rest I have no idea how reliable this is, and I suspect it isn't very, but on the plus side it does seems to work, at long as I compile with -smp. Parsing 300Mbytes of XML and outputting the information in 305K records takes approximately 5 minutes, and works with less than 1G of heap. This is fast and small enough for my purposes. Thanks for listening, and good night! -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binary constants in Haskell
Don Stewart [EMAIL PROTECTED] writes: Are there binary constants in Haskell, as we have, for instance, 0o232 for octal and 0xD29A for hexadecimal? No, though it is an interesting idea. Presumably it is less common since octal and hexadecimal are more compact and almost as easy to interpret as bit patterns? Why would you want them? Prelude let bin = foldl... Prelude 0o232 154 Prelude bin [0,1,0, 0,1,1, 0,1,0] 154 Prelude 0xD29A 53914 Prelude bin [1,1,0,1, 0,0,1,0, 1,0,0,1, 1,0,1,0] 53914 -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Binary constants in Haskell
Dusan Kolar [EMAIL PROTECTED] writes: // PLS, no flame I apologize if my post came across as such, that was certainly not the intent. I think the question was [..] whether there's such a literal or not and whether it is bad idea to have something like 0b10111011. I agree. From my point of view, the difference between 0b10111011 and (bin[1,0,1,1,1,0,1,1]) is 22-10 that is 12 characters. And from my point of view, 0xEE or 0x273 are equally readable, and even more succinct. If you are into bit-twiddling, that is. For user-friendly bitfields you should obviously provide a higher level interface. So, i would expect only two answers: NO, it is ..., or YES, in version 6.9.0 it is possible. ;-) As far as I know, there are no such plans. Send in a patch and see if it gets accepted :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Strictness leak
Some time ago, I posted this code:
countIO :: String - String - Int - [a] - IO [a]
countIO msg post step xs = sequence $ map unsafeInterleaveIO ((blank
outmsg (0::Int) c):cs)
where (c:cs) = ct 0 xs
output = hPutStr stderr
blank= output ('\r':take 70 (repeat ' '))
outmsg x = output ('\r':msg++show x) hFlush stderr
ct s ys = let (a,b) = splitAt (step-1) ys
next = s+step
in case b of [b1] - map return a ++ [outmsg (s+step)
hPutStr stderr post return b1]
[] - map return (init a) ++ [outmsg
(s+length a) hPutStr stderr post return (last a)]
_ - map return a ++ [outmsg s return
(head b)] ++ ct next (tail b)
It wraps a list with IO operations, so that progress can be reported
while evaluating the list elements. Unfortunately, there seems to be
a stricness leak here - and consequently, it does not work on an
infinite list.
I'm not sure why this happens, can anybody else see it?
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strictness leak
Jeff Polakow [EMAIL PROTECTED] writes:
Besides anything else, sequence will diverge on an infinite list.
Argh, of course. Thanks!
It is necessary to compute all of the computations in the list before
returning
any of the pure resulting list.
Replacing sequence with sequence', given as:
sequence' ms = foldr k (return []) ms
where
k m m' = do { x - m; xs - unsafeInterleaveIO m'; return (x:xs) }
seems to solve it.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Don Stewart [EMAIL PROTECTED] writes: goalieca: So in a few years time when GHC has matured we can expect performance to be on par with current Clean? So Clean is a good approximation to peak performance? If I remember the numbers, Clean is pretty close to C for most benchmarks, so I guess it is fair to say it is a good approximation to practical peak performance. Which proves that it is possible to write efficient low-level code in Clean. And remember usually Haskell is competing against 'high level' languages like python for adoption, where we're 5-500x faster anyway... Unfortunately, they replaced line counts with bytes of gzip'ed code -- while the former certainly has its problems, I simply cannot imagine what relevance the latter has (beyond hiding extreme amounts of repetitive boilerplate in certain languages). When we compete against Python and its ilk, we do so for programmer productivity first, and performance second. LOC was a nice measure, and encouraged terser and more idiomatic programs than the current crop of performance-tweaked low-level stuff. BTW, Python isn't so bad, performance wise. Much of what I do consists of reading some files, building up some hashes (associative arrays or finite maps, depending on where you come from :-), and generating some output. Python used to do pretty well here compared to Haskell, with rather efficient hashes and text parsing, although I suspect ByteString IO and other optimizations may have changed that now. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why can't Haskell be faster?
Sebastian Sylvan [EMAIL PROTECTED] writes: [LOC vs gz as a program complexity metric] Obviously no simple measure is going to satisfy everyone, but I think the gzip measure is more even handed across a range of languages. It probably more closely aproximates the amount of mental effort [..] I'm not sure I follow that reasoning? At any rate, I think the ICFP contest is much better as a measure of productivity. But, just like for performance, LOC for the shootout can be used as a micro-benchmark. Personally I think syntactic noise is highly distracting, and semantic noise is even worse! This is important - productivity doesn't depend so much on the actual typing, but the ease of refactoring, identifying and fixing bugs, i.e *reading* code. Verbosity means noise, and also lower information content in a screenful of code. I think there were some (Erlang?) papers where they showed a correlation between program size (in LOC), time of development, and possibly number of bugs?) - regardless of language. Token count would be good, but then we'd need a parser for each language, which is quite a bit of work to do... Whatever you do, it'll be an approximation, so why not 'wc -w'? With 'wc -c' for J etc where programs can be written as spaceless sequences of symbols. Or just average chars, words and lines? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] using an external application
Andrew Butterfield [EMAIL PROTECTED] writes: I'm puzzled - when I run this on GHCi (v6.4, Windows XP) I get the following outcome^^ The process cannot access the file because it is being used by another process. Isnt' this a difference between Windows and Unix? Windows typically locks files, Unix typically does not. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ghc -e with standard input
Maurício [EMAIL PROTECTED] writes: Actually, what I want is to select a region of text from emacs and get back the result of that evaluated as haskell code. So, I need something that is fast to type M-| xargs ghc -e almost works - but ghc -e evaluates only a single argument, so you need to enclose the region with quotes (and escape any quotes inside it). A bit of elisp could probably do it fairly easily. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best Linux for Haskell?
david48 [EMAIL PROTECTED] writes: Didn't work for me : Installs fine, ghci works fine, but I get linking problems. ld complains about -lgmp Did you try installing any of these? % apt-cache search libgmp libgmp3-dev - Multiprecision arithmetic library developers tools libgmp3c2 - Multiprecision arithmetic library -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] words function
Ryan Bloor [EMAIL PROTECTED] writes: I am trying to create a function that uses the words function... I am doing the same thing to each element in a list so I am using mapping techniques. And it doesn't work? --Define the main first function rStrings2Results :: ([String] - String) - [[String]] - [String] rStrings2Results f(head:tail) = (f head : rStrings2Results f tail) Note that you will shadow 'head' and 'tail' from the Prelude here. Ideally, you should choose different names, I think (x:xs) is idiomatic, or perhaps (l:ls) for a list and lists in this case. I notice 'rStrings2Results' looks very much like a reimplementation of a common Prelude function, presumably that is intentional? I just want take a list and on the first member (hello my name is ryan) to say [(hello, my, name, is, ryan),..] using the words function. You really want to return a tuple here, and not a list? You then would have to have a fixed number of words in each string. If you mean to convert hello my name.. to [hello,my,name..], well, I guess you know how to achieve that. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interesting effect of upgrading GHC
Neil Mitchell [EMAIL PROTECTED] writes: I just removed GHC 6.6.1 and installed 6.8.1, and I noticed something rather unexpected. I recompiled an existing program (with -O2), and instead of taking 30 seconds to compile, it took roughly 2 seconds. In previous releases, certain constructs took O(n^2) time to compile. One that was a particular issue for me was: I've noticed that largish data structures - in my case, ~20x20 matrices - embedded in code seems to take a surprisingly long time to compile. (I haven't noticed (nor looked for) any speedup with new releases, though.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why are OCaml and Haskell being used at these companies?
Seth Gordon [EMAIL PROTECTED] writes: Bioinformaticians are among the first to adopt functional programming languages From my experience, Bioinformatics use a mixture of langauges - C to implement various algorithms, a bit of Java for UI-oriented stuff, and Perl to tie it all together. (You can use Python instead, of course, but expect to be considered something of a rebel.) I think Haskell works nicely to combine at least the C and Perl aspects, but as far as I can tell, I'm about the only one who does this. There isn't a lot of comp.sci. in bioinformatics, beyond a handful of relatively standard algorithms. I guess it's one of those practical fields. I guess the important difference to the financial sector is that the competitive advantage is in exclusive data, not exclusive algorithms or analytical methods. Thus, programmer productivity isn't quite so important, you're just going to script togehter some pre-packaged tools, often ten or fifteen year old software. FWIW, a few years ago, when I was stubbornly unemployed[*], I wrangled a fifteen-minute informational interview with Kenan Sahin[**]. He advised me to look for work related to medical devices Sounds like good advice to me - pharmaceuticals seem to have enough money, at least. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] More accessible papers
Peter Verswyvelen [EMAIL PROTECTED] writes: Most research papers have the same layout: two columns per A4 page. They mostly come as PDF or PS. I think it is (more and more) common these days for journals to publish an HTML version on their web site. Otherwise I'd suggest e-mailing the author and asking for a single-column version (or whatever you need), or at least LaTeX sources or other editable version. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Brandon S. Allbery KF8NH [EMAIL PROTECTED] writes: Kind of like Google PageRank for libraries. Yes. Only up to a point; not all programs written using such libraries are necessarily going to end up on hackage. (Consider the code written by the financials folks that have been mentioned here various times; I don't see that as a problem -- if you don't contribute, you don't get to vote. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Thomas Schilling [EMAIL PROTECTED] writes: I would advocate using a comment system that is similar to the one at http://djangobook.com/. I'm pretty sure Brian O'Sullivan has written a Haskell implementation of this for the Real World Haskell book. While the technology is there (or will be), I worry if this is the right solution for something else than soliciting comments on a (fixed, non-editable) text. I can all to easily imagine a situation where any documentation is riddled with a plethora of notes, questions, answers, comments etc, with nobody to clean up the mess every now and then. For user-edited documentation, a wiki seems a much better fit - where each author make some effort to leave pages as self-contained consistent documents. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Over-allocation
Gracjan Polak [EMAIL PROTECTED] writes: let entries = IntMap.fromList (map (\(a,b,c) - (a,c)) (concat p)) Gut reaction: Map is lazy in its values (but probably not the key, which are checked for order), so you should force the 'c' before inserting it in the map. (There's probably a strict fromList or IntMap somewhere?) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Duncan Coutts [EMAIL PROTECTED] writes: 4. Meanwhile, we could get a lot more mileage from de-centralised approaches. Ideas I saw in this thread that sound attractive to me are to make Hackage display, for each package: - date of last update - download statistics - some kind of voting scores, so users can vote for good packages (and add text comments, please) - auto-build system, so that there's a per-platform indication of whether the package builds; ideally, packages should come with a test suite, which could be run too (Is this list complete?) Those are the major things I think. No Google page rank-alike? I did a quick popularity count by wget'ting the whole thing, and looking for hrefs under cgi-bin/packages/archive¹. Not exact, as it counts links to the previous version, but a rough approximation. Page rank would be better, as it would ascribe higher importance to a library that is required by a more popular library. Anyway, quick and inaccurate results: 1 cabalrpmdeps 1 compression 1 dfsbuild 1 dfsbuild 1 EdisonAPI 1 exif-1 1 exif-3000 1 haxr-1 1 haxr-th-1 1 haxr-th-3000 1 hmarkup-1 1 hmarkup-3000 1 hscolour 1 hsql-mysql 1 hsql-odbc 1 hsql-postgresql-1 1 MonadRandom 1 packedstring 1 proplang 1 rss-1 1 rss-3000 1 Shellac-readline 1 vty 1 xslt 2 AGI 2 ALUT 2 anydbm 2 AppleScript 2 BerkeleyDB 2 BitSyntax 2 catch 2 chunks-2007 2 ContArrow 2 cpphs 2 csv 2 darcs-graph 2 debian 2 dsp 2 fastcgi-1 2 fastcgi-3000 2 ftphs 2 functorm 2 GLUT 2 GuiTV 2 harchive 2 hburg 2 HGL 2 hjs 2 hS3 2 HsHyperEstraier 2 HsSVN 2 hstats 2 IFS 2 infinity 2 IOSpec 2 libmpd 2 libxml 2 LRU 2 metaplug 2 monad-param 2 network-bytestring 2 NewBinary 2 parsedate 2 parsely 2 pointfree 2 ports 2 PostgreSQL 2 Ranged-sets 2 safecopy 2 selenium 2 Shellac 2 state 2 stream-fusion 2 strict 2 uniplate 2 Win32 2 X11-xft 3 alex 3 base64-string 3 fastcgi-3001 3 fgl 3 happy 3 haskelldb-hdbc 3 haxr-3000 3 HDBC-odbc 3 hsql-sqlite3 3 html 3 MaybeT 3 pqc 3 xhtml-1 4 Crypto-3 4 HDBC-postgresql 4 HPDF-0 4 HSH 4 HTTP 4 hxt 4 OpenAL 4 plugins 4 polyparse 4 readline 4 TypeCompose 5 gd 5 haskelldb-hsql 5 HTTP-Simple 5 iconv 5 pretty 6 Emping 6 encoding 6 GrowlNotify 6 hmp3 6 HsSyck 6 HTTP-3000 6 IndentParser 6 ipprint 6 logict 6 mime-string 6 monadLib 6 process 6 random 6 stringsearch 6 suffixtree 6 torrent-2007 7 cgi 7 cgi-3000 7 DeepArrow 7 HCL 7 stm 7 syb-with-class 7 tar 8 haskell-src 8 HDBC-sqlite3 8 hpodder-0 8 old-locale 8 TV 9 bencode 9 OpenGL 9 utf8-string 10 arrows 10 SDL 11 ConfigFile 11 dlist 11 hsql 12 bktrees 12 bzlib 12 directory 12 FileManip 12 Finance-Quote-Yahoo 12 haskelldb 12 hinstaller-2007 12 hpodder-1 12 hsns 12 hsSqlite3 12 numbers-2007 12 old-time 12 phooey-0 12 phooey-1 13 irc 15 cabal-upload 16 HPDF-1 17 hslogger 18 HaXml 18 HDBC 19 HUnit 20 HsOpenSSL 20 pandoc 20 regex-pcre 20 sessions-2007 20 xmonad 20 YamlReference 21 containers 21 Stream 21 unix-compat 22 template-haskell 23 zlib 24 array 24 X11-extras 25 gd-3000 26 MissingH 28 QuickCheck 28 xhtml-3000 31 time 32 Cabal 35 pcap 36 HTTP-3001 39 regex-posix 40 binary 40 regex-compat 41 X11 42 xmobar 43 bytestring 47 cgi-3001 52 regex-base 56 cabal-rpm 59 filepath 59 unix 101 haskell98 101 parsec 107 network 197 mtl -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Over-allocation
Gracjan Polak [EMAIL PROTECTED] writes: The problem is that my prog allocates a lot just to free it immediatelly after. But what? Use +RTS -hd instead, which will tell you the constructor. I bet you'll find it's (:), and that you are retaining a load of Chars from your input file, pending evaluation of the elements from your map. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Over-allocation
Gracjan Polak [EMAIL PROTECTED] writes: I tried both Map and IntMap and there was no difference in memory total usage or usage pattern. Seems I'm already strict enough. This only proves Map and IntMap are equally strict, or in other words, they are both lazy in the elements. Values are left lazy till the point where they are forced, and that is at write-out in my current excersise. I'd want to leave them lazy as in more involved transformation not all of them will be needed. Then you get the memory behavior you ask for. Unevaluated strings are extremely expensive, something like 12 bytes per char on 32 bit, twice that on 64 bits, and then you need GC overhead, etc. ByteStrings are much better, but you then probably need to implement your own XML parsing. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
David Menendez [EMAIL PROTECTED] writes: Someone in a previous thread made an analogy between GHC and the linux kernel. I imagine that third-party Haskell distributions, consisting of GHC/Hugs/whatever and some bundled packages, would meet the desire for a batteries included Haskell implementation without tying the most popular libraries to GHC releases. Well - the various Linux distributions certainly could do this - providing a virtual haskell-libs package that just pulls in a bunch of commonly used packages. It'd be nice, of course, if that package was reasonably consistent across distributions, and if there were a corresponding installer for those other operating systems. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] expanded standard lib
Duncan Coutts [EMAIL PROTECTED] writes: I did a quick popularity count by wget'ting the whole thing, and looking for hrefs under cgi-bin/packages/archive¹. That's quite fascinating. Thanks. You've convinced me we should add something like that :-). Note that that was only a direct count, I haven't implemented a real library rank. Please file a feature request: http://hackage.haskell.org/trac/hackage/ This okay? http://hackage.haskell.org/trac/hackage/ticket/183 -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New slogan for haskell.org
Thomas Schilling [EMAIL PROTECTED] writes: Haskell is a general-purpose, pure functional programming languages that puts many interesting results from research into a practical programming language. It's features include: * Static typing with type inference: enables writing robust and fast programs quickly and makes large code bases maintainable. [..] I like this approach: list buzzwords with a brief explanation, and a rationale for why this helps you develop robust and efficient programs quickly. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] St. Petersburg Game
[EMAIL PROTECTED] writes: increment b = b + 1 This is also called 'succ' (for successor). main = dolet b = 0 let c = randomRIO (1,2) until (c == 1) increment b return b ERROR StPetersburg.hs:8 - Type error in application *** Expression : until (c == 1) increment b *** Term : c == 1 *** Type : Bool *** Does not match : Int - Bool Prelude :t until until :: (a - Bool) - (a - a) - a - a So until wants a function from a something to a boolean, but you are giving it (c==1) which is just a boolean. More generally, I think you should solve this in a more functional style, perhaps using randomRs to get a list of coin tosses, and take what you need from that. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Collections library
Ben Franksen [EMAIL PROTECTED] writes: PS (completely off-topic, sorry): I've been using the collections library throughout the project I must say it is a lot nicer to work with I tried to Google for this, and ended up at http://hackage.haskell.org/trac/ghc/wiki/CollectionClassFramework The only link that seems to work is the one that is marked as outdated. I've replaced them with a link to Hackage, but somebody who knows more about this might want to recheck the facts on the page. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and DB : giving up
Don Stewart [EMAIL PROTECTED] writes: And it reminds me to release the galois sqlite3 bindings, which do happily work with 6.8. Surely one of the other 15 haskell db bindings would also work. I think this is the problem, not the solution. There is a lot of DB libraries, just like there are a multitude of XML libraries, several collections, etc. Too many libraries are written as research projects or by grad students, and left to rot after release. The fragmentation also means that few libraries see any extensive testing - I was a bit surprised that apparently none of the XML libraries can handle files larger than a few megabytes, for instance. You're probably right that one of them would work, but especially new users will have no way of knowing which one. Only after the user has given up do people post similar experiences. This is getting better, of course - hackage will grow usage and activity statistics and perhaps ratings, the wiki will be extended with recommendations, more people will get involved in development. But at the moment, this is a problem. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New slogan for haskell.org
Yitzchak Gale [EMAIL PROTECTED] writes: Guido is clearly not rejecting functional influences on Python, he is supporting them. But he feels that these specific instances do not fit in. I read some of his statements, and find that I disagree vehemently. But I wonder if partial evaluation is contributint to this? GvR thinks list comprehensions are better than map or filter, and wants nested functions instead of lambda. So where I like to write filter odd or(\xs - (filter odd xs, filter even xs)) he would prefer let filter_odd xs = [ x | x - xs, odd x ] in filter_odd and let map_even_odd xs = let filter_odd ys = [ y | y - ys, odd y ] filter_even ys = [ y | y - ys, even y ] in (filter odd xs, filter even xs) in map_even_odd I hope I'm not misrepresenting the Python way here, but it feels incredibly clunky. Maybe it looks better in Python? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell interface file (.hi) format?
Claus Reinke [EMAIL PROTECTED] writes: you might find it easier to use GHCi's :browse command While ghc -e works, this no longer work within GHCi? Prelude :b Control.Concurrent.MVar module 'Control.Concurrent.MVar' is not interpreted -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast Array operations: foldl, drop
Bryan O'Sullivan [EMAIL PROTECTED] writes: For higher dimensions, there are enough options in terms of traversal direction and what exactly e.g. a fold should fold over (single elements? lower-dimensional slices?) that a sensible API doesn't exactly leap out. How about a 'reduce' instead of 'foldl1'? I think that if you require a commutative operator, the order doesn't matter (except for efficiency and possible rounding issues, I guess). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Progress indications
Andrew Coppin [EMAIL PROTECTED] writes: (BTW, what's the difference between unsafePerformIO and unsafeInterleaveIO?) Prelude :m + System.IO.Unsafe Prelude System.IO.Unsafe :t unsafePerformIO unsafePerformIO :: IO a - a Prelude System.IO.Unsafe :t unsafeInterleaveIO unsafeInterleaveIO :: IO a - IO a The former lets you cheat by pretending an IO action is a pure function, the latter, which really should be called 'notQuiteAsUnsafeInterleaveIO', just makes a strict IO action lazier, deferring it to when the result is demanded. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible Improvements
Johan Tibell [EMAIL PROTECTED] writes: It would be great if someone could exemplify these rules of thumb, e.g. Primitive types such as Int should be strict unless in the three canonical examples X, Y and Z. My strictness radar is still quite poor and I feel I can't make informed decisions on when I need to make something more strict or lazy. I find that I often need to add strictness when: left thumb) parsing [Char] into something more compact, i.e. almost all cases. right thumb) storing data into maps, especially when the values are produced by multiple updates - i.e. doing word frequency counts. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Graph theory analysis of Haskell code
Tim Chevalier [EMAIL PROTECTED] writes: aka a call graph. This is called control flow analysis and the classic paper on it is Olin Shivers' dissertation This is very well-trodden ground, but if you familiarize yourself with the literature on the subject, then who knows, you may discover something new. I'll just add that having a tool visualizing this would be very useful for refactoring code. If you e.g. use color to distinguish nodes/functions from different modules, you could use that information to decide to merge or split modules to minimize external interfaces. You could also try to automatically cluster nodes, which would be more interesting theoretically, but IMO less likely to be practical. Another option would be to couple this with profiling or coverage information to visualize something about the usage of paths and nodes in the call graph. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Pattern matching error
Philip Weaver [EMAIL PROTECTED] writes:
You'll find that the pattern that it's failing to match is:
[('b',[5,4]),('b',[1]),('b',[6])]
You could also use ghc with -Wall, which will tell you exactly which
cases you've omitted.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Daniel Fischer [EMAIL PROTECTED] writes: IO is important because you can't write any real program without using it. Ouch! I get awfully discouraged when I read statements like this one. I think Lennart was referring to that, you HAVE to know a little IO to write programmes, at least getArgs, getLine, putStr(Ln), readFile, writeFile, appendFile. And therefore some use of the IO monad has to be taught relatively early. Well, I guess you could get pretty far using 'interact' - far enough in an educational setting to do lists and Maybe, and then monads, before introducing monadic IO. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is a bad example for Monads
Dan Piponi [EMAIL PROTECTED] writes: The question isn't Does Haskell need quickdirty hackers? It's would we get better software (using your favourite metric) if we put Haskell into the hands of quick and dirty hackers?. I think the answer might be yes. This is an interesting trade-off: if we suppose that the most enterprising and creative (i.e. talented) [language] hackers are most susceptible to be lured over to Haskell, this strategy will increase the average quality of software overall, while simultaneously decreasing the average quality of code in both languages! Note also that there are many classes of people who fit the quick and dirty category. Encourage them to learn Haskell and only be quick. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [OT] A nice organized collection of threads in Haskell-Cafe
Vimal [EMAIL PROTECTED] writes: Vimal wrote: What is the difference between In-Reply-To and References? There was a time In-Reply-To was for emails and References was for Usenet. My friend wrote a parser for Haskell-cafe messages from the mailman archives as suggested. One place to look for example threading code is in the Gnus news/mail client for Emacs. Works fairly well, and is (was, when I looked at it briefly ages ago) not too complicated, and in elisp, which is not quite entirely an unfunctional language. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: -threaded
Simon Marlow [EMAIL PROTECTED] writes: Concurrency is supported just fine without -threaded. You need -threaded if you want to: : 3) write a multithreaded Haskell library or DLL I thought -threaded (A.K.A. -smp, no?) only affected which runtime was used, and thus was a linking option. I do have a library that needs -smp, but as far as I knew, the onus would be on the *applications* to specify this when compiling/linking. Is that incorrect? Is there a way for a library to inform the application about this? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] type classes
Lutz Donnerhacke [EMAIL PROTECTED] writes: * Peter Padawitz wrote: I'd like to define several instances of the same type class with the same type variable instance. Only method instances differ. How can I do this without writing copies of the type class? Define the type class in a module named MyClass. Define the each instance in a module named MyInstanceX where X is a version number. Include only the MyInstanceX module, you currently need. Or, if you need more than one at the same time, wrap your data type in one newtype per instance. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OOP'er with (hopefully) trivial questions.....
Nicholls, Mark [EMAIL PROTECTED] writes: After many years of OOP though my brain is wired up to construct software in that ?pattern??.a problem for me at the moment is I cannot see how to construct programs in an OO style in Haskell?.I know this is probably not the way to approach it?but I feel I need to master the syntax before the paradigm. Mostly, you'd use an algebraic data type. I.e. data Shape = Square Int | Rectangle Int Int | Circle Int area :: Shape - Int area (Square x) = x^2 area (Rectangle x y) = x * y area (Circle r) = pi*r^2 -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OOP'er with (hopefully) trivial questions.....
Thomas Davie [EMAIL PROTECTED] writes:
Yes, and you can indeed do a similar thing in Haskell. The natural
thing to do here would be to define a type Shape...
data Shape = Circle Int
| Rectangle Int Int
| Square Int
If however, you *really* want to keep your shapes as being seperate
types, then you'll want to invoke the class system (note, not the same
as OO classes).
class Shape a where
area :: a - Int
newtype Circle = C Int
instance Shape Circle where
area (C r) = pi * r^2
There's a third way, too, and I haven't seen anybody mention it yet
(apologies if I just missed it). You can provide an explicit record
of the relevant member functions, and instantiate it in different
ways. E.g.
data Shape = Shape { area :: Int }
square x = Shape (x^2)
rectangle x y = Shape (x*y)
circle r = Shape (pi*r^2)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OOP'er with (hopefully) trivial questions.....
Miguel Mitrofanov [EMAIL PROTECTED] writes:
I've noticed it, but there are some problems with this
representation, so I decided not to mention it. It's OK as far as we
don't want functions working on two areas - I don't see, how we can
implement, say, intersect :: Shape - Shape - Bool in this way.
However, it's a useful pattern.
Yes, there are different trade offs, it depends what you want to do.
The AlgDT makes intersect simple:
intersect :: Shape - Shape - Bool
intersect (Circle x) (Circle y) = ...
intersect (Circle x) (Rectangle x y) = ...
:
As Derek hints at, this isn't so nice in C++ and friends, you probably
will end up with
// Apologies for any mistakes in the code, it's been a while.
class Circle : public Shape {
:
bool intersect(s){
if(dynamic_castCircle(s)){...}
else if (dynamic_castRectangle(s)){...}
:
}
}
etc. In addition to being very verbose and tedious code to write, you
will have no idea if you have managed to cover all cases. Your
'intersect' function is spread all over the place.
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New to Haskell
Cristian Baboi [EMAIL PROTECTED] writes:
Here is some strange example:
module Hugs where
aa::Int
aa=7
Small note, it's common to use spaces around the :: and = I've
never really noticed before.
cc :: (Int-Int) - (Int-Int-Int) - Int - (Int-Int)
cc a op b = \x- case x of { _ | x==aa - x+1 ; _- a x `op` b }
What I don't understand is why I'm forced to use guards like x==aa in
cc, when aa is clearly bounded (is 7)
I don't quite understand what you mean. You don't have to use guards,
the function could equally well have been written using if-then-else.
Why not
cc a op b x = if x==aa then (x+1) else a x `op` b
Oh, wait, you're asking why you can't write
case x of aa - x+1
_ - a x `op` b
The answer is that case introduces a new binding for 'aa', so the
above is equivalent to
let aa = x in x+1
Case is really for deconstructing values with pattern matching, a
simple variable like aa (or _) will match any pattern.
f::Int-Int
f(1)=1
f(2)=2
f(_)=3
You can drop the parentheses here.
g::Int-Int
g(1)=13
g(2)=23
g(_)=33
h :: [Int-Int] - Int - Int
h [] x = x
h [rr] x = let { u=Hugs.f ; v=Hugs.g } in case rr of { u -
Hugs.g(x)+aa ; v - Hugs.f(x)+aa ; _ -rr (x) + aa }
h (rr:ll) x = h [rr] x + h (ll) x
Same here, if I understand you correctly. The case introduces new
bindings for u and v. Note that you can't (directly) compare
functions for equality either, the only way to do that properly would
be to compare results over the entire domain. (f == g iff f x == g x
forall x)
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New to Haskell
Cristian Baboi [EMAIL PROTECTED] writes:
I mean anything that you can put between { }, and between ;
Okay, there you have it then: the syntax for a block is a {, followed
by elements separated by ;s and terminated by a }.
Perhaps you are really asking about how the layout rule works? (Which
has already been answered, btw.)
Is this ([1 ,2 ,3 ,4]) a tuple or what ?
It has commas in it!
Good observation. Lists also have commas in them, and strings can,
too. ,,, is not a tuple, either. A tuple would have a (, and
subexpressions separated by commas, and terminated by ). The
subexpressions would need to be maximal, and have no superexpression
except the tuple.
I must admit I don't understand why you find this difficult, I've had
my share of problems grokking Haskell, but tuple syntax has always
seemed quite natural.
- the fact that lambda expressions are not the same thing
as algebraic data values
It might help to know why you think they might be the same;
the syntax is different and the name is different...
Ah, just a thought, nothing more.
Lambda expressions are values, which is just data, after all.
Yes.
Even C can apply a function variable to an argument (function pointers).
Would you say that functions and structs in C are the same thing
because of this?
This is a fundamental property of the language. A lambda
expression is programme and at runtime the system doesn't
know one lambda expression from another (all it can do with
one is apply it to something).
Even C can apply a function variable to an argument (function pointers).
What make Haskell different beside the lazy evaluation and mutable
variables things ?
Referential transparency? But if you are happy about how C can print
functions, perhaps you want to do:
instance Show (a - b) where
show x = A function
Main show (+)
A function
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: New to Haskell
Miguel Mitrofanov [EMAIL PROTECTED] writes: Well, LISP can [print functions], if I remember it right. Only in an interpreter, if I remember it right. I think Emacs used to print #function or something for functions. It seems to keep around the reresentation now. Anyway, LISP has a bunch of different equalities (at least: =, eq, eql, equal), so there are clearly different trade offs. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to make Prelude.read: no parse more verbose ...
Georg Sauthoff [EMAIL PROTECTED] writes:
Well, how do I compile a Haskell program in such a way, that I
get a useful error message from read? I mean, like the
filename/linenumber of the calling expression for starters.
It's dirty, it's mean, but you can use CPP. (On one line, and with
ghc -cpp):
#define read (\s - case [ x | (x,t) - reads s, (,) - lex t] of
{ [x] - x ;
[] - error(read: no parse at ++__FILE__++:++show __LINE__);
_ - error(read: no parse at ++__FILE__++:++show __LINE__)})
-k
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Doing some things right
Don Stewart [EMAIL PROTECTED] writes: A Wake Up Call for the Logic Programming Community http://www.cs.kuleuven.ac.be/%7Edtai/projects/ALP//newsletter/dec07/content/Articles/tom/content.html Interesting read! Clearly, the logic programming people are vastly more successful at our prime goal: avoiding success at all costs. We have much to learn here :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Doing some things right
Andrew Coppin [EMAIL PROTECTED] writes: http://www.cs.kuleuven.ac.be/%7Edtai/projects/ALP//newsletter/dec07/content/Articles/tom/content.html Haskell is the undisputed flagship of the FP community. Er... really? It depends on how you define the FP community, of course. The author counts participation at ICFP, so he probably has an academic slant. I thought Lisp and Erlang were both infinitely more popular and better known. Certainly not infinitely. Lisp isn't entirely functional, and while Erlang is an industrial success story, I think Haskell is seeing a wider range of application. [I actually heard a number of people tell me that learning LISP would change my life forever because LISP has something called macros. The close ties between data and code in Lisp gives some nice opportunities for your program to e.g. manipulate itself. For e.g. genetic programming. I think macros are used for bottom-up design (i.e. building EDSLs), where you would use higher-order functions in Haskell. (I don't really have a lot of Lisp experience, I'd be interested to hear if other people agree or not) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell-cafe reply-to etiquette
Albert Y. C. Lai [EMAIL PROTECTED] writes: B. This mailing list sets the List-Post header: List-Post: mailto:haskell-cafe@haskell.org Progressive mail clients honour this, e.g., Evolution. Thus you are given three buttons: I'm rather tied to my MUA, and while I'm not complaining (and Gnus lets me conpensate for different practices on a list-by-list basis), it's really the list management software, mailman, that should allow individual subscribers to configure the headers. So for people unhappy with the current situation, you can either fix mailman, or, for extra credit, write a better replacement in Haskell :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Wikipedia on first-class object
[EMAIL PROTECTED] writes: I suggest that you read something on 'quantum computing'. I guess I should disclaim the rest of my post right away: I don't know much about quantum anything, beyond what I read in the newspapers. Sorry. But: Concerning quanta, the simulation of quantum processes on classical archi- tectures may be and usually is extremely inefficient. So inefficient that your simulation loses sense. You could raise the same argument for (digital) computers compared to brains - although my brain might be able to, it's not practical for it to do the computations performed even by simple computer programs. But the difference is quantitative and practical, not qualitative and theoretical. (Arguably, I know. I invoke Occam.) No classical system can compute, say, a Fourier transform in constant (in fact, infinitely small) time, quantum system do it (in a sense) constantly. If I understand correctly, a quantum computer might solve problems in NP in polynomial time, which is assumed not to be possible for deterministic computers. As far as I can tell, it doesn't imply the ability to compute anthing that wasn't computable before. Now if we can wrap up the topic of whether machines can think, next session we'll discuss whether ships can swim. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is there anyone out there who can translate C# generics into Haskell?
Peter Verswyvelen [EMAIL PROTECTED] writes: Well, it's a good habit in Haskell to move the most important parameter to the end of the argument list. See e.g. http://www.haskell.org/haskellwiki/Parameter_order. I must say I like these recommendations. As for the Data.Map examples, the parameter order was changed compared to the old FiniteMap, and I was sure there was some rationale given? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Quanta. Was: Wikipedia on first-class object
Derek Elkins [EMAIL PROTECTED] writes: I don't understand your point. We know what swimming is: floating and moving autonomously. You're the first one I've heard who would use the term 'swimming' for ships. (And to be pedantic, wouldn't you say that fish swim, except when they float?) The point - stolen from Dennet, I think -- is that it is not terribly relevant wheter machines can think or just, you know, float and move autonomously, forever voyaging through dark seas... For goodness sake, I have *REALLY* the impression that those guys who speak about computability of the Universe, Who is speaking about computability of the universe? This looks like a straw man to me. have the mentality of 18 century thinkers for whom the world was simple and mechanistic. Or even the mentality of people contemporary of Democritus, for whom everything reduced to some dance of atoms. Or a wave function for the Universe... So - your counterclaim is that something complex and mystic and incomprehensible cannot arise from the simple, tangible and understood? Perhaps my views are *so* 1980s, but not 18th century, I think. Why is it that we cannot design roads so that we avoid traffic jams? Don't we understand cars and asphalt? Quantum effects in the combustion engine, perhaps? More seriously, perhaps quantum enters into the equation in how the brain works, perhaps it is even necessary for thought. However, I get worried it's just another mystical mantra, a gratuitous factor that, lacking any theory about how and what it does, adds nothing to help understanding the issue. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Cristian Baboi [EMAIL PROTECTED] writes: I think it's a bug. Here is why: let f = (\x - x/0) in f 0 == f 0 Referential transparency say that f 0 must equal to f 0, but in this case it is not. :-) I think you are wrong. Referential transparency says that you can replace any occurence of 'f 0' with another expression of the same value, it does not say anything about the behaviour of (==). -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 0/0 1 == False
Yitzchak Gale [EMAIL PROTECTED] writes: In the semantic domain there is one bottom. In Haskell there are many expressions that represent bottom. One cannot test those for equality. If we are being pedantic, I can define data Foo = Foo instance Eq Foo where _ == _ = True (undefined :: Foo) == Foo -- True The result of a Haskell function applied to some arguments cannot be bottom. This function is bottom for any argument: f x = undefined I think you mean that they cannot be bottom if you want to compare them for equality. Yes. See above. What is the precise term for describing this? Structural equality? On the other hand, some bottoms are exceptions, you may be able to catch them and do something useful with them after all, no? How does that fit in? -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why purely in haskell?
David Roundy [EMAIL PROTECTED] writes: I just want to point out that unsafePerformIO is at the core of the (safe) bytestring library. As SPJ et al pointed out, this is crucial functionality, and is only unsafe if unsafely used. In Modula-3 modules using hacks must be explicitly marked as UNSAFE. See http://www.cs.purdue.edu/homes/hosking/m3/reference/unsafe.html Maybe this is also an option for Haskell? I don't think this is a good idea. I think the point is (should be) to mark functions unsafe when they may be unsafe to /use/, and not when they just make use of potentially unsafe functionality. It is perfectly reasonable to write safe (pure) code that uses unsafe ones. You just have to trust the author to get it right. I'd be curious as to how much of the Prelude would be marked unsafe if you had your wish... All of it? In the end it is all passed to GCC (or generates assembly), which is inherently unsafe. :-) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Tim Sweeney (the gamer)
Sebastian Sylvan [EMAIL PROTECTED] writes: Maybe I'm just lucky, but if we are still talking about the games industry I don't think this fits my experience of bosses. Games compete very much on performance, and we basically rewrite almost all of our code over a few years or so anyway Another thing is that having the next big game means an incredible amount of money - more than a Hollywood blockbuster, according to popular rumor. Many companies may be willing to take a risk on promising but immature technology in the hope that it will give them the advantage they need to deliver the next Halo (or whatever). Very competitive industry, large money involved, lots of software rewritten or developed from scratch. Sounds ideal. Any boss who insists on doing things the way they've always done it won't last long. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 0/0 1 == False
Achim Schneider [EMAIL PROTECTED] writes: You need to use the / operator, if you want to do floating-point division. Yes, exactly, integers don't have +-0 and +-infinity... only (obviously) a kind of nan. No, failure (exception, bottom) is different from NaN, which is just another value in the domain - admittedly one which behaves rather strangely. Said differently: I don't know a thing about floats or numerics. Perhaps it helps to think of floating point values as intervals? If +0 means some number between 0 and the next possible representable number (and similar for -0), it may make more sense to have 1/+0 and 1/-0 behave differently. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Wolfgang Jeltsch [EMAIL PROTECTED] writes: However, the fact that (0 / 0) == (0 / 0) yields False is quite shocking. It doesn’t adhere to any meaningful axiom set for Eq. Tough luck, but that's how floating point works, and what the numericalists know, and possibly even love (although I have my doubts). Sanitizing this behavior would make Haskell less usable for real-world numerical problems. As a compromise, what about an option to make NaN (and presumably the infinities) cause an immediate exception? (And, cetero censeo, exceptions for Int overflow as well.) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
Ketil Malde [EMAIL PROTECTED] writes: The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I'll expand a bit of this, after I've checked with Wikipedia. Please correct me (and it) if I'm wrong, but: 1) Intel CPUs generate exceptions, not NaNs (unless a NaN is already involved), so NaNs are introduced by choice in the run-time system. 2) IEE754 supports both 'signaling' and 'quiet' NaNs, so it seems the standard is not blessed in this regard. And, in Haskell, I'd consider using NaNs for missing values slightly abusive of the system, this is just a poor man's way of spelling Maybe Double. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] writes: The difference between you (and/or Wolfgang J.) and myself is that I enjoy more my freedom, even if I have to pay with a little more work. You want to enforce rigid reactions of the system. You should be free to do it on *your* machine, not on mine. You are putting words in my mouth! I do not want to enforce rigid reactions on the system, I want the option to enforce them on my programs. As I said, the exceptional treatment of exceptional values might be a compilation option, as it was in some Fortrans I used long time ago. *I* proposed a compile-time option, *you* responded that it is a blessing NOT to have it. You want your programs to react histerically to all difficulties in math, since you are afraid of propagating NaNs, etc. If you consider halting execution to be a hysterical reaction, arithmetic errors to be all difficulties in math, and wishing for accurate error messages to be afraid, I guess the answer is 'yes'. And *then* you will have to sit down and correct your code. If there is no exception, your program may run happily, and produce rubbish, yes? Yes. I am more conservative. If you are afraid of rubbish, protect your code by appropriate checks *before* the errors occur. I've written a bit of checking code in my time. The problem is that you quickly end up with more checking code than 'real' code, that the checking code paths are rarely used, and thus even more bug prone than the rest of the code, and that usually, there is little you can sensibly do other than halt execution anyway. The nice thing about checking for integer overflow and arithmetic exception is that they can be added with no cost in code size or complexity, and (at least on some architectures) no cost in performance - perhaps even improvements, for signaling NaNs. My Haskell programs tend to be rather Spartan, and I think this makes them more readable, and thus more likely to actually be correct. What you call a sabotage I.e. the insistence on wrap-around Ints (a minority use case!) and quiet NaNs as the One True Way, disallowing all other approaches. I call the programmers negligence. I'll pleade guilty to the charge of being negiligent and not checking intermediate results for errors and overflows. But the only reason for using Int (and not Integer) and arguably floating point, is performance. Wrapping everything in checks will be laborious, and I am fairly certain that performance will suffer by magnitudes. So yes, I am lazy, I use Int and cross my fingers. (I'm not alone; I've read a fair bit of Haskell code (starting with the Prelude), I must just have been unfortunate to miss all the code written by the industrious and serious people who actually check their Int operations...) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why purely in haskell?
[EMAIL PROTECTED] writes: People, you are monsters. Well, bring on the torches and the pitchforks (although the image in my mind is more like a mob carrying lenses and bananas). no, some users are victims of its success as a formal language, not just as a coding tool I think Haskell's theoretical basis is part of its success as a coding tool. ... They *want* to have Eq as they imagine the equality, including the comparison between incomparable. In an ideal world, yes, but I think the monster to which you respond was fairly clear on being 'practical' here? The bombing of NaN *might* be a profound compilation option, but for people who really do numerical work, this is a blessing NOT to have it. I don't understand this. Are you worried users will edit the language pragmas in your code, and complain about NaN errors? Back when I *was* using the abbreviation FP for 'Floatin Point', I often got NaNs due to programming errors. Given the NaN's nature of contaminating subsequent results, getting an exception at the first occurrence would aid in tracking it down. - Ignoring Int overflow is a cheap way of having `mod` (MAXINT+1). Useful for many purposes. ...and ditto for this. The usefulness of one case in no way justifies sabotagin all other cases. I'd wager Ints see wider use in settings where the silent 'mod' is harmful, than where this effect is desired. Again, the current behavior causes errors that are very hard to track down. IMHO, these are two very different types, and I'm sligtly baffled that the fact is not reflected in Haskell. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First time haskell - parse error!
S. Doaitse Swierstra doai...@cs.uu.nl writes: then (s1 ++ s2 ++ s3 ++ s4) where s1 = Golds s2 = show (gold s g) s3 = , Silvers s4 = show (silver s g) If you want to keep the definitions local to the expression you should write ..but I think it is better style to avoid this kind of one-off named values. I much prefer: then Golds ++show (gold s g)++... For some reason, this is a style isse that doesn't get much attention, at least not in the non-functional language tradition, where temporary variables are scattered all over. So instead of doing: let ns y = not (isSpace y) f x = takeWhile ns x in map f We can use anonymous functions in place of the uninformatively named ones: map (\x - takeWhile (\y - not (isSpace y)) x) and use partial application toward point-free-ness: map (takeWhile (not . isSpace)) which IMO is a lot easier to read, taking up less screen and mind estate. Of course it's possible to overdo the point-free thing (commonly referred to as pointless), but I think it's great when you can eliminate gratuitous naming like this. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First time haskell - parse error!
Miguel Mitrofanov miguelim...@yandex.ru writes: Maybe it's just me, but I think composition chain is MUCH easier to read. I definitely agree. [Cited from Learn You a Haskell for Great Good] oddSquareSum :: Integer oddSquareSum = sum . takeWhile (1) . filter odd . map (^2) $ [1..] oddSquareSum :: Integer oddSquareSum = let oddSquares = filter odd $ map (^2) [1..] belowLimit = takeWhile (1) oddSquares in sum belowLimit To me, the first one is very clear, and exposes the function as what it is: a neat, linear pipeline of standard function applications. You don't have to be a very seasoned programmer to quickly identify this structure, or the components involved. Introducing names means that I need to keep the temporary definitions in my head, and I think takeWhile (1) is as clear as it can get. And while a name can be misleading (belowLimit is a boolean, no?) or flat out wrong, the definition has its semantics¹. Another, perhaps graver issue, is that the names obscure the linearity of the function. I now need to check that the temporary defintions don't recurse or perform other tricks.² Named values are just like comments, which IMO also should be kept to a bare minimum. A bit tongue in cheek: If you need a name to understand what a function does, or a comment to understand how it does it, then your code is too complicated. -k (who still doesn't name all his functions 'foo') ¹ Which are perhaps not-so-defined. Thanks for bringing it up. ² There are plenty of point-free examples that overload my mind -- I wonder if this might be when you start to linearize non-linear structures, composing dots and combinators and whatnot? -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Naming and coding style (was: [Haskell-cafe] First time haskell - parse error!)
Colin Adams colinpaulad...@googlemail.com writes: Named values are just like comments, which IMO also should be kept to a bare minimum. A bit tongue in cheek: If you need a name to understand what a function does, or a comment to understand how it does it, then your code is too complicated. Tongue-in-cheek? It's completely ridiculous. I'm not saying that you shouldn't name things - just that you shouldn't add names as a remedy for incomprehensible code. Especially when you can instead write clear code in the first place. E.g. I don't need a name for \n - n `mod` 2 == 1 to understand what it does. And especially in this case, naming otherwise clear code fragments just introduces a layer of indirection, which add more opportunities for errors and misunderstandings. That example above has six names in it. And they are named because they represent common idioms that are used all over the place, and so labeling and memorizing them improves clarity and reusability, and since they are from the standard library, I can expect them to be reasonably correct and efficient. Here's another one for you: never introduce names if it increases the size of your program. (Corrolary: don't name things that aren't referred to at least twice) -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] First time haskell - parse error!
Sebastian Fischer s...@informatik.uni-kiel.de writes: I do not agree that introducing names locally for compositions is *always* a bad idea, even if used only once. Well, of course I do that all the time too. :-) (Choosing names that are misleading or flat out wrong is of course always a bad idea.) Of course nobody actually does this on purpose, but like comments, names tend to bit-rot over time as code gets updated, but names or comments stay the same. Also, good names are harder than they sound: I don't think 'belowLimit' is a good name for 'takeWhile (1)', for instance. I certainly couldn't guess what it was for without looking at the implementation, which kind of defeats the purpose of names for improving code clarity, don't you think? And what's a good name for the associative monoid operator again? Named values are just like comments While you wanted to degrade named values by this statement I think it can serve as justification. It does cut both ways, I suppose :-) With the names in the rewritten example this comment is no longer necessary. I'm not so sure - the names just try to put meaningful labels on the internals of 'oddSquareSum', while the comment refers to the whole function, and it can be picked up by haddock, so there are other considerations. Good names can help making comments less important. OTOH, comment can give you the best(?) of both worlds, both revealing the linear structure of the function, while still providing extra information: oddSquareSum :: Integer oddSquareSum = sum -- add together . takeWhile (1) -- until a value 10K is seen . filter odd -- all the odd . map (^2)-- squares of $ [1..] -- natural numbers -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
