Re: [Haskell-cafe] Proof of a multi-threaded application
Tim Docker [EMAIL PROTECTED] writes: My apologies for side-tracking, but does anybody have performance numbers for STM? I have an application waiting to be written using STM, boldly parallelizing where no man has parallelized before, but if it doesn't make it faster, Faster than what? Faster than an equivalent non-concurrent program. It'd also be nice if performance was comparable lock-based implementation. Are you considering using STM just to make otherwise pure code run in parallel on multiple cores? No, I have a complex structure that must be updated in non-predictable ways. That's what STM is for, no? -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] implementing python-style dictionary in Haskell
Tillmann Rendel [EMAIL PROTECTED] writes: Why should a Haskell hash table need more memory then a Python hash table? I've heard that Data.HashTable is bad, so maybe writing a good one could be an option. One problem is that Haskell collections are lazy by default. I'm aware of a few use cases where laziness lets you formulate a very elegant recursive population of a collection, but I think that in general, strictness is what you want, and further, that if you want lazy, you store your data as one-tuples: data Lazy a = Lazy a (If there's a workaround/solution in the other direction, I'd really like to hear it). I'm therefore tempted to suggest that collections should be strict by default, and in particular, that there should be strict arrays for arbitrary types, not just the ones that happen to be unboxable. Unboxing should be an optimization for (some) strict arrays. -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] Windows vs. Linux x64
Bartosz Wójcik [EMAIL PROTECTED] writes: while working on my resent project I've noticed that my code seems to be faster under Windows than under Linux x64. Is Windows running in 32 bit? What gcc versions are you using on each system? Windows is 32 bit with GHC-6.8.3. Linux is 64 bit with GHC-6.10.1. This corresponds to my experiences - 64 bits is slower, something I've ascribed to the cost of increased pointer size. -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] workarounds for Codec.Compression.Zlib errors in darcs
Jason Dagit [EMAIL PROTECTED] writes: That is, if you use the optional specification of a header file for each foreign import, and if your Haskell compiler can compile via C, then any checking that types match between Haskell and C can be performed automatically, by the backend C compiler. Would this method work with return types since C compilers tend to let you ignore those? In this example that brought up this discussion it was in fact an ignored return value that caused the problem. I've tried to look at GCC's warning options, but couldn't make it emit a warning on an ignored result. (Doesn't mean it isn't in there, of course) -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] Windows vs. Linux x64
Bartosz Wójcik [EMAIL PROTECTED] writes: Win32 Core2Duo 1.8GHz 1GB RAM 17 Mb total memory in use MUT time 56.97s ( 57.02s elapsed) %GC time 0.5% Win32 Core2Duo 2.2GHz 2GB RAM 17 Mb total memory in use MUT time 57.44s ( 57.53s elapsed) %GC time 0.7% (0.8% elapsed) So, despite the CPU being 25% faster, it's exactly as fast. Memory bound? Win32 P4 2.8GHz 1GB RAM 17 Mb total memory in use MUT time 171.64s (175.78s elapsed) %GC time 1.7% (1.5% elapsed) You're doing divisions, and I seem to remember division being an operation that wreaked havoc with the P4's ALU or trace cache, or something like that. Linux64 Core2Duo 2.2GHz 2GB RAM 41 MB total memory in use (1 MB lost due to fragmentation) MUT time 68.26s ( 68.92s elapsed) %GC time 0.9% (1.1% elapsed) Linux32 Core2Duo 2.3GHz 4GB RAM 17 Mb total memory in use MUT time 51.77s ( 51.83s elapsed) %GC time 0.5% (0.6% elapsed) Interesting that Linux32 is actually faster than Win32. Different cache sizes? -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] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8
Galchin, Vasili [EMAIL PROTECTED] writes: I think I am getting a namespace collition between Data.ByteString.Lazy.Char8.ByteString and Data.ByteString.Lazy.Internal.ByteString You rarely need to import 'Internal' directly. here is the error message Couldn't match expected type `B.ByteString' against inferred type `bytestring-0.9.0.1:Data.ByteString.Lazy.Internal.ByteString' Are you sure this is not just a versioning problem? I.e. that some library is built against bytestring-0.X.Y, but your current import is bytestring-0.A.B, but your program expects these to be the same? (And they probably are, but the compiler can't really tell). -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] Data.ByteString vs Data.ByteString.Lazy vs Data.ByteString.Char8
Galchin, Vasili [EMAIL PROTECTED] writes: Warning: This package indirectly depends on multiple versions of the same package. This is highly likely to cause a compile failure. package binary-0.4.2 requires bytestring-0.9.0.1 package bio-0.3.4.1 requires bytestring-0.9.1.0 ah ha .. Ketil, this is what you are saying? Yes, exactly. If so, how do I fix? install a newer version of binary? Just recompiling it against bytestring-0.9.1.0 would suffice. You really should anyway, bytestring-0.9.0.1 has a nasty performance 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] Haskell project proposals reddit
Jason Dusek [EMAIL PROTECTED] writes: I think you are overlooking the Web 2.0 aspect of this. I've been wondering what reddit brings to the table that makes it worth keeping track of yet another web site, registering yet another user account, learning yet another interface. Assuming you're not just being sarcastic about buzzword compliance, would you - or somebody else - care to elaborate a little bit what the advantage is 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] Time for a new logo?
Don Stewart d...@galois.com writes: I noticed a new haskell logo idea on a tshirt today, http://image.spreadshirt.net/image-server/image/configuration/13215127/producttypecolor/2/type/png Simple, clean and *pure*. Nice. For some more hubris, replace 'A' with 'The'. -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] Time for a new logo?
J. Garrett Morris jgmor...@cecs.pdx.edu writes: Nice. For some more hubris, replace 'A' with 'The'. I had the very same thought :) It certainly wouldn't do to let, say, the existence of Concurrent Clean get in the way of our self-promotion. Well, they get to make T-shirts with Clean - the /other/ purely functional language. Seriously though - thet text can be interpreted as Haskell, the purely functional language to distinguish it from Haskell, the county in Texas, or Haskell, the Indian Nations Universityor for that matter Haskell, the logician. To avoid any hard feelings, I suggest either putting Haskell the logician (with a picture of same) on the back of the shirt, or replacing the text with just purely functional or similar. At any rate, A is to weak, and suggests just one of the crowd. -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] Time for a new logo?
Gianfranco Alongi gianfranco.alo...@gmail.com writes: I agree on what some people say; I see no point in trying to advertise elitism. For this reason, my favorite subtitle is pure . lazy . fun. Nice and friendly, with some doulbe meanings for the cognoscenti. (I'm sorry, but I can't bring myself to add simple in there with a straight face.) Is it an option to add a \tau to the \lambda? Especially if we go for the lambda in a circle theme - to differentiate from Half-life, Scheme, and other kids' stuff :-) -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: Time for a new logo?
George Pollard por...@porg.es writes: Might be interesting to try angling the ends of the stems to look something more like the guillemot in [1]. I might try this in Gimp but I'm no designer :P If you're on Linux or similar, I recommend Inkscape for this kind of thing. -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] Logos of Other Languages
Jules Bean ju...@jellybean.co.uk writes: So I agree with Ashley insofar as, there is no *need* for the logo to incorporate a lambda or a or suchlike devices. On the other hand, I think it's not necessarily a bad thing either, as long as it works with (1) and (2) above. I agree with this, but would also add that referring to foundations, history or theory (lambda) is better than referring to syntax (). I don't know if it was proposed as a serious option, but I quite like the idea of using _|_ as a symbol. -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] Use of abbreviations in Haskell
Isaac Dupree m...@isaac.cedarswampstudios.org writes: Derek Elkins wrote: I haven't been able to find any semantic difficulties with this addition. I like it too... what I run into is that there's an implicit assumption that module of name Foo.Bar.Baz *must* be found in a file Foo/Bar/Baz.[l]hs . Ah, surely mere practicalities will not stand in the way of improving the usability of the language? GHC uses this all the time ..unless you want a compiler, I guess. How about this: A module may be defined in a file with a name corresponding to the module name, or any dot-separated prefix of it? I.e. the file Foo/Bar.hs will define module Foo.Bar and optionally Foo.Bar.Baz as well? GHC should then be able to find it, and I believe it already has a prioritized search mechanism (presumably, the file could be named Foo.Bar.hs, too). -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] How to check object's identity?
Aaron Tomb at...@galois.com writes: As others have explained, the == operator doesn't tell you whether two values are actually stored at the same location in memory. Nobody yet mentioned that (==) doesn't guarantee *anything* - it's a user defined function. So while it may and should give structural equality, it also may 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: Literate Programming
"D. Tweed" [EMAIL PROTECTED] writes: Unfortunately the last time I looked at CWEB it still had the same idea about identifiers as WEB itself, namely that if they match textually they are the same, which makes the automatic indexes produced less useful for C++: I've got twelve classes all with a `read()' method plus any in [...] (Of course, the indexes only matter if like me you prefer reading hardcopy or work on trains, etc.) It would equally hurt cross-referencing, wouldn't it? Emacs' haskell-mode seems to have hard coded a few type signatures from the Prelude, and while probably useful, it'd be much more neat if it could work out what functions actually were referenced. (And not try to deduce types in comments!) Anyway, my problem with literate programming is that I don't really know what to put in there with the source code. Usage documentation? Explanations about implementation details? Tutorial and examples? I guess one reason the Perl documentation works so well, is that the target is clearly defined: man pages. -kzm -- If I haven't seen further, it is by standing in the footprints of giants
Re: Show, Eq not necessary for Num [Was: Revamping the numeric classes]
Brian Boutel [EMAIL PROTECTED] writes: The fact that equality can be trivially defined as bottom does not imply that it should be a superclass of Num, it only explains that there is an ugly way of working around the problem. There is nothing trivial or ugly about a definition that reflects reality and bottoms only where equality is undefined. I think there is. If I design a class and derive it from Num with (==) is bottom, I am allowed to apply to it functions requiring a Num argument, but I have no guarantee it will work. The implementor of that function can change its internals (to use (==)), and suddenly my previously working program is non-terminating. If I defined (==) to give a run time error, it'd be a bit better, but I'd much prefer the compiler to tell me about this in advance. Of course, if you do not need to apply equality to your "numeric" type then having to define it is a waste of time, but consider this: It's not about "needing to apply", but about finding a reasonable definition. - Having a class hierarchy at all (or making any design decision) implies compromise. I think the argument is that we should move Eq and Show *out* of the Num hierarchy. Less hierarchy - less compromise. - The current hierarchy (and its predecessors) represent a reasonable compromise that meets most needs. Obviously a lot of people seem to think we could find compromises that are more reasonable. - Users have a choice: either work within the class hierarchy and accept the pain of having to define things you don't need in order to get the things that come for free, Isn't it a good idea to reduce the amount of pain? or omit the instance declarations and work outside the hierarchy. In that case you will not be able to use the overloaded operator symbols of the class, but that is just a matter of concrete syntax, and ultimately unimportant. I don't think syntax is unimportant. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: A sample revised prelude for numeric classes
[EMAIL PROTECTED] (Marcin 'Qrczak' Kowalczyk) writes: Why do you stop at allowing addition on Dollars and not include multiplication by a scalar? Perhaps because there is no good universal type for (*). Sorry, it would have to have a different symbol. Is this ubiquitous enough that we should have a *standardized* different symbol? Any candidates? Having Units as types, with the idea of preventing adding Apples to Oranges, or Dollars to Roubles, is a venerable idea, but is not in widespread use in actual programming languages. Why not? It does not scale to more general cases. (m/s) / (s) = (m/s^2), so (/) would have to have the type (...) = a - b - c, which is not generally usable because of ambiguities. Haskell's classes are not powerful enough to define full algebra of units. While it may not be in the language, nothing's stopping you from - and some will probably encourage you to - implementing e.g. financial libraries with different data types for different currencies. Which I think is a better way to handle it, since when you want m to be divisible by s is rather application dependent. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Functional programming in Python
Manuel M. T. Chakravarty [EMAIL PROTECTED] writes: You want to be able to write f 1 2 + g 3 4 instead of (f 1 2) + (g 3 4) I do? Personally, I find it a bit confusing, and I still often get it wrong on the first attempt. The good thing is that the rule is simple to remember. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Functional programming in Python
Jerzy Karczmarczuk [EMAIL PROTECTED] writes: BTW, before I knew Haskell I exprimented with a syntax in which 'x f' is the application of 'f' to 'x', and 'x f g' means '(x f) g'. Hmmm. An experimental syntax, you say... Oh, say, you reinvented FORTH? Wouldn't x f g in a Forth'ish machine mean g(f,x) -- using standard math notation, for a change rather than g(f(x)) ? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: update in-place
Cagdas Ozgenc [EMAIL PROTECTED] writes:
Could you help me on this notation?
Perhaps?
data Foo = Foo { a :: Int, b :: String }
This declares a Foo constructor with two named fields, and Int a and
a String b. This is equivalent to declaring
data Foo = Foo Int String
but with a couple of extra features added, among others that
you automatically get defined functions a and b which take a Foo
object and return the values of the respective parts.
instance Show Foo where
show f = show (a f) ++ ++ show (b f)
...so the (a f) and (b f) parts are just extracting the relevant
information from the Foo.
If you know Lisp, it's fairly similar to defstruct.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: streching storage manager
Saswat Anand [EMAIL PROTECTED] writes: As regard to Marcin's suggestion of using a list of compact arrays, although elements can be accessed faster, there will be a lot if redundancy since windows are overlapping. So consecutive arrays will contain almost same data. Hmmm - a circular buffer array, fed from a lazy read? Of course, if this is to be more efficient than a lazy list of arrays, you need to destructively update the buffer. Perhaps this is a too Cistic solution. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: UniCode
Dylan Thurston [EMAIL PROTECTED] writes: Right. In Unicode, the concept of a character is not really so useful; After reading a bit about it, I'm certainly confused. Unicode/ISO-10646 contains a lot of things that aren'r really one character, e.g. ligatures. most functions that traditionally operate on characters (e.g., uppercase or display-width) fundamentally need to operate on strings. (This is due to properties of particular languages, not any design flaw of Unicode.) I think an argument could be put forward that Unicode is trying to be more than just a character set. At least at first glance, it seems to try to be both a character set and a glyph map, and incorporate things like transliteration between character sets (or subsets, now that Unicode contains them all), directionality of script, and so on. toUpper, toLower - Not OK. There are cases where upper casing a character yields two characters. I though title case was supposed to handle this. I'm probably confused, though. etc. Any program using this library is bound to get confused on Unicode strings. Even before Unicode, there is much functionality missing; for instance, I don't see any way to compare strings using a localized order. And you can't really use list functions like length on strings, since one item can be two characters (Lj, ij, fi) and several items can compose one character (combining characters). And map (==) can't compare two Strings since, e.g. in the presence of combining characters. How are other systems handling this? It may be that Unicode isn't flawed, but it's certainly extremely complex. I guess I'll have to delve a bit deeper into it. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
[Posted to haskell-cafe, since it's getting quite off topic] Kent Karlsson [EMAIL PROTECTED] writes: for a long time. 16 bit unicode should be gotten rid of, being the worst of both worlds, non backwards compatable with ascii, endianness issues and no constant length encoding utf8 externally and utf32 when worknig with individual characters is the way to go. I totally agree with you. Now, what are your technical arguments for this position? (B.t.w., UTF-16 isn't going to go away, it's very firmly established.) What's wrong with the ones already mentioned? You have endianness issues, and you need to explicitly type text files or insert BOMs. An UTF-8 stream limited to 7-bit ASCII simply is that ASCII stream. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. I can understand UCS-2 looking attractive when it looked like a fixed-length encoding, but that no longer applies. So it is not surprising that most people involved do not consider UTF-16 a bad idea. The extra complexity is minimal, and further surfaces rarely. But it needs to be there. It will introduce larger programs, more bugs, lower efficiency. BMP characters are still (relatively) easy to process, and it saves memory space and cache misses when large amounts of text data is processed (e.g. databases). I couldn't find anything about the relative efficiencies of UTF-8 and UTF-16 on various languages. Do you have any pointers? From a Scandinavian POV, (using ASCII plus a handful of extra characters) UTF-8 should be a big win, but I'm sure there are counter examples. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Unicode support
Kent Karlsson [EMAIL PROTECTED] writes: You have endianness issues, and you need to explicitly type text files or insert BOMs. You have to distinguish between the encoding form (what you use internally) and encoding scheme (externally). Good point, of course. Most of the arguments apply to the external encoding scheme, but I suppose it wasn't clear which of them we were discussing. But as I said: they will not go away now, they are too firmly established. Yep. But it appears that the right choice for external encoding scheme would be UTF-8. When not limited to ASCII, at least it avoids zero bytes and other potential problems. UTF-16 will among other things, be full of NULLs. Yes, and so what? So, I can use it for file names, in regular expressions, and in whatever legacy applications that expect textual data. That may be worthless to you, but it isn't to me. So will a file filled with image data, video clips, or plainly a list of raw integers dumped to file (not formatted as strings). But none of these pretend to be text! True. But implementing normalisation, or case mapping for that matter, is non-trivial too. In practice, the additional complexity with UTF-16 seems small. All right, but if there are no real advantages, why bother? I couldn't find anything about the relative efficiencies of UTF-8 and UTF-16 on various languages. So, how big is our personal hard disk now? 3GiB? 10GiB? How many images, mp3 files and video clips do you have? (I'm sorry, but your argument here is getting old and stale. Don't be sorry. I'm just looking for a good argument in favor of UTF-16 instead of UTF-8, and size was the only possibility I could think of offhand. (And apparently, the Japanese are unhappy with the 50% increase UTF-8's three-byte encoding over UTF-16's two-byte one) You could run the same argument against UTF-16 vs UTF-32 as internal encoding form, memory and memory bandwidth is getting cheap these days, too, although memory is still a more expensive resource than disk. But as (I assume) the internal encoding form shouldn't matter (as) much, as it would be hidden from everybody but the Unicode library implementor. It boils down to performance, which can be measured. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: = vs -
Mark Carroll [EMAIL PROTECTED] writes: On Tue, 9 Oct 2001, Ashley Yakeley wrote: At 2001-10-09 11:55, Mark Carroll wrote: What is the rationale for when Haskell demands a = and when it demands a -? Okay, I can't give you anything formal, but here's my intuitive understanding of things e.g. x :: Integer - Integer A function from and Integer to an Integer. Even more obvious if you have one more parameter: g :: Integer - Integer - Integer g takes an Integer and returns a function that takes an Integer and returns an Integer. Equals-assignment would be very non-intuitive here. I guess the same argument goes for lambdas \x - x*x maps *from* an x *to* its square. x 1 = 1 x 2 = 3 Function definitions use (=). I'm not sure I see any really compelling reason, except that it's the usual math syntax, and arrows would look weird, in particular with nullary definitions: c - 0 y a = case a of 1 - 1 2 - 3 z a | a == 1 = 1 | a == 2 = 3 It seems there's a predisposition for having exactly one (=) in function definitions. Perhaps one could have had a syntax like z a = | a == 1 - 1 | a == 2 - 3 instead, as it'd make it more consisten with the case, but I suppose there's a reason for it being the way it is. The case statement is an expression like any other, while I suspect the guards can only be used in function definitions like your 'z' example. By the way, if you read '=' as is assigned to, and '|' as where and '-' as gives, things mostly make sense, I think. (Note that there's also the back-arrow, used to draw from, e.g. in the IO Monad main = do x - readFile /etc/passwd putStr (map crack (lines x)) or list comprehensions primes = [ p | p - [2..], noDivides p primes] I suppose the difference from (=) assignment is reasonably clear.) Rambling on, -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Haskell-beginners problem with memory consuption
Petter Egesund [EMAIL PROTECTED] writes: I load my file in one chunk, and does a lot of substitutes on the string - this is quick eating all my memory and the computers start to get really slow. Keep in mind that Strings are lists of characters. I think (somebody correct me if I'm wrong) GHC will store a character inside a cons cell, but that still leaves 8 bytes per character. Worst case it will store the 8-byte cons cell pointing to a 32-bit char value, 12 bytes per character. (Strings as lists-of-char is very useful, but not terribly efficient). Using hGetArray to read into a UArray of Word8, or something like that, will probably be a lot faster and save a lot of space. The problem is of course that the string is copied each time I do a substitute As W.J. says, you should make sure that you don't keep more references to the original string than you need to, so that old stuff can be garbage collected. If you post (pieces of) the code, people may be able to point out improvements more easily. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: SV: Haskell-beginners problem with memory consuption
Petter Egesund [EMAIL PROTECTED] writes: fun :: String - String look for pat1 in string - if found subst with sub1 look for pat2 in string - if found subst with sub2 look for pat3 in string - if found subst with sub3 recurse until no pattern is found I would structure this as replace :: String - [String] - String replace input patterns = ... At each position of input, check for the presence of patterns (use isPrefixOf) and conditionally replace it, else output first char of input and recurse on input's tail. This should make the function online, so that it can be streamed over a large but lazy list (say a file read with readFile -- hurry up before Simon takes it away! :-) without explicitly constructing the whole input or output String. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Limiting resources on a per-function basis?
Jeff Newbern [EMAIL PROTECTED] writes: Thanks for your input. I am mainly interested in this functionality to enhance my unit tests. I want to be able to run test cases with limits on time, heap, stack, etc. and fail the test if it exceeds the limits. Well, if you can isolate the tests well enough (i.e. not run too many other parts of your program), you could possibly get by with GHC's options for limiting resources (for the whole program)? In particular the +RTS -K and -M options would be useful, see http://www.haskell.org/ghc/docs/6.2/html/users_guide/runtime-control.html#RTS-OPTIONS-GC for details. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: pet project - 7 Millennium Prize problemss
Christopher Milton [EMAIL PROTECTED] writes: I think Haskell can be used to solve several, if not all, of the seven problems. What's this? Is there an URL with more information? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Hi, I have a question!
Derek Elkins [EMAIL PROTECTED] writes: Either use a different name for your operator, or specify the + that you want by writing OperationTest.+ instead of +. You can also hide the Prelude (+), though it is a somewhat useful function. Wouldn't making Nat an instance of Num also work? instance Num Nat where -- the definition of (+) for Nat here -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] elemt from list
Pajo Patak [EMAIL PROTECTED] writes:
I want to return a list, from and list of lists (all integers), where
is the erroe in the code?
nthList :: [[a]] - Int - [a]
nthList ([x]:xs) 1 = [x]
nthList ([x]:xs) (n+1) = nthListh xs n
Did you try it at all?
Prelude let { nthList ([x]:xs) 1 = [x];
nthList ([x]:xs) (n+1) = nthListh xs n}
interactive:1: Variable not in scope: `nthListh'
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Outstanding context : (Num b, Random b)
horsh [EMAIL PROTECTED] writes: Could anyone please explain why these two things are not equivalent: One of them has a type signature? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ????Pattern match(es) are overlapped???
Arjan van IJzendoorn [EMAIL PROTECTED] writes: newtype Method = Method String getMethod = Method GET putMethod = Method PUT doMeth getMethod = ... doMeth putMethod = ... You will have to write: doMeth (Method GET) = ... doMeth (Method PUT) = ... Or (I assume, haven't tested) if you insist on renaming the methods: doMeth m | m == getMethod = ... | m == putMethod = ... (or using a case statement, of course) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie: Is it possible to catch _|_ ?
Russ Lewis [EMAIL PROTECTED] writes: Another newbie question: Is it possible to catch _|_ - that is, to encounter it, handle it and continue? Since _|_ is the value of a non-terminating computation, this requires you to solve the halting problem. GHC does occasionally detect loops, but for the general case, don't hold your breath :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie: Is it possible to catch _|_ ?
Russ Lewis [EMAIL PROTECTED] writes: Oh. I was figuring that the runtime would detect _|_ whenever evaluation requires that it calculate a given expressoin, and that expression is currently being evaluated...that is, some subset of an expression evaluates to the expression itself. You mean like in fibs = 1:1:zipWith (+) fibs (tail fibs) ? :-) Actually, (and more seriously) I suspect this is the kind of loop detection that makes GHC go Exception: loop (which you may be able to catch; I don't know the details since I just let my programs crash instead :-) Prelude let x = x Prelude x *** Exception: loop -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] WildCard question
Paul Cosby [EMAIL PROTECTED] writes: Every time I try to use [underscore] in an definition it says something like the symbol /017 is not recognised Could that be \017, i.e. octal 17 (defined in ASCII as SI, whatever that may be)? Any help suggestions? Wild guess: Are your files using the same character set as your Haskell system is expecting? I know Windows pulls some occasional stunts with the character set (and occasionally lies about it), but I wasn't aware that it affected underscore. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Re: sizeFM type
[Moved to -cafe at SPJ's request] Serge D. Mechveliani [EMAIL PROTECTED] writes: On Mon, Apr 26, 2004 at 10:09:18PM +0200, Ketil Malde wrote: Serge D. Mechveliani [EMAIL PROTECTED] writes: length :: [a] - Integer smallLength :: [a] - Int Hmm...isn't it possible to use a class here? Perhaps even Num? I think, for many functions, like length, it is most natural to return Integer only. Well, perhaps Integral is a better choice. I was perhaps thinking of functions like: average xs = sum xs / length xs I'd rather have a polymorphic length, than different versions for each possible return type. One problem could be that with average xs = sum xs / fromIntegral (length xs) the return type of length becomes ambigous? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: sizeFM type
S. Alexander Jacobson [EMAIL PROTECTED] writes: assuming Moore's law lasts I suspect Moore's law is dead or dying. Intel just announced the latest Prescott P4 at 3.6 GHz, up from 3.2 last June. That's only a 12.5% increase. One year before that, it was about 2.5GHz, or almost 30%. I didn't recheck, but I think that in the PII and PIII period, the increase was about 50% every year. Interestingly, none of the other chipmakers seem to be doing much better either. But apart from that, your points are valid. :-) -kzm PS: Okay, that was perhaps off topic even for -cafe. -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] some newbie FFI questions
John Kozak [EMAIL PROTECTED] writes: data Pixel a = Pixel !a !a !a deriving Show I use ImageMagick to load the image, then build an Array of Pixel Floats. Building the array takes 45 seconds on a 2.5Ghz P4 with code compiled -O2, which seems slow to me - are my expectations unrealistic? I've tried various UNPACK things which didn't make much difference. Are you using UArrays? If you're going to read the whole image anyway, they will probably be faster than the normal arrays. Also, I read somewhere that operations are often specialized for Double but not Float - since you talk about image loading rather than processing, it may be worth it to use Floats to save space, even if Doubles could be faster. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] migrating from python
paolo veronelli [EMAIL PROTECTED] writes: All these are very natural with dictionaries, so I'd like to figure out the haskell view. I've no clue what you're doing (or for that matter, what RDFs are), but is there any reason Data.FiniteMap doesn't do the job? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] optimising for vector units
MR K P SCHUPKE [EMAIL PROTECTED] writes: Well I have to say the dataflow style of lazy programming made me think Haskell would be ideal for multi-processor use (and now HyperThreading is common most PCs have more than one processor from the code's point of view)... I was disappointed to find GHC only uses one thread, and therefore will only use one CPU. I'm sure somebody, somewhere, is working on speculative execution of Haskell code. Now that Sun is building Niagara with IIRC 8 cores on a chip, Intel is rumoured to put up to 16 cores on the post-Montecito Tukwila, Sony/IBM's Cell is said to be some kind of parallel design, and every self-respecting chip vendor is putting at least two cores on a chip and/or adding multithreaded cores. Even if there's a lot of rumor-mongering going on, it seems fairly clear that you can only go on for so long, adding more cache to your old designs, and the bottleneck then becomes the inherent parallelism in your code. One would expect a lazy and pure language to be excellent for parallelization, since the programmer is generally removed from the actual flow of execution anyway. At some point (for some n), being able to spawn n threads will gain you more than a factor c constant overhead, and Haskell programs, with a run-time system that can evaluate expressions in paralllel, will outperform single threaded C code. (But it probably isn't that simple, or we would have it already :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] optimising for vector units
Jon Cast [EMAIL PROTECTED] writes: factor c constant overhead, ^^ What makes you think the overhead is constant? (Referring to the overhead introduced by boxing and such, not parallelizing. Sorry if that wasn't clear) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] optimising for vector units
Jan-Willem Maessen - Sun Labs East [EMAIL PROTECTED] writes: I missed this bit: I'm building compilers for supercomputers at Sun casualSo, any plans for compilers for functional languages making use of Niagara? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
Graham Klyne [EMAIL PROTECTED] writes: 2. I like to distinguish between expected errors and unexpected errors. Having been burned in the past by using exceptions (not FP), I try to use them only for conditions that are truly unexpected; i.e. _exceptional_. Bad input, IMO, is something that is not unexpected, so I don't really like to handle that via exceptions. I agree, trying to handle exceptions caused by incorrect input is just needless complication, the program should crash, and the calling function should be fixed instead. Common errors that happen to me are: Prelude.head : empty list Prelude.read : no parse andPrelude.(!!) : index too large and so on. Is there any easy way (TH?) to amend these to output the line number of the offending caller? It would be a great improvement to see something like Prelude.head : empty list in Foo.hs, line 4711 since programs generally contain many, many calls to functions like these. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
MR K P SCHUPKE [EMAIL PROTECTED] writes: head :: [a] - Maybe a head (a0:_) = Just a0 head _ = Nothing Argh, no! Violating the precondition of head is a bug in the caller, I want it to crash, but I also want to know where. Wrapping it up in Maybe (or any other error propagation) is not a solution. I don't want to write a lot of unwrapping code in all the callers, just to get a trackable error message in the (few) cases where I'm using the function incorrectly. Neither do I want to write (\x - if null x then error (__FILE__:__LINE__) else head x) everywhere instead of head, nor pollute my code with error tracking, but otherwise meaningless strings. (Which is what I generally do when I get this kind of anonymous error. if null x then error foo else head x. A mechanism for a function to report the caller site would obliviate the need for all this ugliness. -kzm Hmm...if I run it through CPP and #define HEAD (\x - if null x then error (__FILE__:__LINE__) else head x) is the __LINE__ resolved at the place of declaration or at the place of usage? -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
MR K P SCHUPKE [EMAIL PROTECTED] writes: As for head, I think it's fine that it throws an error because it is specified to be defined for only non-empty lists. But surely it is better to encode this fact in the type system by useing a separate type for non-empty lists. Yes, in principle. But that means you still need to write more and tedious code to deal with it. And there's a question how far you can practically get with this approach. Are you going to discard lists in favor of tuples, just because the type systems can't verify that the index passed to (!!) is witin range? A mechanism for a function to report the caller site would obliviate the need for all this ugliness Unfortunately the cost of this is prohabative as the call stack would have to contain backtrace information. Also due to lazy evaluation the 'call site' may not be what you expect. AFAICS, this disadvantage is shared by all other schemes of labeling call sites. The only difference is that I want to do it automatically (perhaps when a debug option is passed to the compiler) I don't want it for all functions or anything, just the annoying, small, and commonly used leaf functions. Here's what John Meacham had to say: --- Note that pattern matching rather than deconstruction functions have a number of benefits, not just relating to error messages, consider two functions which use the head of their argument. f xs = ... head xs ...=20 g (x:_) = ... x ... now, g is superior to f in several ways,=20 I agree with this. How about constructs like mins = map (head.sort) Is mins = map ((\(x:_)-x).sort) still so superior? Is it really necessary to sacrifice code clarity just to get decent error messages? And how do you extend this approach to 'read' and (!!)? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
MR K P SCHUPKE [EMAIL PROTECTED] writes:
mins = map ((\(x:_)-x).sort)
maybe what you meant was:
case sort x of
(x:_) - ... do whatever with x ...
_ - ... do failure conition ...
No, I don't think so. I only want the bug to be reported, and the
umatched pattern will do it nicely.
Yes, in principle. But that means you still need to write more and
tedious code to deal with it.
Just because code is tedious does not mean it is not necessary to
handle all corner cases. A robust application does not fail when
given unexpected input.
But if I use head, I should *know* that I never pass it an
empty list. Whether head returns a Nothing or just crashes doesn't
matter, I have to go and fix my *design*, because it has a bug,
and not a corner case that should be handled.
Are you going to discard lists in favor of tuples,
Of course not... You can actually define constrained datatypes where
the maximum length is a parameter of the type.
The only difference is that I want to do it automatically
My point was that you can manually label some functions, but to automatically
do it for all functions is going to cause big stack space problems - think
about recursive functions... or mutually recursive functions...
Yes, of course. So *my* point is that it would be really nice to
write small leaf functions like these with an implicit file/line
parameter that identified the caller site, in order to avoid
cluttering the code with them.
Okay, perhaps I'm not using the type system to its full extent, but I
think this is fairly common practice.
An easy solution seems to be to use -cpp and add
#define head (\(x:_)-x)
at the top of the relevant source files. However, I'm not sure how to
make this work with the other difficult functions. Another
alternative (basically emulating the GHC's behavior in the above case)
is
#define head (\x - case x of {(x:_) - x; _ - error (head failed at
++__FILE__++:++ show __LINE__)})
It seems difficult to generalize this, though.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
David Roundy [EMAIL PROTECTED] writes:
Here bug is a function that just calls error with a little prefix
explaining that there is a bug in darcs, and would the user please report
it. Obviously, defining a head here would be just as easy,
Cool! The basic trick is just to inline the actual function
defintions using CPP macros. I've made macros for most of the
troublesome functions, but I can't get it to work for operators
(something like `(!!)` doesn't parse, it seems) Any tricks?
Unless I'm overlooking something, I could have a file prelude.h
containing something like:
8--
import Prelude hiding (head,(!!),read)
#define head (\xs - case xs of { (x:_) - x ; _ - bug head __FILE__ __LINE__})
#define at (let {at (y:_) 0 = y; at (y:ys) n = at ys (n-1); at _ _ = bug at
__FILE__ __LINE__} in \a x - at a x)
#define read (\s - case [ x | (x,t) - reads s, (,) - lex t] of { [x] - x ; _
- bug read __FILE__ __LINE__})
#define fromJust (\x - case x of Just a - a; Nothing - bug fromJust __FILE__
__LINE__)
bug c f l = error (Program error - illegal parameters to '++c++', file '++f++',
line ++show l)
8--
and just #include prelude.h if/when I want better debugging. No
expensive stack frames, no unwanted strictness, and no clutter.
Any comments?
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
Ketil Malde [EMAIL PROTECTED] writes:
Unless I'm overlooking something
Which I of course did.
#define at (let {at (y:_) 0 = y; at (y:ys) n = at ys (n-1); at _ _ = bug at
__FILE__ __LINE__} in \a x - at a x)
No prize for spotting the bug here.
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] exceptions vs. Either
Ketil Malde [EMAIL PROTECTED] writes: import Prelude hiding (head,(!!),read) Any comments? Here's one: I thought this would make it difficult to have other imports of Prelude, hiding other pieces of it (e.g. catch, to avoid ambiguities with Control.Exception.catch) (Also, the definition of 'bug' hinders forces the #include to be after any imports, not sure it's better to have a separate module for it, which would then need to be on the module search path) (I seem to be mainly following up to my own posts, so if somebody asks, I'll take this to a quiet corner at the -cafe :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] closed classes
Malcolm Wallace [EMAIL PROTECTED] writes: Ah, but now you cannot use (Closed t) = as a predicate in type signatures, and since you cannot write a partial signature, you must omit the signature altogether... Hmm..yes, that would be a disadvantage. :-) -ketil -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] cost of List.// for Ord types?
Fergus Henderson [EMAIL PROTECTED] writes: Basically, I'm wondering if I should avoid using the standard library \\, If efficiency is a significant concern, and the lists involved may be long, yes, you should. I'm not sure how to preserve the semantics, either. (\\) seems to delete the first occurence of every value in the second list. I first tried this (\\\) :: Ord a = [a] - [a] - [a] a \\\ b = setToList $ minusSet (mkSet a) (mkSet b) and while it's often what I want, it's clearly not the same thing. More accurate to build a frequency table with freq xs = addListToFM_C (+) emptyFM $ zip xs $ repeat 1 and traverse the input something like (untested): a \\\ b = let ft = freq b in delf ft b delf ft (x:xs) = case lookupFM ft x of Nothing - x : delf ft xs Just n - delf (addToFM ft x (n-1)) xs delf _ [] = [] Should be O(|a|+|b|log|b|), I think. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Writing binary files?
Glynn Clements [EMAIL PROTECTED] writes: Right now, the attempt at providing I18N for free, by defining Char to mean Unicode, has essentially backfired, IMHO. Anything that isn't ISO-8859-1 just doesn't work for the most part, and anyone who wants Basically, I'm inclined to agree with what you say. A minor point is that the other ISO-8859 encodings (or really, any single-byte encoding) works equally well, as long as you don't want to mix them. So I guess you really want to say Anything that isn't a single-byte encoding... (Except for string constants, I guess, but perhaps you could just use its byte representation in the source? The length could be slightly surprising, though.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
Shawn Garbett [EMAIL PROTECTED] writes: viewpoint: What if List were a type class? Or, what if String were one? Could we have painless read/show with arrays of Char, as well as lists, for instance? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
Greg Buchholz [EMAIL PROTECTED] writes: I've been looking at the other shootout results (with the hope of learning something about making haskell programs faster/less memory hungry) and I couldn't quite figure out why the Hashes, part II test comsumes so much memory ( http://shootout.alioth.debian.org/bench/hash2/ ). So I started to try heap profiling, and generated the following graphs for the different types of profiles... biography = http://sleepingsquirrel.org/haskell/hash2_b.ps retainer = http://sleepingsquirrel.org/haskell/hash2_r.ps closure = http://sleepingsquirrel.org/haskell/hash2_d.ps type = http://sleepingsquirrel.org/haskell/hash2_y.ps cost cntr = http://sleepingsquirrel.org/haskell/hash2_c.ps ...but I have a hard time figuring out how to prevent something like stg_ap_3_upd_info or void cells from consuming so much memory. One thing you could do, is to move the pure definitions (constants and functions) out of the monad. This will make them separate cost centres, with their own profile information. I toyed with this, but admittedly, it didn't change much in this case. I think it is better style, though. A simple way to improve speed marginally, is to specify Int instead of letting things default to Integer. A more complex way, saving about 60% of the time, is to use unboxed arrays instead of strings for the keys - memory consumption seems to be the same, though. To get memory consumption down, I tried a strict update function: update k fm = let x = (get hash1 k + get fm k) in x `seq` addToFM fm k x which slowed the program down(!), but reduced memory consumption from about 25Mb to 1.5Mb. So it seems that the memory consumption is due to unevaluated values in the FMs. BTW, I looked at the shootout web pages, but I couldn't find the specification for any of the benchmarks. What is and isn't allowed? -kzm import System (getArgs) import Data.FiniteMap import Data.Array.Unboxed import Maybe type Key = UArray Int Char type Map = FiniteMap (UArray Int Char) Int hash1, hash2 :: Map hash1 = listToFM $ zip keys [0..] hash2 = listToFM $ zip keys (repeat 0) keys :: [Key] keys = map (\x - listArray (1,4+length (show x)) (foo_ ++ show x)) [0..] get :: Map - Key - Int get fm k = fromJust $ lookupFM fm k update :: Key - Map - Map update k fm = let x = (get hash1 k + get fm k) in x `seq` addToFM fm k x foo_1 = keys!!1 foo_ = keys!! main = do [n] - getArgs let res = foldr update hash2 (concat $ replicate (read n) keys) putStrLn $ unwords $ map show [get hash1 foo_1, get hash1 foo_, get res foo_1, get res foo_] -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OCaml list sees abysmal Language Shootout results
Ketil Malde [EMAIL PROTECTED] writes: To get memory consumption down, I tried a strict update function: update k fm = let x = (get hash1 k + get fm k) in x `seq` addToFM fm k x which slowed the program down(!), I wonder if this isn't due to never evaluating the values for foo_2 to foo_9998 because of laziness? BTW, I looked at the shootout web pages, but I couldn't find the specification for any of the benchmarks. What is and isn't allowed? For instance, changing the order of of the updates shaves another 10-20% off the time (because of cache-friendliness, I suppose): - let res = foldr update hash2 (concat $ replicate (read n) keys) + let res = foldr update hash2 (concat $ map (replicate (read n)) keys) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Can I determin the function name passed in?
Keith Wansbrough [EMAIL PROTECTED] writes:
Instead, you should pass around data items that
contain both the function and its name - either just pairs, [...]
or proper data types
...or both, using records:
data NamedFunc a b = NamedFunc { nameOf :: String, apply :: (a-b) }
f = NamedFunc successor (\x - x+1)
apply f 4
= 5
nameOf f
= successor
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Peter Simons [EMAIL PROTECTED] writes: Keith Wansbrough writes: Count me as a vote for the better-but-slightly-slower wc. How about the attached program? On my machine it faster than Tomasz's version, and I think it's still a fairly clean source code I guess it's possible to submit three different Haskell entries (for GHC, Hugs and NHC). Perhaps we should split up, and aim for performance with GHC, memory with NHC and clarity/brevity with Hugs? (Seriously, it would be very instructive to look at the differences between the three versions.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootout results
Peter Simons [EMAIL PROTECTED] writes: The problem is not Haskell, nor is it the implementation. The problem is that beginners, including yours truly, tend to write awfully inefficient code once you give them a String and tell them: Here, that's the contents of your file. And it's just so *convenient* to use it. Nonetheless, the problem is the inefficient code, not the language. But even a simple, single-pass word-counting using the standard IO is slow, it would be really nice to write this in a straightforward way and still get decent performance. As somebody just said, you get to chose between speed and simplicity/clarity of code. I would like both. Couldn't readFile et al. provide the standard interface, but use hGetBuf tricks (e.g. from your 'wc' entry) behind the curtains? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: OCaml list sees abysmal Language Shootoutresults
William Lee Irwin III [EMAIL PROTECTED] writes: Actually, I've been wondering about this. If my understanding is correct, Haskell lists are basicly singly-linked lists of cons cells (is that correct?) A simple (I think) thing to do would be to make the lists doubly-linked and circular. Uh, I think one of the main problems with the usual IO functions is that it adds the overhead of cons cells and optionally 32bit chars (although I think GHC packs them for char values 256) - when you really want an (unboxed) array of Word8. BTW can you give some references to these known techniques? Ugh, lousy cache properties... try rank-ordered B+ trees. There are probably better choices than that even. It's probably best Simon point us to references to what's actually useful here. I'm as dumb as anybody, but it seems to me that one could read a lazy chain (list) of buffers as UArray Int Word8, and tack a list-type interface (head, tail, cons...) interface on top. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subsequence near solved hopefully
Remi Turk [EMAIL PROTECTED] writes: You might also want to look at the earlier `any prefix of tails' suggestion, as it makes the solution a rather simple one-liner. Wouldn't that be looking for a sub*string*, and not a (general) sub*sequence* (which I think does not have to be contigous?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Subsequence near solved hopefully
Peter Stranney [EMAIL PROTECTED] writes: Thanks guys for all your help, finally through code, sweat and tears i have found the solution; Well done! I hope you don't mind some further comments? isSubStrand:: String - String - Bool isSubStrand [] [] = True isSubStrand [] (y:ys) = False You can just call it ys here, since the [] case is handled above. Although I see the point of using the pattern to make it explicit. Or you could write the two lines as isSubStrand [] ys = null ys -- null returns a Bool, True iff [] isSubStrand (x:xs) [] = False isSubStrand (x:xs) (y:ys) | length(x:xs)length(y:ys) = False You may think of this as an optimization, but it is the opposite - it will count up both lists at each iteration, making the algorithm O(n^2) complexity. Here I'd drop the (x:xs) pattern, and just use xs and ys. | take (length (x:xs)) (y:ys)==(x:xs) = True This is also inefficient; length traverses the xs, and equality does it again (until a mismatch) - and look up isPrefixOf in the Prelude! | otherwise = isSubStrand (x:xs) ys BTW, in addition to isPrefixOf, look at the function tails (also in the List module), and see if you can come up with a short, elegant and efficient solution using these two functions. :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are handles garbage-collected?
Remi Turk [EMAIL PROTECTED] writes: IMO, [bracket] does indeed have those same drawbacks. (Although the traditional explicit memory management model is alloc/free, which is much worse than bracket/withFile) Isn't bracket more like stack allocated memory? And most problems with explicit memory management related to heap (as you indicate)? The theoretical solution (and probably _only_ theoretical) is implementing a lot of garbage collectors: one for memory, one for open files, one for sockets, one for 3D polygon meshes etc etc... ...or have a number of available file handles that is limited by memory? :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Are handles garbage-collected?
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: - 8 times more popular on c.l.python than c.l.java, - 11 times more popular on c.l.python than c.l.perl, - 16 times more popular on c.l.python than c.l.c, but finally - 4 times *less* popular on c.l.python than c.l.scheme, i.e. the order of Haskell-awareness is Scheme Python Java Perl C. I'm not sure whether this is accounted for in the tally, but I would guess more threads are crossposted between c.l.scheme and c.l.functional than between c.l.f and the other groups, and thus more likely to be read by Haskellites. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Set of reals...?
Stijn De Saeger [EMAIL PROTECTED] writes:
But, like you mentioned in your post, now I find myself needing a
notion of subset relations, and since you obviously can't define
equality over functions, i'm stuck again.
Perhaps one can define an approximate equality, with an error bound?
Define the sets with a maximal boundary, and check points within the
combined boundary. You can only be sure about the answer if it is
'False', 'True' should be interpreted as maybe :-).
An inplementation could look something like (untested):
data RSet = RSet {isin :: Double - Bool, bounds :: (Double,Double) }
equals :: Double - Rset - RSet - Bool
equals epsilon s1 s2 = and (map (equals1 s1 s2) [l,l+epsion..h]
where l = min (fst $ bounds s1) (fst $ bounds s2)
h = max (snd $ bounds s1) (snd $ bounds s2)
Or you could use randomly sampled values (and perhaps give a
statistical figure for confidence?), or you could try to identify the
boundaries of each set, or..
Do you know any way around this problem, or have i hit a dead
end...?
Simulating real numbers on discrete machinery is a mess. Join the
club :-)
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Processing of large files
Alexander N. Kogan [EMAIL PROTECTED] writes: How should I modify it to make it useful on large file? It eats too much memory... procFile = putStrLn . show . foldl merge [] . ^ words foldl is infamous for building the complete list, before evaluating anything. Did you try foldr or foldl' instead? Also, you may want to make 'merge' more strict; I suspect you build lazy tuples that look like (word,1+1+1+1+...) and only get evaluated at the end. Using heap profiling will probably give you some hints (well documented in the GHC manual, ask if you get stuck) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Newbie Question on type constructors
Ben Rudiak-Gould [EMAIL PROTECTED] writes: In particular, your notation with type signatures makes it totally unclear that Circle and Square have disjoint ranges; in fact it looks like they have the same range. : The syntax that would have made the most sense to me would have been something like data Shape = forall x::Float. Circle x forall x::Float. Square x with maybe a + or something joining the lines, though that might have done more harm than good. Instead of +, perhaps we could use U (union) - we are talking about sets of values after all. And U is analogous to V (logical or, a value in the union is either in one set or the other), and on or the most common 'or' characters is, of course, the vertical bar, so perhaps the current syntax makes sense after all? :-) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Processing of large files
Alexander Kogan [EMAIL PROTECTED] writes: Thanks! I did the following: For extra credit, you can use a FiniteMap to store the words and counts. They have, as you probably know, log n access times, and should give you a substantial performance boost. :-) (I have a feeling FMs are slow when the keys are Strings - is it possible that a trie or other structure would be faster? Or using hashed keys, perhaps?) But I wonder why the very useful function foldl' as I define it is not included into Prelude? Me too - it's the main drawback going from Hugs to GHCi :-) I also wonder if there's any important uses for foldl where foldr or foldl' wouldn't be at least as good, but I'm sure somebody can come up with an example. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Processing of large files
Tomasz Zielonka [EMAIL PROTECTED] writes: Thank you. It works for me too, but I don't understand why and how ;-)) Could you explain? I'm a bit puzzled by this discussion, as strictness of FiniteMaps have rarely been (perceived to be?) a problem for me. Scott's solution forces (lookupFM a' x) to head normal form (or is it weak head normal form). This means that the value of type (Maybe v) is evaluated as much that it is known whether it is Nothing, Just _ or _|_ (bottom). This is probably enough to evaluate the path from FiniteMap's tree root to x. If you insert a value into a FiniteMap, isn't the key necessarily evaluated anyway? Or is the problem that you can get a long chain of unevaluated 'addToFM's? The trick would then be to evaluate the FM now and then (e.g. using a strict fold). However (lookupFM a' x) in head normal form can be still something like this: Just unevaluated: 1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1+1 I thought simply forcing evaluation of the value before inserting would do it (i.e. something like v `seq` addToFm fm k v (modulo v needing deeper seq'ing, that is) Am I missing something? -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Sound library?
Henning Thielemann [EMAIL PROTECTED] writes: On Fri, 3 Dec 2004, Jason Bailey wrote: Would anyone know of packages out there for Haskell that support mp3's or ogg files? Do you mean realtime unpacking and playback? I'm afraid without hacking Haskell programs are too slow for that. Really? Written in C, mpg123 can decode 50 minutes of audio in 30 seconds (tested on a 1GHz PIII) -- would a Haskell implementaion really be 100x slower? (Although I agree that FFI'ing to an existing library does sound like the thing to do.) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Non-technical Haskell question
John Goerzen [EMAIL PROTECTED] writes: sensibly share libraries between apps. Anyway, disc is cheap. Memory not so much, though. One advantage of having something in .so form is that every instance of every application that uses it shares the same in-memory image of the code. Well, a 5 Mbyte [1] overhead isn't really that much, IMHO. You'd need to run a lot of (different; if they're the same, the text will be shared) applications to get any measurable benefit. Eventually, it would be nice to have dynamic linkage, but I can see why it isn't a priority. -kzm [1] On my Linux system, the overhead seems to be less than 2 Mbyte. 5 Mb is the figure used by the OP. -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Non-technical Haskell question
Philippa Cowderoy [EMAIL PROTECTED] writes: The strip utility helps somewhat You're right, of course. My executable (incidentally on Sparc) seems to have an overhead of approximately one megabyte when just considering the text segment (that is, subtracting the text sizes of my own .o files). -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parse text difficulty
Douglas Bromley [EMAIL PROTECTED] writes: I've show(n) a particular data type and it shows up as: [([2,6],British),([1],Charles),([1,8],Clarke),([2,6],Council),([2],Edinburgh),([1],Education),([4],Increasingly)] Let me guess: type [([Integer],String)]? What I want to do is format that nicely into a table. Since you (probably) want one list entry on a line, why not format each entry as a string, and output each string as a line? You may find the function unlines to be helpful. The best way of doing (I thought) was to: Remove the first [( and final )] Then replace ),( with a newline(\n) If you really want to do this (reformat the string), you could perhaps write a function that substitutes a substring for something else, perhaps using isPrefixOf, drop and take. But this will be a more fragile design than working from the original data strucure. -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parse text difficulty
Robert Dockins [EMAIL PROTECTED] writes:
And I thought that most programmers used zipWith, which has to be
prefix.
[1..5] `zipWith (+)` [7..]
You don't have a computer at your end of the internet? :-)
Prelude [1..5] `zipWith (+)` [7..]
interactive:1: parse error on input `('
Prelude let zwp = zipWith (+) in [1..5] `zwp` [7..]
[8,10,12,14,16]
-kzm
--
If I haven't seen further, it is by standing in the footprints of giants
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Non-technical Haskell question
clearly this guy has never seen Phil Wadler. Some people may find this tasteless - I thought it was funny, so I guess those people will find me tasteless also. In that case, I'm probably already in their kill files, so this won't offend anybody. http://www.malevole.com/mv/misc/killerquiz/ -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] AbstractDataType question
Tomasz Zielonka [EMAIL PROTECTED] writes: Record field labels can be also used in pattern matching and in record update. Especially the latter is very useful. But not quite as elegant -- while record query lets you modify the underlying structure and replace the old record queries with functions, I don't think there's a way to do this for record updates (or am I wrong?) -kzm -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Begginer question
Maurício [EMAIL PROTECTED] writes:
complex_root :: (Float, Float, Float) - (Complex Float, Complex Float)
complex_root (a,b,c) = (x1,x2) where {
delta = b * b - 4 * a * c :: Float;
sqr_delta = if delta = 0 then (sqrt delta) :+ 0 else 0 :+
(sqrt delta) :: (Complex Float);
x1 = (b + sqr_delta)/(2 * a);
x2 = (b - sqr_delta)/(2 * a);
}
Couldn't match `Float' against `Complex Float'
Expected type: Float
Inferred type: Complex Float
In the second argument of `(+)', namely `sqr_delta'
In the definition of `x1': x1 = (b + sqr_delta)
The error message says it all, really.
If you examine the definition of x1, you see that (+) is applied to
two variables. If you check these, you will discover that they have
different types, which is the cause of the error.
Note that Haskell doesn't automatically convert arguments for you --
this is a feature.
-kzm
--
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: Utility functions
Simon Marlow [EMAIL PROTECTED] writes: There are already a couple of bits of (L)GPL under fptools: GMP and readline. GMP we'd like to replace because it is necessarily a part of every compiled Haskell program; readline isn't so important but it would be nice to have a BSD-licensed replacement. Readline is GPL and GMP LGPL, aren't they? So GMP only restricts what you can do with modifications to that library (and thus only affects developers who want to release a modified GHC without source), while linking with readline will potentially affect regular users of GHC. Or? -kzm -- 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] Some random newbie questions
[EMAIL PROTECTED] writes: I'm constantly surprised hearing from so many people about their space problems. I cannot remember having space problems with my programs. I don't know what everybody else is doing wrong :-) At least two common cases. Extracting compact data structures from large files. The contents of the large file is read as a linked list (ugh) of pointers (double ugh) to 32-bit Chars (triple ugh) -- twelve times the size of the file, if my calculations are correct. The contents can't be GC'ed before the extracted data is fully evaluated. (Now if the file was an mmap'ed array, it wouldn't be so bad, perhaps in the next generation IO that people are discussing this will be easier?) Naive use of foldl. I tend to think the default foldl should be strict (ie. replaced by foldl') -- are there important cases where it needs to be lazy? I do disagree with people recommending strictness annotations (seq etc). In contrast, I make my programs as lazy as possible. ...but no lazier :-) -kzm -- 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] Hugs vs GHC (again) was: Re: Some random newbiequestions
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: - Do the character class functions (isUpper, isAlpha etc.) work correctly on the full range of Unicode characters? It's not obvious what the predicates should really mean, e.g. should isDigit and isHexDigit include non-ASCII digits or should isSpace include non-breaking space characters. I think perhaps the answer is all of the above. The functions could be defined in multiple modules, so that 'ASCII.isSpace' would match the normal space character only, while 'Unicode.isSpace' could match all the weird and wonderful stuff in the standard. I also have the feeling that 'String' and/or 'Char' should be classes rather than data types (perhaps with 'String' built on top of a more general 'Sequence' type?) Ideally, you could treat an array as well as a list as a string. JM$0.02 -kzm -- 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: Hugs vs GHC (again) was: Re: Some randomnewbiequestions
Simon Marlow [EMAIL PROTECTED] writes: For unix, there are couple different tacks one could take. The locale system is standard, and does work, but is ugly and a pain to work with. In particular, it's another (set of) global variables. And what do you do with a character not expressible in the current locale? I'd like to possibility of different character sets for different files, for example. Not a problem. Have you looked at the streams proposal? I don't suppose this will make (stream)getContents any more efficient, beyond reducing the data size from Char to Word8? (So I still need to use explicit buffering (as described by Peter Simons, IIRC) to get fast IO?) And one small comment: is it still considered good form to prefix functions with argument type (instead of using modules - i.e. streamGetContents and fileGetContents as opposed to Stream.getContents and File.getContents). -kzm -- 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] Typing question
Dmitri Pissarenko [EMAIL PROTECTED] writes:
a) How should I define the types of the attributes correctly?
data Purchase = P Double Double
data Customer = C Int [Purchase]
or, if you want named fields:
data Purchase = P { price, rebate :: Double }
data Customer = C { id :: Int, purchases :: [Purchase] }
b) Is it possible to impose a constraint on the constructor of
tuple Purchase, so that the compiler throws an error, if one tries
to create a purchase where rebate is greater than price (rebate and
price are given in absolute numbers; rebate is NOT a fraction of
price)?
One way would be to store it as a fraction, e.g. using an Int8 with
implicit 256 (or 255) denominator, which elminates the problem. Or
create a function that constructs only valid Purchases, and hide the P
constructor (i.e. don't export it from the module).
c) What is a correct name for attributes of tuples (such as price
and rebate in Purchase) and constructors of tuples?
I think the accepted lingo is records with named fields.
-kzm
--
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: Hugs vs GHC (again) was: Re: Some randomnewbiequestions
Okay, I've taken a look (there seems to be some differences between the web page and the tgz from the wiki - fileGet seems to have disappeared). I still don't grok much of it, so just ignore me if I'm being overly naive. Anyway. Let's see, I can now open a stream from a file by doing: f - openFileInputStream filename streamGet f now gets me the bytes in that file. Adding an encoding: t - textInputStream f utf8 tsGet t gets me Chars as decoded by the utf8 decoder. Cool. Couldn't this be generalized more? What about a fundep on the Stream classes, parametrizing by content? Ideally, I would like to have 'get' return a value of a type appropriate to the stream type. I must admit I didn't dig too deeply in the gritty details of applying codecs, but must textInputStream be limited to text-decoding functions? It would be really nice to be able to specify arbitrary decoders (e.g. using 't - Stream.decode f utf8') to do stuff like t - decode f zip p - decode f (crypt password) So it seems to me that this can be generalized to more than Text, but the implementation is perhaps too text-specific? BTW and IMHO, perhaps the parameters could be swapped - i.e. 'map (textInputStream utf8) f1 f2 f3' seems to me to be more useful than 'map (textInputStream f) utf8 iso8859_1 ucs4' :-) -kzm -- 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] Signature of a function
Dmitri Pissarenko [EMAIL PROTECTED] writes: When I remove the line activityIndicator :: Customer - Num What is wrong in the signature above? Try ':i activityIndicator'? -kzm -- 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: Character predicates
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: Dimitry Golubovsky [EMAIL PROTECTED] writes: [Proposal: ASCII.isDigit is true for '0'..'9', Unicode.isDigit is true for whatever Unicode defines as digits] So there might be a bunch of (perhaps autogenerated, from localedef files) modules for each locale/encoding, like ISO8859_1 or KOI_8. I disagree. Char is supposed to mean Unicode only, and data is converted to Unicode on boundaries with those parts of the world which use different encodings. ...and uppercase chars in KOI_8 is a subset of uppercase chars in Unicode, so a KOI_8-specific isUpper would be superflous(?) My intention was only to separate between (the traditional) ASCII and (our modern day tower of Babel) Unicode. One possibility could be to have locale-modules apply to (raw) Word8 data -- so somebody writing for KOI_8 could avoid converting to UC Char at all. I'm not sure this is something we want, though. -kzm -- 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: I/O interface
Keean Schupke [EMAIL PROTECTED] writes: At the end of the day IO is serial by nature (to one device anyway), so the way to do this into one file is to have one thread that reads and writes, and to 'send' read and write requests over channels from the threads that need the work done Would the stream proposal make this possible and easy? I.e. could the IO thread provide (say) output streams to the other threads, and pass writes on to its own output stream? -kzm -- 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: I/O interface
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] writes: Ketil Malde [EMAIL PROTECTED] writes: It seemed to me, though, that streams are related to channels, I'm not sure what exactly do you mean by streams (because they are only being designed), but differences are: Sorry for being unclear, I was thinking in relation to the new-io proposal Simon M. recently posted on the lists (I put all Haskell mail in the same folder, it could have been a ghc list or haskell@). - A stream passes around bytes, which are usually grouped in blocks for efficiency. A channel is polymorphic wrt. the element type and elements are always processed one by one. Perhaps I'm confused, but while Stream.StreamInputStream is a stream of Word8, Text.TextInputStream provides a stream of Chars. Thanks for the explanation! -kzm -- 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] Question about instance
John Velman [EMAIL PROTECTED] writes:
data Relation a i b = Rel {name::RN, arity::Int, members::(Set [EN])}
Why do you parametrize the data type when you don't use the
parameters? Either do
data Relation = Rel {name::RN, arity::Int, members::Set [EN]}
or
data Relation a i b = {name::a, arity::i, members::Set b}
(or whatever you intended).
instance (Show a, Show i, Show b) = Show (Relation a i b)
where
show (Rel a i b) =
a ++ / ++ (show i) ++
++ (show b)
It doesn't matter whether a,i,b are in Show, as you don't use them
(they are completely unrelated to the a,i,b in (Rel a i b), the former
are types, the latter are variables)
-kzm
PS: Please don't quote the entire thread in each message. Although I
haven't seen Andreas' message on the list (yet).
--
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] Linear shuffle
Gracjan Polak [EMAIL PROTECTED] writes: shuffle :: [a] - IO [a] shuffle [] = return [] shuffle x = do r - randomRIO (0::Int,length x - 1) s - shuffle (take r x ++ drop (r+1) x) return ((x!!r) : s) This algorithm seems not effective, length, take, drop and (!!) are costly. Is there any better way to implement shuffle? The length seems to me to be constant, so you could presumably calculate it once, and pass it as a parameter. Then, given the index 'r' you could use 'splitAt r' to split the string, and join the first part to the tail of the second, prepending the head of the second. More precisely (I hope this is not a homework excercise :-): : (s1,s2) = splitAt r return (head s2 : s1 ++ tail s2) This reduces the three (four if you include length) traversals to one. -kzm -- 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] Linear shuffle
Tomasz Zielonka [EMAIL PROTECTED] writes: On Fri, Jan 14, 2005 at 09:17:41AM +0100, Gracjan Polak wrote: This algorithm seems not effective, length, take, drop and (!!) are costly. Is there any better way to implement shuffle? You can use mutable arrays (modules Data.Array.MArray, Data.Array.IO). But is that better, really? IIUC, you will now need to shift the first part of the string to the right, so it's still a linear operation for each shuffle. -kzm -- 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] Linear shuffle
Tomasz Zielonka [EMAIL PROTECTED] writes: But is that better, really? IIUC, you will now need to shift the first part of the string to the right, so it's still a linear operation for each shuffle. Perhaps I don't know this particular algorithm, but you can shuffle the array with linear number of swaps. No need to shift elements. Right - this implementation picked an arbitrary element, placed it in front, and repeated, if I understood it correctly. Slightly different from moving each element to a random position (e.g. after k shuffles, elements (k+1..n) will be in the original order), but perhaps this too can be easily emulated with an array-based (direct) shuffle? -kzm -- 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] Linear shuffle
Keean Schupke [EMAIL PROTECTED] writes: Please see: http://okmij.org/ftp/Haskell/perfect-shuffle.txt For an explanation of the algorithm. Right. I was commenting based on the source posted by Gracjan. (And http://c2.com/cgi/wiki?LinearShuffle contains a variety of shuffling algorithms). -kzm -- 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: Answers to Exercises in Craft of FP
David Owen [EMAIL PROTECTED] writes: Do you know if there are solutions to exersises available somewhere? Have you gone through the whole book, i.e. all the exercises? Unfortuantely I don't know of anywhere that the exercise answers can be found, even after some google searching. Another option is posting the excercise to this list (or perhaps in comp.lang.functional), along with your current effort at solving it. (As this could look like a homework request, don't expect the direct solution, but I think you will get some hints to nudge you in the right direction.) -kzm -- 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] Math libraries for Haskell
Keean Schupke [EMAIL PROTECTED] writes: Can I request 2 types, one for dense (complete) matricies and another for sparse matricies? ...and maybe also put (!) in a class, so that it can be used as a general indexing operator for all indexed data structures? (Or is this already possible? I must admit I'm slightly lost in IArray, Ix, HasBounds etc.) -kzm -- 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] Reading images (PGM)
Greg Buchholz [EMAIL PROTECTED] writes: I need to write a function in Haskell, which 1) reads a greyscale image (for instance, in JPEG, PNG or the like) and If you can specify any image format you want, and you're not concerned with efficiency, you can't beat the simplicity of the portrable greymap (PGM) file format. There are also variants using black and white (PBM) and color (PPM) and they also have textual value representations. Google for Andrew Cooke's pages, he has some code for reading/writing them as part of Pancito, IIRC. -kzm -- 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: Hugsvs GHC (again)was: Re: Somerandomnewbiequestions
Duncan Coutts [EMAIL PROTECTED] writes: The point is that the Unix documentation does not consider the short pause as data is read off your hard drive to be blocking. So that's why select will always report that data is available when you use it with a file handle. Isn't this also for historic reasons? I.e. disk latency has improved from what? 20ms to perhaps 7ms the last fifteen years. CPU frequency has gone from a few MHz to a few GHz in the same time frame. So while a disk seek used to amount to perhaps a thousand instructions -- hardly worth a task switch, it now amounts to millions of instructions. (All numbers made up, of course) With fast CPUs and distributed memory (NUMA architectures), the difference between cache and global memory is beginning to increase also -- perhaps select() really should wake up when the buffer is available in L2 cache? -kzm -- 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] LGPL libraries
Kirsten Chevalier wrote: I am not a lawyer, but there are a couple of important points getting missed in this thread: [...] That's just silly isn't a defense. [...] and thus trust me, we're not going to sue you isn't the answer they're looking for, even if it's a completely accurate answer. I'm not a lawyer either, but I've discussed this a bit with one. Since the GPL is a voluntary licensing with no renumeration, the intent of the licensor will be given a lot more weight than in a negotiated agreement between two (more or less equal) parties. I think a clear statement from the author that linking statically is allowed in his interpretation of the license will be sufficient, even if it's not obvious from the licencing text. FSF or other third parties opinions should be irrelevant. So actually asking and getting the author's opinion is probably a good idea. This is according to Norwegian law, but I think such a statement will in any jurisdiction make it clear that you were acting in good faith. (Just make sure you have a contingency plan for when Duncan asks you to cease and desist :-) (And of course there's nothing to prevent you from being met at the airport the next time you travel to country with different copyright law enforcement. Also, there are other copyright holders to this particular code who may want to have their say in the matter.) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] idea for avoiding temporaries
David Roundy wrote: Actually, I was thinking this sounded a lot like DiffArrays. Except that DiffArrays are slow and expensive in both space and time (compared with strict unboxed arrays). They necesarily hold boxed values so you pay a factor of at least two in space cost (for arrays of Doubles) right off the top, and there's no way you could recover that. What about using a DiffArray with reasonably-sized (cache-friendly?) UArrays as the elements? That way, the cost of boxing can be amortized over more Doubles. Efficiency would depend on updated patterns, of course. -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lazy IO and closing of file handles
Donald Bruce Stewart wrote: pete-expires-20070513: When using readFile to process a large number of files, I am exceeding the resource limits for the maximum number of open file descriptors This is very annoying - I can't see any good reason why file descriptors should run out (before memory is exhausted). I guess the Linux kernel is intended for imperative use :-/ Read in data strictly, and there are two obvious ways to do that: -- Via strings [..] -- Via ByteStrings [..] Perhaps this is an esoteric way, but I think the nicest approach is to parse into a strict structure. If you fully evaluate each Email (or whatever structure you parse into), there will be no unevaluated thunks linking to the file, and it will be closed. If the files are small (e.g. maildir or similar with one email in each?), you can use strict ByteString, but I generally use lazy ByteStrings for just about anything. Be aware that extracting a substring from a ByteString is performed by slicing, so it keeps a pointer to the original string (along with offset and length). For strict ByteStrings, this would keep everything in memory, for lazy ByteStrings, you'd keep only the relevant chunks (so that would allow the body to be GC'ed, if you aren't interested in keeping it). (I wonder if the garbage collector could somehow discover strings that have been sliced down a lot, and copy only the relevant parts?) -k ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
