Re: [Haskell-cafe] A GHC error message puzzle
Pierre-Etienne Meunier wrote: Does it still work with : writeFile output $! process inp You're right, that changes things. Then the program prints: loop That would have given it away, of course. :) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
Sebastian Fischer wrote: process = process Nice! What about the other part of the solution: What is the cause of the error? Of course, the cause is the black hole. But why is it not reported? Hmm. On second thought, perhaps it was a good idea after all that I did not exclude GHC team members and their families. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A GHC error message puzzle
Lennart Augustsson wrote: So it's a bug in the garbage collector. It's closing a handle that clearly is still reachable, otherwise this would not have happened. Simon Marlow wrote: The handle is in fact not reachable from the roots, because the thread that points to it is also not reachable. I think I agree with Lennart here. A thread with an active exception handler is not permanently unreachable, only temporarily unreachable, unless we know that it is impossible for any exception to be thrown at it that it is capable of catching. In this case, the handler can catch a NonTermination, so it is not unreachable. A keyboard interrupt is another possibility. If we know that things are really stuck it could still be helpful for us to throw the NonTermination, but that doesn't mean that the handle should be considered unreachable at the time. It is very important to do the best we can to allow people's exception handlers to run successfully, especially in a bracket. That is a much higher priority than protecting people from hanging their app when they write poor exception handlers. By finalizing the handle, you are significantly lowering the chance of exception handlers being able to do a proper job. I do agree, though, that hClose should be less finicky about finalized handles, which would solve the problem in this particular case. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Sean Leather wrote: Which one do you use for strings in HTML or XML in which UTF-8 has become the commonly accepted standard encoding? UTF-8 is only becoming the standard for non-CJK languages. We are told by members of our community in CJK countries that UTF-8 is not widely adopted there, and there is no sign that it ever will be. And one should be aware that the proportion of CJK in global Internet traffic is growing quickly. But of course, that is still a legitimate question for some situations in which full internationalization will not be needed. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Sean Leather wrote: So then, what is the standard? ...I also noticeably don't see UTF-16. Right there are a handful of language-specific 16-bit encodings that are popular, from what I understand. So, if this is the case, then a similar question still arises for CJK text: What format/library to use for it (assuming one doesn't want a performance penalty for translating between Data.Text's internal format and the target format)? It appears that there are no ideal answers to such questions. Right. If you know you'll be in a specific encoding - whether UTF-8, Latin1, one of the CJK encodings, or whatever, it might sometimes make sense to skip Data.Text and do the IO as raw bytes using ByteString and then encode/decode manually only when needed. Otherwise, Data.Text is probably the way to go. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Bryan O'Sullivan wrote: In general, Unicode uptake is increasing rapidly: http://googleblog.blogspot.com/2010/01/unicode-nearing-50-of-web.html These Google graphs are the oft-quoted source of Unicode's growing dominance. But the data for those graphs is taken from Google's own web indexing. Google is a U.S. company that appears to have a strong Western culture bias - viz. their recent high-profile struggles with China. Google is far from being the dominant market leader in CJK countries that they are in Western countries. Their level of understanding of those markets is clearly not the same. It could be this really is true for CJK countries as well, or it could be that the data is skewed by Google's web indexing methods. I won't believe that source until it is highly corroborated with data and opinions that are native to CJK countries, from sources that do not have a vested interest in Unicode adoption. What we have heard in the past from members of our own community in CJK countries does not agree at all with Google's claims, but that may be changing. It would be great to hear more from them. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Ketil Malde wrote: I haven't benchmarked it, but I'm fairly sure that, if you try to fit a 3Gbyte file (the Human genome, say¹), into a computer with 4Gbytes of RAM, UTF-16 will be slower than UTF-8... I don't think the genome is typical text. And I doubt that is true if that text is in a CJK language. I think that *IF* we are aiming for a single, grand, unified text library to Rule Them All, it needs to use UTF-8. Given the growth rate of China's economy, if CJK isn't already the majority of text being processed in the world, it will be soon. I have seen media reports claiming CJK is now a majority of text data going over the wire on the web, though I haven't seen anything scientific backing up those claims. It certainly seems reasonable. I believe Google's measurements based on their own web index showing wide adoption of UTF-8 are very badly skewed due to a strong Western bias. In that case, if we have to pick one encoding for Data.Text, UTF-16 is likely to be a better choice than UTF-8, especially if the cost is fairly low even for the special case of Western languages. Also, UTF-16 has become by far the dominant internal text format for most software and for most user platforms. Except on desktop Linux - and whether we like it or not, Linux desktops will remain a tiny minority for the foreseeable future. Alternatively, we can have different libraries with different representations for different purposes, where you'll get another few percent of juice by switching to the most appropriate. Currently the latter approach looks to be in favor, so if we can't have one single library, let us at least aim for a set of libraries with consistent interfaces and optimal performance. Data.Text is great for UTF-16, and I'd like to have something similar for UTF-8. Is all I'm trying to say. I agree. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Michael Snoyman wrote: Regarding the data: you haven't actually quoted any statistics about the prevalence of CJK data True, I haven't seen any - except for Google, which I don't believe is accurate. I would like to see some good unbiased data. Right now we just have our intuitions based on anecdotal evidence and whatever years of experience we have in IT. For the anecdotal evidence, I really wish that people from CJK countries were better represented in this discussion. Unfortunately, Haskell is less prevalent in CJK countries, and there is somewhat of a language barrier. I'd hate to make up statistics on the spot, especially when I don't have any numbers from you to compare them with. I agree, I wish we had better numbers. even if the majority of web pages served are in those three languages, a fairly high percentage of the content will *still* be ASCII, due simply to the HTML, CSS and Javascript overhead... As far as space usage, you are correct that CJK data will take up more memory in UTF-8 than UTF-16. The question still remains whether the overall document size will be larger: I'd be interested in taking a random sampling of CJK-encoded pages and comparing their UTF-8 and UTF-16 file sizes. I think simply talking about this in the vacuum of data is pointless. If anyone can recommend a CJK website which would be considered representative (or a few), I'll do the test myself. Again, I agree that some real data would be great. The problem is, I'm not sure if there is anyone in this discussion who is qualified to come up with anything even close to a fair random sampling or a CJK website that is representative. As far as I can tell, most of us participating in this discussion have absolutely zero perspective of what computing is like in CJK countries. As far as the conflation, there are two questions with regard to the encoding choice: encoding/decoding time and space usage. No, there is a third: using an API that results in robust, readable and maintainable code even in the face of changing encoding requirements. Unless you have proof that the difference in performance between that API and an API with a hard-wired encoding is the factor that is causing your particular application to fail to meet its requirements, the hard-wired approach is guilty of aggravated premature optimization. So for example, UTF-8 is an important option to have in a web toolkit. But if that's the only option, that web toolkit shouldn't be considered a general-purpose one in my opinion. I don't think *anyone* is asserting that UTF-16 is a common encoding for files anywhere, so by using UTF-16 we are simply incurring an overhead in every case. Well, to start with, all MS Word documents are in UTF-16. There are a few of those around I think. Most applications - in some sense of most - store text in UTF-16 Again, without any data, my intuition tells me that most of the text data stored in the world's files are in UTF-16. There is currently not much Haskell code that reads those formats directly, but I think that will be changing as usage of Haskell in the real world picks up. We can't consider a CJK encoding for text, Not as a default, certainly not as the only option. But nice to have as a choice. What *is* relevant is that a very large percentage of web pages *are*, in fact, standardizing on UTF-8, In Western countries. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: String vs ByteString
Ketil Malde wrote: I'd point out that it seems at least as unfair to optimize for CJK at the cost of Western languages. Quite true. [...speculative calculation from which we conclude that] a given document translated between Chinese and English should occupy roughly the same space in UTF-8, but be 2.5 times longer in English for UTF-16. Could be. We really need data on that. If it's practical to maintain different backends with identical public APIs and different internal encodings, that would be the best. After a few years of widespread usage, would know a lot more. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: Bugfix release for timezone-olson
Version 0.1.1 of the timezone-olson package is now available on Hackage. http://hackage.haskell.org/package/timezone-olson The timezone-olson package provides a parser and renderer for binary Olson timezone files whose format is specified by the tzfile(5) man page on Unix-like systems. These files are often found in /usr/share/zoneinfo on Unix-like systems. Functions are provided for converting the parsed data into TimeZoneSeries objects from the timezone-series package. Now that Version 2 format Olson files are beginning to appear in the wild, we can see the full details of how the specification in the tzfile(5) man page is applied in real life. This release fixes several bugs related to parsing and rendering Version 2 format Olson files, as well as a few other small issues. Updating is recommended. A new version of the timezone-series package, also version 0.1.1, is also now available on Hackage. http://hackage.haskell.org/package/timezone-olson The timezone-series package endows Data.Time, from the time package, with several data types and functions for enhanced processing of timezones. Among them is TimeZoneSeries,which represents all of the clock settings that occur in a time zone, and functions to convert between UTCTime and LocalTime without knowing in advance what clock setting is in effect at the given moment. This release of timezone-series only adds a few type signatures and more documentation for isValidLocalTime and isRedundantLocalTime and friends. Aristid Breitkreuz provided a proof for the basic fact about time change gaps and overlaps that is used to implement them. The proof can be seen here: http://projects.haskell.org/time-ng/gaps_and_overlaps.html Many thanks to Aristid who, in addition to providing the above proof, assisted in finding bugs and preparing for the release of these two updates. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Should Yesod.Mail be a separate package?
Michael Snoyman wrote: [1] http://hackage.haskell.org/package/mime-mail Great news! This is an important package. It's obviously very preliminary, though. This is not trivial to get right - look at the long and colorful history of the Python email library, detailed on the first page of the library documentation. Here are some initial suggestions for improvement: 1. The module name Network.Mail.Mime is too generic. There will also be a parser someday. We should have Types, Parse, and Render in separate modules. I expect each of those to grow gradually as more features are added. On the other hand, I think I like the decision to re-implement just the features of RFC 2822 message format needed for everyday MIME use rather than building this on top of a more generic message type, as is done in Python. It simplifies things. But are multi-line headers supported properly? That's trickier than it looks, there have historically been many wrong implementations out there. That itself could be a reason to build this on top of a proper RFC 2822 implementation. 2. mailHeaders should have an Ord instance that compares case-insensitively, though the underlying Strings should remain Strings. 3. It should be possible to control whether text parts get quoted-printable encoded. Perhaps add QuotedPrintable to Encoding? 4. I don't like having those sendmail things here in the same module and package. It's convenient, but messy in several ways - creates a spurious dependency on process, only works on certain platforms and even then with possible weird platform dependencies, etc. I think this should be in a separate package. Once there is a nice easy-to-use SMTP companion package, I don't think the sendmail things will be used that much anyway. Put them in a separate package, but mention it in prominent places so people will find it. 5. Is the blaze-builder dependency necessary now that Bryan has built those techniques into Data.Text? 6. Are I18N text-encoded headers supported? That's very important, even for simple everyday usage. It's a bit complicated, though. That might be another reason to build on top of a full RFC 2822 implementation. 7. This very simple interface is great for everyday use. Think about how to add the less common options for more general use, without cluttering up the everyday interface - custom parameters for Content-Type and Content-Disposition, specifying the boundary rather than allowing it to be generated automatically, etc. It's important to think about those kinds of things now, before the interface gets set in cement. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] data.time.zoneinfo
Anatoly Yakovenko wrote: I am trying to figure out how to use this library, seems like this should work Data.Time.ZoneInfo... Have you looked at my timezone-olson package? I wrote it as an alternative to Data.Time.ZoneInfo. I think it is more flexible, and better integrated with Data.Time. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Should Yesod.Mail be a separate package?
I wrote: 2. mailHeaders should have an Ord instance that compares case-insensitively, though the underlying Strings should remain Strings. I really meant Eq instance - which then affects the Ord instance, too. Sorry. wren ng thornton wrote: What is the intended use case? Since many uses of Ord imply filtering out duplicates, this seems like it could result in getting inconsistent capitalization. Granted, the RFC says it's case-insensitive, but some folks like their aesthetics... (then again, those folks should probably use case-normalizers. I'm mostly just curious if the Ord is intended for Data.Map or what.) Of course the type will preserve case internally. I envision something like a HeaderName type which is a newtype wrapper for String. If you really want to see the details of case when you are doing something other than rendering, you can always extract the String out of the newtype. But semantically, header names are case insensitive. Here is a use case - I want to search for the From field in an email. (Or all of the From fields, sometimes there is more than one.) Well, someone may have used non-standard case, but it should still match. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskellers browse users form
I'm using Safari on Snow Leopard. On the Browse Users page on Haskellers, there are little buttons that look like number spinners on the two numerical fields, like Using Haskell since... When I press one of those, the number -1.7976931348623157e+308 appears in the field. That must be Lennart. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
Jon Fairbairn wrote: I'm probably terribly out of date with this, so I wonder if anyone can save me the bother of working out what the /preferred/ libraries are for (a) determining the last-modified-time of a file or directory and (b) manipulating the resulting time datum. I can find System.Directory.getModificationTime and Data.Time.formatTime, but using them together seems unduly awkward. It's not you who is out of date - it is the base library, which *still* uses the long deprecated old-time library for these kinds of functions. Is there an existing trac ticket about this? Going via a string representation is obviously not the most robust or efficient method, but converting to a CalendarTime and manually building a UTCTime from it may not be worth the effort. One alternative is to use the convertible package. Then you can just say: utc - fmap convert (getModificationTime myFile) :: IO UTCTime Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Catching up on Time and Directory
Michael Snoyman wrote: * Move System.Locale into the time package, bumping version number to 1.3. * Bump old-locale to 1.1 and have it simply re-export System.Locale from time. (Maybe we don't actually need to make that bump, 1.0.1 may be sufficient.) * Bump old-time to 2.0 (make it clear this is a *very* different version) and have it re-export modules from time. (This is the part of the proposal people should *really* beat up on.) I disagree with all of these items, and only support the last item: * Find every single package depending on old-time and get it to use time instead. Most importantly, base. These old- packages have been deprecated for long enough. Dump them. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Downloading web page in Haskell
José Romildo Malaquias wrote: Web browsers like Firefox and Opera does not seem to have the same problem with this web page. I would like to be able to download this page from Haskell. Hi Romildo, This web page serves the head, including a lot of JavaScript, and the first few hundred bytes of the body, then pauses. That causes web browsers to begin loading and executing the JavaScript. Apparently, the site only continues serving the rest of the page if the JavaScript is actually loaded and executed. If not, it aborts. Either intentionally or unintentionally, that effectively prevents naive scripts from accessing the page. Cute technique. So if you don't want to honor the site author's intention not to allow scripts to load the page, try looking through the JavaScript and find out what you need to do to get the page to continue loading. However, if the site author is very determined to stop you, the JavaScript will be obfuscated or encrypted, which would make this an annoying task. Good luck, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Downloading web page in Haskell
Albert Y. C. Lai wrote: ...truncates when the web server chooses the identity encoding The server chooses identity when your request's Accept-Encoding field specifies identity or simply your request has no Accept-Encoding field Excellent work! My methodology of discovering and confirming this is a great lesson in the triumph of the scientific methodology (over the prevailing opinionative methodology, for example). Haha, indeed! Actually the truncation strongly suggests that javascript is not involved: the truncation ends with an incomplete end-tag /. This is abnormal even for very buggy javascript-heavy web pages. Well, no, the theory was that the server sends some random number of bytes from the body to ensure that the browser starts loading the scripts in the head. So it could stop anywhere. In the end, I think you didn't really need the W3C validator. You also could have triangulated on the headers sent by your own browser. So, there you have it, folks. The Haskell community debugs a broken web server, without being asked, and without access to the server. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most images broken on haskellwiki pages
Eugene Kirpichov wrote: I looked at a couple pages of mine... and looks like the vast majority of images are not displaying. This probably has to do with moving the wiki to the new server during the past few days. I forwarded your email to the admin team there for them to have a look. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] doesDirectoryExist is always returning False
On Sat, Nov 20, 2010 at 4:55 PM, Marcelo Sousa wrote:
I'm having currently a problem with System.Directory in my mac os.
System Version: Mac OS X 10.6.5
Kernel Version: Darwin 10.5.0
Prelude System.Directory let dirTest = do {dir - getCurrentDirectory;
doesDirectoryExist dir}
Prelude System.Directory dirTest
False
This did not happen on my Mac, but now it started
happening, right after I upgraded some packages.
I suspect the unix package. See:
http://hackage.haskell.org/trac/ghc/ticket/4812
Thanks,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] doesDirectoryExist is always returning False
Marcelo Sousa wrote:
I'm having currently a problem with System.Directory in my mac os.
Prelude System.Directory let dirTest = do {dir - getCurrentDirectory;
doesDirectoryExist dir}
Prelude System.Directory dirTest
False
I.e., System.Directory.doesDirectoryExist always
returns False.
I wrote:
http://hackage.haskell.org/trac/ghc/ticket/4812
It looks like this problem happens when you upgrade or reinstall the
directory package (any version) after upgrading the unix package to
version 2.4.1.0 on Mac OS X.
Note that the directory package does depend on unix or Win32,
as obviously it must. That dependency can be seen in
directory.cabal, even though it does not show up on hackage.
Thanks to Simon Marlow for clarifying that point.
So a work-around for this problem is:
cabal install --reinstall --constraint='unix == 2.4.0.2' directory
If you originally upgraded or reinstalled directory using the
--global flag, you must add it to the above also.
Thanks to Duncan Coutts for this work-around.
Regards,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: The attosplit package splits lazy bytestrings lazily
This is a belated announcement of a package I uploaded to hackage last week. When processing a large input stream, one of the most important techniques is to split the input into smaller pieces and process each piece separately. If that large input stream happens to be a lazy bytestring, the attosplit package provides a simple but powerful way to use that technique. The attosplit package exports a single function: split :: Parser Strict.ByteString - Lazy.ByteString - [Lazy.ByteString] It splits a lazy bytestring into a lazy list of lazy bytestrings, at boundaries defined by an attoparsec parser. Whenever the parser matches, the result of the match is prepended to the new lazy bytestring which begins at that point. For example, suppose lazyH is a lazy bytestring read from a gigantic HTML file, and you want to process each section beginning with an H1 tag separately. Each section could itself still be quite large, so you want to process each section lazily as well. Then split (string H1) lazyH is a lazy list of lazy bytestrings. The first lazy bytestring gives you all of the bytes up to the first H1 tag. The rest of the lazy bytestrings give each section beginning with H1 separately. This allows you to read the entire file lazily, while processing each individual section lazily on its own. Of course, you are not limited to split only at boundaries defined by a string. You have the full power of attoparsec at your fingertips. http://hackage.haskell.org/package/attosplit Enjoy! -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mailing lists on projects.haskell.org
Hi, Sorry, I haven't been reading the cafe for a few days, so I just saw this thread. Erik de Castro Lopo wrote: I tried sending mail to the haskell-llvm mailing list ( AT projects.haskell.org) several days ago and today I received a bounce message. Looking into the issue a little further, I find that... projects.haskell.org doesn't seem to be listening on port 25. Thanks for this report. I have restarted exim, but it is still not responding. I'll bring it up with other haskell.org domain admins and see if we can get this fixed. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] chr/ord?
Michael Rice wrote:
-- comb is a combinator for sequencing operations that return Maybe
comb :: Maybe a - (a - Maybe b) - Maybe b
comb Nothing _ = Nothing
comb (Just x) f = f x
comb is essentially the same as something in the Prelude:
it is just (=) specialized to Maybe.
(=) :: Monad m = m a - (a - m b) - m b
Now what am I misunderstanding in the code below?
lst = [('A',65),('B',66),('C',67),('D',68)]
Brandon S. Allbery wrote:
...it defaulted to [(Char,Integer)]. This is a manifestation
of the Monomorphism Restriction...
While it may be debatable whether the Monomorphism
Restriction is helpful in compiled code, it is unquestionably
a major nuisance at the GHCi prompt, for this and other
reasons.
I highly recommend that you create a .ghci file in your home
directory containing the line:
:set -XNoMonomorphismRestriction
In my opinion, MR should be off by default in GHCi.
-Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Make XNoMonomorphismRestriction the default in GHCi
I hereby propose that XNoMonomorphismRestriction be the default in GHCi. I submitted a ticket: http://hackage.haskell.org/trac/ghc/ticket/3202 Note that I am NOT expressing any opinion about MR in general - just about what the default should be in interactive GHCi sessions only. Please read my comments in the ticket, and respond here or in the ticket. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Simon Marlow wrote: Care to submit a patch to put this in System.Directory, or better still put the relevant functionality in System.Win32 and use it in System.Directory? Bulat Ziganshin wrote: now getDirectoryContents return ACP (ansi code page) names so openFile works for files 1) and 2). With such change getDirectoryContents will return correct unicode names, so openFile will work only with names in first group. The right way is to fix ALL string-related calls in System.IO, System.Posix.Internals, System.Environment. You're right in that we really ought to fix everything. However, I'm happy to just fix some of these things, even if it introduces some inconsistencies in the meantime. We already have much of System.Directory working with Unicode FilePaths, so there are already inconsistencies here. +1 for integrating Unicode file paths. Thanks, Bulat! I think the most important use cases that should not break are: o open/read/write a FilePath from getArgs o open/read/write a FilePath from getDirectoryContents There's not much we can do about non-Latin-1 ACP file paths hard coded in Strings. I hope there aren't too many of those in the wild. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Thomas Davie wrote: Not at all, as discussed, there are legitimate uses for a lazy sum, and haskell is a lazy language by default. Haskell is lazy by default, and we have found that to be a big win in most cases. So we don't need to be embarrassed to use strictness when that is the right thing to do. While there are indeed certain very rare situations in which you want foldr or foldl for sum, they are both joltingly wrong as the default for typical usage. In practice, I find this to be a small annoyance that occurs so often that it becomes a major one. Can we please fix it already? Let it be noted that this discussion also applies to product. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] curious about sum
Henk-Jan van Tuyl wrote: reverse maximum minimum Oh yes, please fix those also! scanl scanr scanr1 iterate take drop splitAt inits Hmm, I use those all the time with large lists. They are lazy as expected, and seem to work fine. Do you have examples of problems with them? foldM fliterM (Bulat) No opinion, I hardly use those. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
I wrote: I think the most important use cases that should not break are: o open/read/write a FilePath from getArgs o open/read/write a FilePath from getDirectoryContents Simon Marlow wrote: The following cases are currently broken: * Calling openFile on a literal Unicode FilePath (note, not ACP-encoded, just Unicode). * Reading a Unicode FilePath from a text file and then calling openFile on it I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents. Why only on Windows? I don't know how getArgs fits in here - should we be decoding argv using the ACP? And why not also on Unix? On any platform, the expected behavior should be that you type a file path at the command line, read it using getArgs, and open the file using that. For comparison, Python works that way, even though the variable is called argv there. The current behavior on Unix of returning, say, UTF-8 encoding characters in a String as if they were individual Unicode characters, is queer. Given your fantastic work so far to rid System.IO of those kinds of oddities, perhaps now is the time to finish the job. If you think we really need to provide access to the raw argv bytes, we could add another platform-independent function that does that. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Simon Marlow wrote: The following cases are currently broken... I propose to fix these (on Windows). It will mean that your second case above will be broken, until someone fixes getDirectoryContents... ...it's a lot easier on Windows... on Unix I don't have a clear idea of how to proceed... If someone else has a good understanding of what needs done, please wade in. I don't know how getArgs fits in here... I agree it's broken and needs to be fixed. OK, would you like me to reflect this discussion in tickets? Let's see, so far we have #3300, I don't see anything else. Do you want two tickets, one each for WIndows/Unix? Or four, separating the FilePath and getArgs issues? On Unix, all file APIs take [Word8]... So we should probably be converting from FilePath to [Word8] by encoding using the current locale... what about encoding errors, Where relevant, we should emulate what the common shells do. In general, I don't see why they should be different than any other file operation error. and what if encode.decode is not the identity due to normalisation Well, is it common for people using typical input methods and common shells to create file paths containing text that decodes to non-normalized Unicode? I'm guessing not. If that's the case, then we don't really have to worry about it. People who went out of their way to create a weird file name will have the same troubles they have always had with that in Unix. But perhaps a better solution would be to make the underlying type of FilePath platform-dependent - e.g., String on Windows and [Word8] on Unix - and let it support platform- independent methods such as to/from String, to/from Bytes, setEncoding (defaulting to the current locale). That way, pass-through file paths will always work flawlessly on any platform, and applications have complete flexibility to deal with any other scenario however they choose. It's a breaking change though. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
Ketil Malde wrote: If we want to incorporate a translation layer, I think it's fair to only support UTF-8 (ignoring locales), but provide a workaround for invalid characters. I disagree. Shells and GUI dialogs use the current locale. I think most other modern programming languages do too, but correct me if I am wrong. Still, your ideas about dealing with decoding errors sound useful. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Unicode workaround for getDirectoryContents under Windows?
I wrote: OK, would you like me to reflect this discussion in tickets? Let's see, so far we have #3300, I don't see anything else. Do you want two tickets, one each for WIndows/Unix? Or four, separating the FilePath and getArgs issues? Simon Marlow wrote: One for each issue is usually better, so four. OK, they are: #3300, #3307, #3308, #3309. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Breaking ghci
Günther Schmidt wrote: ...*I* have managed to write code that ghc is not even able to compile due to exhausting virtual memory! Top that! Good work Günther! Joe Fredette wrote: Code or it didn't happen. :) Yes, how did you do it? Did it involve very large literals? GHC is known to have some limitations with that. For example, on my machine, a String literal that is larger than about 1 Gb will cause GHC to overflow the RTS stack. And a list literal with only a few thousand elements can cause GHC to suck up all memory and bring my computer to its knees. Examples: choke1 = \ \0123456789abcdef\ \0123456789abcdef\ . . . \ choke2 = [ 0,1,2,3,4,5,6,7, 0,1,2,3,4,5,6,7, . . . 0,1,2,3,4,5,6,7, 99] Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Leaner Haskell.org frontpage
Don Stewart wrote: Newbies: http://haskell.org Everything regular users need at fingertips http://dashboard.haskell.org/ That's fine. But please, no matter how minimalist the newbie page, make sure that there is a clear and prominent link there to the advanced page. Otherwise, if I happen to be somewhere without my bookmarks, it will take me a lot of fumbling in the dark to find it. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] powerSet = filterM (const [True, False]) ... is this obfuscated haskell?
Thomas Hartman wrote: on haskell reddit today powerSet = filterM (const [True, False]) is said to be beautiful / mind blowing. Is this a uniquely haskell obfu, or is there a way of reading this definition that makes sense? To me, these are more obvious: powerSet = map catMaybes . mapM ((mzero:).return.return) powerSet = map concat . mapM ((mzero:).return.return) They work by pretty much the same principle. Perhaps they seem simpler to me only because I use mapM a lot more than I use filterM. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Ambiguous type variable - help!
Hi Phil, I'm trying to work out how to handle a choice at runtime which determines what instance of a State monad should be used. First of all, you should realize that you'll almost never want to do something like that in Haskell. In my opinion, if you're coming from an OO language, you should ban yourself from defining Haskell classes or using existential types until you are completely comfortable with how different Haskell is from OO. You can get along fine without them. I've concocted a very simple example to illustrate this (below) - but it doesn't compile because ghc complains that my type is ambiguous arising from my use of 'fromSeq'. Notice that you have given two completely separate sets of instructions of what to do depending on whether Int or Double is selected. You have not given any indication of how to choose between them, even at runtime. Of course, the compiler doesn't care that your string constants Int and Double happen also to be the names of types if unquoted. The way you avoid boilerplate in Haskell in these kinds of cases is by using polymorphism. Note that there could still remain a small amount of boilerplate - you move the actual hard work into a single polymorphic function, but then you may still need to mention that function once for each type. If that bothers you, there are more advanced tools to get rid of that last bit of boilerplate, like Template Haskell or Scrap Your Boilerplate. Below is one way to fix up your example, with a few other minor bits of polish. Regards, Yitz import Control.Monad.State -- Why Strict? Haskell is lazy by default. data SeqType = SeqInt Int | SeqDouble Double class SequenceClass a where nextSeq :: State a Int instance SequenceClass Int where nextSeq = State $ \s - (s, s + 1) instance SequenceClass Double where nextSeq = State $ \s - (truncate s, s + 1) chooser :: String - SeqType chooser inStr | inStr == Double = SeqDouble 1 | otherwise = SeqInt 1 -- Here is the polymorphism. -- Make this a function so that we can move it -- out of main. result :: SequenceClass a = a - [Int] result = evalState $ replicateM 10 nextSeq -- Here is the only boilerplate needed printResult :: SeqType - IO () printResult (SeqInt i)= print $ result i printResult (SeqDouble x) = print $ result x main :: IO() main = do userInput - getLine printResult $ chooser userInput -- or you could just say -- main = getLine = printResult . chooser ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Getting highest sum of list elements with Map
Hi Gwern, gwern0 wrote: ...efficiency is an issue. Here are a few efficiency issues that I noticed in your algorithm after a quick look (none of these have to do with Haskell really): o ranks sorts the entire set, then discards all but the maximum. It would be better to use maximum or maximumBy. If you are worried about the empty set, check that separately. o You recompute the same rank value repeatedly for every word in each sentence. Use a let clause in your list comprehension to do it only once per sentence. o approximation rescans the entire corpus after discarding each word. Try to think of a way to recompute only those sentences that contained the word. Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
I agree with most of Alexander's many thoughtful comments about Don's list of potential additions to HP. But I disagree about pandoc. Alexander Dunlap wrote: No. Pandoc is too actively developed to go into the HP. It depends on the nature of the development. If the API is currently very unstable and is expected to stabilize soon, then wait a little bit. Otherwise, that is no excuse to exclude something worthwhile. Choose a well-tested numbered version and include it. Later, if we want to upgrade, just follow the usual deprecation-upgrade process. Umm - we do have a well-defined deprecation-upgrade process, don't we? It's also much more of an end-user application than a standard library pandoc provides an extensive library, and also a command-line app. Is it a policy that in such a case, we require the command-line app to be split off into a separate package before we can include it? I'm not sure that's so important, but if so, it should not be hard to do that for pandoc. its applications are not general enough to be included in the standard distribution. Text with markup is used in some way for almost every application. This library provides tools to convert between a wide variety of markup formats. Sounds pretty general to me. Other batteries included platforms contain various tools for processing markup that are far less general than pandoc. This is a place where Haskell can shine. So yes, pandoc should definitely be included in the platform. All that said, though, I will certainly agree that it is not currently in the top 5. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Efficient functional idiom for histogram
Dmitry Olshansky wrote: My measurements show that... (-O2 gives approx 2 time impovements). ...using RandomGen and State monad to generate a list gives at least 4 times improvements (on 1 000 000 items). You earlier said: this takes over twice as long as a naively implemented Python program So now our naive Haskell - ordinary usage of Data.Map and System.Random, without resorting to things like unboxed arrays - is beating naive Python handily. Correct? Or is this with an alternate RNG? Although I think even that would be fair, since Python uses Mersenne. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Thinking about what's missing in our library coverage
Tom Tobin wrote: As I understand it, Pandoc is entirely under the GPL (not LGPL). Oh. That would be an issue, yes. Too bad. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?
Peter Verswyvelen wrote: Several libraries define their own codes for they keyboard (GLFW, GTK, GLUT, etc) Maybe it would be nice to agree on a standard datatype for keys? This might also include digital buttons on a joystick, etc... The Windows API has virtual key codes for this. X windows key symbols are used extensively in XMonad. They are found in the X11 package, in the modules Graphics.X11.Types and Graphics.X11.ExtraTypes. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Suggestion: define a standard keyboard codes library?
Peter Verswyvelen wrote: Several libraries define their own codes for they keyboard (GLFW, GTK, GLUT, etc) Maybe it would be nice to agree on a standard datatype for keys? ...The Windows API has virtual key codes for this. I wrote: X windows key symbols... are found in the X11 package But should we use X11 as the standard library then, even on Windows or Mac? Certainly not. X11 has its own philosophy of key virtualization. You would likely encounter serious impedance mismatch on other platforms. Maybe splitting these keys into a separate package would be a good idea? No, they are an integral part of X. I would assume the same is true for WinAPI VKeys, and whatever the corresponding thing is on the Mac. That probably explains why each graphics framework defines its own concept of key mapping, to match its own concept of platform dependence. Here's an example: suppose you want ^C to be copy in your app. Well, what if the user currently has a Dvorak layout - do you really want ^C, or do you want the third physical key to the right of the left shift key? And what if the current keyboard layout is Russian - which Cyrillic letter should be copy? And what if we happen to be on a mobile device or a tablet? Etc. Each platform addresses these issues in its own way, so the concept of a key code doesn't necessarily translate directly from one to the other. I don't think that key binding is so complicated that it's impossible to come up with a reasonable one ring that binds them all library. But it's not so simple as just lining up key code charts with one another. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ``Orphan instances'' should be avoided anyway.
Moving from libraries to haskell-cafe... I wrote: ...there must be some way to control the import and export of instances, just as we can now control the import and export of every other kind of symbol binding. Henning Thielemann wrote: For me it's most often the case that an instance is missing. If there is no way to change existing instance definitions, then you must use 'newtype'. Yes, in that case newtype is a work-around, often messy. Generalized newtype deriving simplifies to adapt the instances you want. That's only one part of it. Using a newtype can sometimes spew wreckage all over the place. But a more difficult case is when you need to use two libraries that already define conflicting instances. That requires a newtype plus however many adaptor functions you need, all inside a wrapper module. What a mess. These cases are likely to arise most often in large software projects. So there hasn't been a big enough demand yet for this feature to be implemented in any compiler, resulting in it being rejected from Haskell', unfortunately. But for large projects it has to work the other way around - the language features need to be there already for the language to be adopted for the project. Or to keep project managers from cursing themselves later on if they do choose Haskell. Anyway, I find the current behavior to be ugly and unintuitive. Why is it that when I say import Control.Monad.Error (throwError, runErrorT) there is no way to prevent also getting a surprising Monad Either instance? Never mind how things should have been named in Control.Monad.Error - that's the way it is right now. I need to be able to import the module without getting the instance. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] permutations and performance
John D. Ramsdell [EMAIL PROTECTED] wrote: I tried to replace a permutation generator with one that generates each permutation from the previous one, in a stream-like fashion. I had hoped the stream-based algorithm would be more efficient because I use only one permutation at a time, so only the permutation and the previous one need be in memory at one time. I thought I'd share the results of testing the two algorithms. Yes, thanks for the interesting discussion. You may also be interested in the following recent thread: http://www.haskell.org/pipermail/libraries/2007-December/008788.html There, Twan van Laarhoven designs the implementation of the permutations function that is slated to be included in GHC 6.10. That implementation is pretty well tweaked for speed, while satisfying the following condition suggested by David Benbennick: map (take n) (take (factorial n) $ permutations [1..]) == permutations [1..n] It's also interesting that this function has an unusually long history for computer science. Some of the best algorithms were first discovered by English church bell ringers nearly 400 years ago. Knuth discusses permutations in Volume 4 Fascicle 2. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't this work?
Alfonso Acosta wrote: I haven't tried to run the code, but my first bet is that, due to the rank-2 polymorphism of ST, you should use parenthesis instead of $ in the case of runST. Perhaps if Andrew is using an old compiler. That is no longer a problem in recent versions of GHC. A more basic issue is that fn is in the IO monad, but its use inside the mapM will need it to be in the ST monad. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't this work?
I wrote: A more basic issue is that fn is in the IO monad, but its use inside the mapM will need it to be in the ST monad. Daniel Fischer wrote: No, return (fn particle) :: ST s (IO ()) , so that's fine. Ah, true. But I doubt that Andrew really meant to do the calculation in ST s (IO ()). Indeed, filling in a few dummies, the code compiles with the 6.8 branch. So then the only way to know why it didn't compile for Andrew is if we see more of the code. But that's only a technical issue. I hope that now Andrew has a better idea about what's wrong. If not - please let us know. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 2 modules in one file
Maurício wrote: Is it allowed to write two different modules in a single file? That would be a really nice feature, especially since modules are Haskell's only encapsulation tool. You want it to be a lightweight as possible. Malcolm Wallace wrote: Some compilers permit it (e.g. Freja), most do not (e.g. ghc). The Language Report makes no specification for the mapping between module sources and the files that contain them. The Hierarchical Module Namespace Extension addendum to the Haskell 98 Report http://www.haskell.org/hierarchical-modules/ recommends, but does not require, a Java-like mapping between hierarchical module names and and the filesystem. In particular, compilers complying with that recommendation require there to be only one module per file. Most compilers do comply. In my opinion, that is a bad policy. It is fine as a simple default for small projects, even though it's a bit ugly and ad hoc. (For example - what does this mean on platforms whose filesystem is not hierarchical?) But for large and complex projects, this policy really complicates the task of the project manager who wants to be able to present various views of the source to teams working on different subprojects, while juggling the version control in an intelligent way. Directory tree structure is sometimes the perfect tool for that, but Haskell has stolen it away. It would be nice if compilers would offer, as an optional alternative, a system of locating modules based on manifest files. That would then allow multiple modules per source file. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 2 modules in one file
I have submitted this as Feature Request #2550 http://hackage.haskell.org/trac/ghc/ticket/2550 Please add any comments as appropriate. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level -
Lennart Augustsson wrote: I don't think anyone has claimed that any interface can be implemented without globals. Of course some can't (just pick an interface that is the specification of a global variable). What I (and others) claims is that such interfaces are bad. Using a global variable makes an assumption that there's only ever going to be one of something, and that's just an inflexible assumption to make. Not true, it's an idiom that comes up often enough. The right way to do these kinds of things is to provide some sort of context around the calling function. Something like withAcquiredResource $ \handle - do ... You (and others) are right that this is better than trying to keep global state in the context of the called function. The problem is that it is not always possible. There are situations in which you simply cannot make demands on a prior context. One important example is when refactoring a single component within an existing mature system. Another is when writing a library for general use if such demands on the calling context seem onerous for the service that the library provides (this latter is the situation for Data.Unique, according to many opinions). I find that Haskell's composability properties help it to outshine any other development environment I know. Experience shows that this is eventually true even for IO related issues - but those generally take a lot more work to discover the right approach. I feel that here we are still working on tackling the awkward squad. However we work that out, right now we need a working idiom to get out of trouble when this situation comes up. What we have is a hack that is not guaranteed to work. We are abusing the NOINLINE pragma and assuming things about it that are not part of its intended use. We are lucky that it happens to work right now in GHC. So my proposal is that, right now, we make the simple temporary fix of adding an ONLYONCE pragma that does have the proper guaranteed sematics. In the meantime, we can keep tackling the awkward squad. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level -
Lennart Augustsson wrote: As I said earlier, global variables may be necessary when interfacing with legacy things (software or hardware). By prior context I didn't mean legacy languages. I meant logically prior - enclosing contexts. It will always be necessary on occasion to refactor code without having any access to the enclosing context. If that refactoring happens to include acquiring an external resource once, using it while our program is running, and releasing it at the end, it is currently an awkward situation for us. We're working on finding a fitting solution to this. The Haskell philosophy has always been to stick it out until someone comes up with the right solution to a problem rather than picking some easy way out. So I'd rather keep global variables being eye sores (as they are now) to remind us to keep looking for a nice way. I agree. But the eyesores do need to be guaranteed to work. That is not currently the case. It's easy to fix the eyesores, so I think we should do that now. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] It's not a monad - what is it? looking for nice syntactic sugar, customizable do notation?
Marc Weber wrote: (3) Third idea: xmlWithInnerIO - execXmlT $ do xmlns http://www.w3.org/1999/xhtml; lang en-US xml:lang en-US head $ title $ text minimal body $ do args - lift $ getArgs h1 $ text minimal div $ text $ args passed to this program: ++ (show args) I still think that (3) would be superiour.. Is there a way to define my own = and functions such as: There is also the combinator approach of Text.Html, which gives you a syntax similar to (3) but without abusing do: (rootElt ! [xmlns http://www.w3.org/1999/xhtml;, lang en-US xml:lang en-US]) $ concatXml [head $ title $ text minimal ,body $ concatXml [h1 $ text minimal ,div $ text $ args passed to this program: ++ (show args) ] ] You use concatXml (it's concatHtml in the library) followed by a list, instead of do, for nesting. (Also, it's stringToHtml instead of text in the library.) A few more brackets, but still pretty clean. Also, you'll have pass in your args from somewhere else, in the IO monad - which is probably a better design anyway. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] It's not a monad - what is it? looking for nice syntactic sugar, customizable do notation?
Oops, needed to convert one more into a comma: (rootElt ! [xmlns http://www.w3.org/1999/xhtml; ,lang en-US ,xml_lang en-US ]) $ concatXml etc. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What monad am I in?
Henry Laxen wrote: Have I, like Monsier Jourdain, been running in the IO monad all my life, and didn't even know it? Marc Weber wrote: Sure... But the ghci error message is another one: Try this: :set -XNoMonomorphismRestriction And I highly recommend putting that line in your .ghci file. There is controversy about whether MR is helpful in general. It is on by default, so I just leave it that way, and it seems to be fine. But at the GHCi prompt, MR is definitely a nuisance. Get rid of it there by using :set in your .ghci file. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [haskell-cafe] Monad and kinds
Ramin wrote: ...no matter how many tutorials I read, I find the only kind of monad I can write is the monad that I copied and pasted from the tutorial... I am writing a mini-database... The query itself is stateful... The query may also make updates to the records. I also thought of trying to re-write my query algorithm to somehow use Control.Monad.State.Strict instead of my own query type, but then I wouldn't get to write my own monad! Just Control.Monad.State should work fine. Daniel Fischer wrote: But this looks very much like an application well suited for the State monad (or a StateT). So why not use that? I agree with Daniel. If you want to learn about the deeper theory of the inner workings of monads, that's great - go ahead, and have fun! But to solve your problem in practice, you don't need that level of knowledge. All you need to know about is get, put, modify, and liftIO. The StateT monad is really simple to use. In general, practical software is higher quality when it uses existing standard libraries. There is no more reason to re-invent the StateT monad than there is to re-invent anything else in the libraries. Among the multitude of monad tutorials out there, I wonder how many of them draw a clear line between what you need to understand to design monads, and what you need to understand just to use them. There's a huge difference in complexity. Like most things, it is best to use monads for a while and get comfortable with them before trying to learn how to design them and build them. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level -
Ashley Yakeley wrote: Currently Data.Unique uses the NOINLINE unsafePerformIO hack to create its MVar. If hs-plugins duplicates that MVar, that's a bug in hs-plugins. Sittampalam, Ganesh wrote: Also, the definition of NOINLINE in the report doesn't preclude copying both the MVar *and* its use sites, Right. It would not be a bug in hs-plugins. That is the most urgent problem right now. It is nice to discuss various proposed new language features. That is the way to solve the problem in the long term. But right now - there is no way to do this in Haskell at all. The NOINLINE unsafePerformIO hack doesn't really work. This is currently a major hole in Haskell in my opinion. For the short term - can we *please* get an ONLYONCE pragma that has the correct semantics? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level -
I wrote: For the short term - can we *please* get an ONLYONCE pragma that has the correct semantics? Sittampalam, Ganesh wrote: So the purpose of this pragma would solely be so that you can declare hs-plugins buggy for not respecting it? No, the hs-plugins problem - whether hypothetical or real - is only a symptom. There is no way to define global variables in Haskell right now. The NOINLINE hack is used, and most often works. But really it's broken and there are no guarantees, because NOINLINE does not have the right semantics. This is demonstrated by your hs-plugins example, but it's a general problem. Until a permanent solution is implemented and deployed in the compilers (if ever), can we please have a pragma that allows the current hack to really work? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level -
For the short term - can we *please* get an ONLYONCE pragma that has the correct semantics? Sittampalam, Ganesh wrote: How do you propose that this pragma would be implemented? As far as I know now, in GHC it could currently just be an alias for NOINLINE, but the GHC gurus could say for sure. Except it should require a monomorphic constant - otherwise the guarantee doesn't make sense. And it would have clear comments and documentation that state that it guarantees that the value will be computed at most once. That way, bugs could be filed against it if that ever turns out not to be true. Other applications and libraries that support the pragma - such as other compilers, and hs-plugins - would be required to respect the guarantee, and bugs could be filed against them if they don't. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: [Haskell] Top Level -
I wrote Other applications and libraries that support the pragma - such as other compilers, and hs-plugins - would be required to respect the guarantee, and bugs could be filed against them if they don't. Sittampalam, Ganesh wrote: If hs-plugins were loading object code, how would it even know of the existence of the pragma? Given such knowledge, how would it implement it? Good point. A compiler pragma is only that, in the end. This is just a hack, we can only do the best we can with it. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: protocol-buffers-0.2.9 for Haskell is ready
Chris Kuklewicz wrote: Who can suggest a way to cast from Float to Word32 and Double to Word64 using ghc? The actual task is that I need to write out the Float as a little endian sequence of four bytes and also be able to read it back in. The writing and reading are done in Put and Get monads to ByteString (from the binary package). I think alloca-like hacks is really the wrong direction and asking for trouble. You are trying to translate between platform-dependent native floats, and IEEE floats in a specified platform-independent binary format for Google. So use encodeFloat/decodeFloat - fast primitives in GHC - on the native side, and a hand-written Binary instance for the exact format you need on the Google side. My opinion, YMMV. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What I wish someone had told me...
Derek Elkins wrote: In general, to encode OO... turns out all you needed was recursive bounded existential quantification. Do you have a reference for that? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] generalized list comprehensions
Derek Elkins wrote: As far as I can tell, no one actually uses parallel list comprehensions. With any luck, the same will be true for generalized list comprehensions. I second this. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] k-minima in Haskell
\begin{code}
kmin :: Ord a = Int - [a] - [Int]
kmin k x = map snd $ Set.toList $ foldl' insertIfSmall (Set.fromList h) t
where
(h, t) = splitAt k $ zip x [0..]
insertIfSmall :: Ord a = Set.Set a - a - Set.Set a
insertIfSmall s e
| e mx= Set.insert e s'
| otherwise = s
where
(mx, s') = Set.deleteFindMax s
\end{code}
This gives O(log k * (n + k)) execution in constant memory.
If you need the result indices to be in order, you can put in
a sort at the end without changing the complexity.
This could be improved by a significant constant factor
by using a priority queue instead of Set. Any Edison people
out there?
Regards,
Yitz
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] k-minima in Haskell
\begin{code}
kmin :: Ord a = Int - [a] - [Int]
kmin k x = map snd $ Set.toList $ foldl' insertIfSmall (Set.fromList h) t
where
(h, t) = splitAt k $ zip x [0..]
insertIfSmall :: Ord a = Set.Set a - a - Set.Set a
insertIfSmall s e
| e mx= Set.insert e s'
| otherwise = s
where
(mx, s') = Set.deleteFindMax s
\end{code}
This gives O(log k * (n + k)) execution in constant memory.
If you need the result indices to be in order, you can put in
a sort at the end without changing the complexity.
This could be improved by a significant constant factor
by using a priority queue instead of Set. Any Edison people
out there?
Regards,
Yitz
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Weaving fun
Back to the original problem for a moment.
\begin{code}
import qualified Data.Sequence as Seq
import Data.Sequence ((|), ViewL((:)))
weave :: [[a]] - [a]
weave = weaveSeqL . Seq.viewl . Seq.fromList
where
weaveSeqL ((x:xs) : s) = x : weaveSeqL (Seq.viewl $ s | xs)
weaveSeqL _ = []
\end{code}
Yes, it also weaves infinite lists.
Regards,
Yitz
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] darcs error
Ruben Zilibowitz wrote: What does it mean if I'm trying to check out a darcs repository and I get the following error? darcs: ./.DS_Store: openBinaryFile: does not exist (No such file or directory) If you are doing darcs get from a partial repo and you did not use --partial, then this sounds like: http://bugs.darcs.net/issue145 The darcs users list would be more appropriate for this question. http://lists.osuosl.org/mailman/listinfo/darcs-users More info about darcs on www.darcs.net. Regards, Yitz ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: 'Proper' use of the State monad
DavidA wrote: What I mean is, it seems like good design would mean that you could write and test the game logic totally independently of any IO. Game functions such as makeMove ought to have type signatures that don't involve any IO. Can this be achieved in option 2? Here is one way: For functions that do not need IO, use types that look like: MonadState GameState m = ... - m a For functions that only do IO without refering to the game state, use: MonadIO m = ... - m a For functions that do both, use: (MonadIO m, MonadState GameState m) = ... - m a Testing of the pure game functions can use State GameState, testing of pure IO functions can use IO, and production can use StateT GameState IO. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell Library on CNN
Border conditions in the Haskell Library have finally made the mainstream media: http://www.cnn.com/2007/US/05/26/border.quirk.ap/index.html -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] unfoldr [ANN: HLint 1.2]
Andrew Coppin wrote: Does it suggest unfoldr too? I think Neil's idea to have this customizable is a good one. It's often a matter of taste. I would rarely want to use unfoldr, and I wouldn't want HList to bother me about it. Instead, I prefer to use iterate for both of Andrew's examples: convert b 0 = [] convert b n = n `mod` b : convert b (n `div` b) convert b = unfoldr (\n - if n 0 then Just (n `mod` b, n `div` b) else Nothing) convert b = map (`mod` b) . takeWhile ( 0) . iterate (`div` b) heap_to_list = unfoldr (\h - if heap_empty h then Nothing else Just (heap_top h, heap_delete_top h)) heap_to_list = map heap_top . takeWhile (not . heap_empty) . iterate heap_delete_top Here is one case where I actually do use unfoldr: -- Mine free-form user input for occurrences of a data type readMany = unfoldr $ listToMaybe . concatMap reads . tails ghci readMany The numbers are 3, 7, and 42. :: [Int] [3,7,42] But I don't believe HLint should be expected to come up with something like that. It's quite rare. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: hs-dotnet, version 0.3.0
Sigbjorn Finne wrote: the first public release of hs-dotnet is now available Fantastic accomplishment! I can only repeat dons' comment - this could be game-changing. Some obvious questions that come to mind: We see that it is already possible to expose a Haskell function to .NET as a callback. That's exciting! Can we go to the next step and register it as part of an assembly? Is it be possible for a running .NET app to fire up the GHC runtime and call into compiled Haskell? Is it possible at all for a .NET function not to have any side effects? If so, is there any way to label it as such and then call it from Haskell outside of the IO monad? Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and C++ program
Sukit Tretriluxana: I was looking around Stroustrup's website and found a simple program... I wondered how a Haskell program equivalent to it looks like... main = E.catch (interact reverseDouble) (\_ - print format error) toDoubles = map (read::String-Double) For a safe program in Haskell, we would not normally use an unsafe function like read, and then try to rescue it by catching IO exceptions. Instead, we would write the program safely to begin with. Something like this (building on Jonathan's idea): import Data.Maybe (listToMaybe) main = interact reverseDouble reverseDouble = unlines . intro . maybe [format error] (map show . reverse) . mapM (readMaybe :: String - Maybe Double) . takeWhile (/= end) . words where intro l = (read ++ show (length l) ++ elements) : elements in reversed order : l readMaybe :: Read a = String - Maybe a readMaybe = listToMaybe . map fst . reads The function readMaybe returns the pure value Nothing if there is a format error instead of throwing an IO exception. It has been proposed to make it part of the standard libraries - I'm not sure what the status is of that process. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts wrote: We want to let random users on random platforms submit simple anonymous build reports (no logs)... The only downside compared to a more centralised system is that we do not get to centrally monitor the status of the dedicated build clients. And that we open ourselves up to some serious security concerns - like hostile build reports and DOS. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts wrote: let random users... submit... build reports... I wrote: ...we open ourselves up to... hostile build reports and DOS. Manlio Perillo wrote: DOS is always a problem, for every application open to the Internet. Yes. But I didn't mean just generic flooding. I meant abusing the effect of build reports to create a DOS. As for hostile builds reports, I don't see it as a security concern. Hostile build reports could effectively remove a package from hackage. Or bless a faulty package, causing problems on other people's systems. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] real haskell difficulties (at least for me)
Duncan Coutts wrote: Detailed build reports with logs are not anonymous, clients will need an account on hackage (ie username and password). Right. If we experience problems with that in the future, we just have to make sure that it won't be too hard to set up captcha. they'll either be obviously bogus Aren't we talking about an automated system? If we don't explicitly design for the possibility of hostile reports, any automated recognition will be trivial to circumvent. or drowned out by the volume of legit reports. Again, if this is automated, it is trivial generate the required volume. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] OS X build failure of Gtk2Hs from MacPorts
Jeff, I'm not sure if this is causing the problem you're referring to, but MacPorts is at GHC 6.10 while Gtk2Hs doesn't support that yet. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: list choices
Both of the points raised by Malcolm are a matter of personal preference, in my opinion. In fact, my own preference is the opposite of Malcolm's in both cases. Both of Malcolm's suggestions would rob me of filtering capability. Malcolm Wallace wrote: I would suggest that posting announcements *only* to haskell@, but with followups set to haskell-cafe@, is the ideal way to keep everyone informed... I am usually not interested in the posts to haskell - calls for papers and the like. So I receive it as a digest it and rarely look at it. Posts that interest me, such as announcements of new packages on hackage, tend to be cross-posted to haskell-cafe. That is ideal for me. ...it would reduce _so_ much irritation if all the haskell-related mailing lists could set the Reply-To header to the list, instead of defaulting to the original poster. I filter haskell-cafe traffic into a place where I can browse it if I have time. But when I am participating in a thread, I want its messages to pop up in my inbox. Forcing active threads to the inbox would take work (given my setup), and the result would be far less accurate. I appreciate people's efforts to include me in a conversation by mentioning me as a recipient. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MySQL and HDBC?
Duncan Coutts wrote: This was uploaded to hackage yesterday: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/HDBC-mysql-0.1 This is wonderful news! Whatever we might say about MySQL, it is so ubiquitous that this driver is really important for Haskell. Chris, please keep us up-to-date with your progress. Chris Waterson wrote: I would very much appreciate feedback. I'm still working with John Goerzen (who has been extremely helpful) to iron our some details, see [1] for a list of issues that you should be aware of before you start doing anything too serious... Well whatever John says will obviously take priority. But the following two points that you list are covered in the API docs on the main Haddock page for HDBC: http://software.complete.org/static/hdbc/doc/Database-HDBC.html o Transactions - if a connection does not support transactions, dbTransactionSupport should return False, and commit and rollback should raise errors. (SqlError I suppose?) Not warnings. o Threading - see the section at the bottom of the Haddock page for a nice specification of what the driver needs and does not need to support. Also - o Non-ASCIIText - OK for now, but MySQL has significant support for Unicode and encodings, so that should be on the to-do list. All of the rest of your to-do items sound great. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MySQL and HDBC?
Chris Waterson wrote: You probably already know this, but... you can mix tables from different storage engines in a single *statement*. Oh, no, I thought it was per database. Horrors! ...when a ROLLBACK has been issued against a non-transactional table... I could raise an error... perhaps this is preferable? John Goerzen wrote: ...what happens in the ODBC case depends on what the user puts in odbc.ini... either the full-on error treatment, or the ignoring the problem It does make sense for this to be configurable. In addition, you might want even more than the current full-on error mode: As Chris pointed out, throwing an exception at commit or rollback is a bit late - your data may already be destroyed by then. There should be a safe mode that raises an exception any time you try make a change to a non-transactional table, even before commit or rollback. That way, you would be able to write code like this: Start doing A in a new transaction. If any operation tries to make a change in a non-transactional table, roll back A and do B instead. Transactional safe mode could still allow reads of non-transactional tables. Is this possible for MySQL and/or ODBC? If you feel that the HDBC API needs to become more rich, I'm quite happy to entertain suggestions there Well, this makes a major difference in the meaning of a program. So it does seem that it should be possible at least to detect what is happening, or even control it programatically. In the case of a connection with less than guaranteed full support for transactions, you would want to be able to choose between the two behaviors available in the ODBC driver, or safe mode. Right now, the meaning of the dbTransactionSupport flag is ambiguous. Does True mean that full support for transactions is guaranteed? Or only that it might be supported for some tables? If not supported for some table, will the driver revert to irrevocable immediate changes, or raise an exception? Will silently ignore commit and rollback requests, or raise an exception? Even before the API becomes richer in this respect, the documentation should more clearly indicate the meaning of this flag (and drivers should then comply). Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: HDBC v2.0 now available
Duncan Coutts wrote: So in the next cabal-install release (which should be pretty soon now) configure will do the same thing and pick base 3 unless you specify build-depends base = 4. Niklas Broberg wrote: I really really think this is the wrong way to go. Occasional destruction is desperately needed for progress, else things will invariably stagnate. I disagree. Having everything fail... would have been a disaster... during the lifespan of base 4 we need to encourage new releases to start working with it... Doing that with warnings hints etc is the way to go. No, that's not good enough either. Existing packages will just stay with old versions to avoid the work, and new packages will then also use old versions for maximum compatibility. The incentive is not strong enough. Those warnings and hints must have teeth. Comparing with what has happened in other languages, which have stagnated or not stagnated at various rates, it is clear that what we need is a well-defined deprecation process. The warnings should say something like: you had better upgrade this, otherwise it will stop working in the next version. Both maintainers and users should be aware of this threat. That way, code that is maintained will not stop working. There will be plenty of time to make the change. Code that is used but not maintained will generate a hue and cry among the users that will hopefully motivate someone to do something about it. Code that is not maintained and little used will eventually be destroyed, but that code is probably bitrotting in any case. The deprecation process can be as slow and fine-grained as we like. But there must be a well-defined point in the future when old unmaintained code will be allowed to stop working. Destruction is not such a friendly approach. We do not need to make the users suffer When done carefully, gradually, and with plenty of warning (at least one full version cycle), destruction is indeed friendly and helpful. It allows users to understand precisely what versions should be used, and when, in old, current, and future projects, while permitting Haskell to march steadily onward. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskeline, pcre-light, iconv and Cabal on OSX
Thomas Davie wrote: This is caused by OS X's libiconv being entirely CPP macros, the FFI has nothing to get hold of. IIRC there's a ghc bug report open for it. Judah Jacobson wrote: The OS X system libiconv is actually OK; it's the MacPorts libiconv that has the CPP macros... Thanks for the report; I'm not sure of what the right solution is, but I opened a ticket on Haskeline's bug tracker Perhaps there should also be a ticket on MacPort's bug tracker? -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: The first difference is about a `mod` b, when a and b are Float types. Python use the fmod function, and it also implement divmod; Haskell seems to lack support for this operation. Yes, Haskell does not implement the full IEEE. There are differing opinions about that: some say we should add it all in, and some say we should take it all out. Floating point is ugly, but useful. It seems that enough of IEEE is implemented for the vast majority of applications, so far. The second difference is about the division of two integers. fac(777) / fac(777) 1.0 Here CPython does not convert the two integers to float before to divide them, but make use of a special algorithm. GHC, instead, returns NaN No, actually here Haskell shines. Perhaps this GHCi session will illuminate the issue for you: Prelude let fac n = product [2..n] Prelude fac 777 `div` fac 777 1 Prelude fac 777 / fac 777 NaN In Haskell, the various integral and floating point types are completely separate. The literal 777 is overloaded - its type is 777 :: Num a = a so it can be used for both integral and floating point types. But the division operators are separate: div :: Integral a = a - a - a (/) :: Fractional a = a - a - a So when you use 777 together with /, the 777 is interpreted as a Fractional (defaulting to Double). And when you use it with div, the 777 is interpreted as an Integral (defaulting to Integer). Hope this helps, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: The first difference is about a `mod` b, when a and b are Float types. Python use the fmod function, and it also implement divmod; Haskell seems to lack support for this operation. I wrote: Yes, Haskell does not implement the full IEEE. I spoke too soon. Data.Fixed.mod' supports this operation. I doubt that it is implemented via the IEEE primitive though. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: fac(777) / fac(777) 1.0 Here CPython does not convert the two integers to float before to divide them, but make use of a special algorithm. GHC, instead, returns NaN I wrote: No, actually here Haskell shines. Perhaps this GHCi session will illuminate the issue for you: Prelude let fac n = product [2..n] Prelude fac 777 `div` fac 777 1 Prelude fac 777 / fac 777 NaN No, this is not as complete as it is done in Python. The `/` operator *always* ...return a float... The `//` operator *always* perform a floor division. This happens for both integers and floats: If I'm correct, there is no operator/function, in Haskell, that perform an exact division between two integers and return a float: exactDiv :: (Integral a, Real b) = a - a - b exactDiv :: (Real a, Real b, Fractional c) = a - b - c x `exactDiv` y = realToFrac x / realToFrac y Python does that same type coercion automatically at runtime. This can sometimes make your code look a bit neater, but other times really gets in the way. I personally prefer the Python solution, where we have two operators with the same behaviour over all the numbers. If you really like exactDiv better, you can define an operator to do it for you. But most people don't. Haskell gives you total control, since the types of everything are strictly defined at compile time. This has the extra advantage of giving you a really powerful type checker that can find many of your bugs at compile time. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: No. I'm looking for... Manlio - can you describe exactly what you want? Do you know exactly what you want? You have said that you want division like in Python - but that even that is not well defined: Python 2.6.1 3/5 0 Python 3.1 3/5 0.59998 Please tell us *exactly* what you want your division to do, on integers and on floating point. Or tell us you want division like / in Python 3.1, or whatever. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: However there is still a *big* problem: it is inefficient. Here is a Python version of the Chudnovsky algorithm [1] for computing Pi: http://paste.pocoo.org/show/102800/ On my system it takes 10 seconds. Here is an Haskell version: http://paste.pocoo.org/show/102801/ On my system it takes 30 seconds. Ah, OK. Thanks. Now we have a well-defined problem. :) And that makes it clear that what you want is Python 3 division. Well, first of all, there are a few bugs in the Haskell version of your program - don't forget that unlike in Python, ranges in Haskell *include* the last number. Second, we should note that it is silly to compute 1000 terms in this sum. By the end, you are getting terms whose order of magnitude is 10 ^ (-15000). The Haskell version is spending a bit more time on those (useless) later terms. The reason is that in Haskell we are first reducing the fraction, then converting to Double. If you really did care about that amount of accuracy, you would leave the result as a Rational. Or as one of various other unlimited-precision floating point types that are available in Haskell libraries. This calculation in Haskell would take the same amount of time as it takes now. You would need to rewrite your Python program to do this, and I would guess it would run a lot slower. In our case, the Python division first does a quick estimate of the sizes of the two integers, and just returns zero if it sees that there will be underflow on conversion to double. So I made the following rough change to the Haskell: -- An exact division (/.) :: Integer - Integer - Double x /. y | y `div` x 5*10^323 = 0 | otherwise= fromRational $ toRational x / toRational y Now the Haskell runs in about half the time as the Python on my machine. Obviously, the Haskell could easily be further optimized. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: I'm looking for an exact integer division that avoids overflows, if possible. Richard O'Keefe wrote: What this sounds like to me is a request that the Prelude function 'fromRational' should work well... If you cannot divide two Integers n, d accurately using (fromRational (n Ratio.% d) :: Double) that casts doubt on the trustworthiness of floating point literals. No, that works fine: Prelude Data.Ratio fromRational $ (3*10^1000)%(2*10^1000+1) 1.5 Suppose we have a function decodeIntegerAsFloat :: RealFloat a = Integer - (Integer,a) such that if (s,m) = decodeIntegerAsFloat x then either x = 0 and s = 0 and m = 0 or x = m * 2**s (mathematically) and abs m \in [0.5,1.0). Yes, that is what Manlio wants. Sometimes you need to divide two very large Integers with a floating point number as result, without the overhead of constructing a Rational from them. Then integer_ratio_as_float :: Floating a = Integer - Integer - a integer_ratio_as_float p q = (mp/mq)*(2.0^(sp-sq)) where (sp,mp) = decodeIntegerAsFloat p (sq,mq) = decodeIntegerAsFloat q You'd actually use scaleFloat; if the difference sp-sq is outside the range of Int the answer is going to be a signed zero or a signed infinity anyway. You have just duplicated the CPython interpreter source code snippet that Manlio linked to. decodeIntegerAsFloat would sit very well in the RealFloat class alongside its model, decodeFloat. It has other uses. I agree, though I'm not sure it needs to be a method. For example, you can use it to compute logarithms of Integers with much less worry about overflow. Actually, efficient integer-valued logarithms for Integers are exactly what you need to implement decodeIntegerAsFloat. Best would be if we could just read that off from the internal representation of an Integer. Would you like to file a GHC issue for that? In the meantime, we could already expose the integer log function in a library using an efficient algorithm. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about integer and float operations
Manlio Perillo wrote: By the way, in GHC.Float there is a (private): integerLogBase :: Integer - Integer - Int Yes, I have needed this function many times. Too bad it is not exposed. In this case, though, we only need base 2. For that, it would be nice if we could just read it directly from the internal representation of the Integer. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Just how unsafe is unsafe
Peter Verswyvelen wrote: I do have asked myself the question whether a really random generating function could be regarded as pure somehow Not really. Somewhere in your program you are likely to make the assumption that a value you obtained, however indirectly, from this function will be the same in two different places. But the sands will constantly be shifting. Furthermore, in real life physical RNGs also involve state, because they need to accumulate entropy. For example, in Unix (on many platforms), the physical RNG device /dev/random will block until there is enough entropy to provide a random number. The /dev/urandom device always returns a number immediately, but that is because it will return a pseudo-random number if there is not enough entropy available, again requiring state. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Just how unsafe is unsafe
Peter Verswyvelen wrote: I do have asked myself the question whether a really random generating function could be regarded as pure somehow I wrote: Not really... Alberto G. Corona wrote: What is pure randomness? .When the algorithmic complexity of the list of random number is equal to the lenght of the list, that is, is incompressible by any means. But this can not be probed. the distribution of values gives a hint of whether if the list obey any algorithm, but even so, many compressible series have a random distribution. in practical terms, it is random has a random distribution, the receiver does not know the algorithm AND the initial value. In this case it can be pure. Perhaps philosophically you can consider it pure, but it is unsafe to treat it as pure in your program. If you write x = genRandomR (1, 100) then the compiler may or may not replace the variable x by the function application genRandomR (1, 100) anywhere in your program. That is probably not what you want. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] random shuffle and random list partition
Hi Manlio, Manlio Perillo wrote: For my Netflix Prize project I have implemented two reusable modules. The first module implements a random shuffle on immutable lists... The second module implements a function used to partition a list into n sublists of random length. Very nice! If someone is interested (and if Oleg give me permission), I can release them as a package on Hackage. Please do that. While I think Oleg's tree method is beautiful, in practice it may be re-inventing the wheel. I haven't tested it, but I doubt that this implementation is much better than using the classical shuffle algorithm on an IntMap. It's essentially the same tree inside. That's what I usually use for this, and it works fine. In future I can add an implementation of the random shuffle algorithm on mutable arrays in the ST monad. I've tried that in the past. Surprisingly, it wasn't faster than using trees. Perhaps I did something wrong. Or perhaps the difference only becomes apparent for huge lists. As you point out, your partition algorithm is not fair. Using your Random.Shuffle and a well-know trick from combinatorics, you can easily get a fair partitions function: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=2485#a2495 Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need an overview of FP-related research topics
I spoke to a faculty member in a decent Computer Science department in which no one has ever done anything related to FP. (You may say that is an inherent contradiction, but what can I do, the department does have a good reputation. I am withholding names to protect the innocent.) This faculty member happens to be the one who was forced to teach the single programming languages course offered by the department, due to his having the least seniority in the department. As such, he is now actually starting to become a bit interested in FP and Haskell. I gave him a few links to Haskell resources, which he appreciated. But coming from more of a pragmatic non-research point of view, I didn't really know what to say. The best I could do was to point him to the Haskell Wikibook, and to the Why FP Matters paper. I would like some links that would give such a person a nice overview of the various active areas of FP-related research these days, leaning towards Haskell. I want to give him a fairly broad view of what is interesting and exciting, why various topics are important, where to find ideas for collaboration and applications to other areas, etc. I actually know about a few departments like that. This could be a good strategy for drumming up more research interest in Haskell. In some cases, the person in question has already been influenced somewhat by the lisp fanatics, so I would like some help in how to deal with that also. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Query on list comprehension
Melanie_Green writes: I want to use listcomprehension to output the pattern below... Jón Fairbairn wrote: Why do you want to use list comprehensions? What if they aren't the best way of getting the result you want? unlines . tail . inits . repeat $ 'a' concat [replicate n 'a' ++ \n | n - [1..]] Or: unlines [replicate n 'a' | n - [1..]] -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need an overview of FP-related research topics
I wrote: I would like some links that would give such a person a nice overview of the various active areas of FP-related research these days... Bernie Pope wrote: Some ideas off the top of my head... Thanks, that's exactly what I was looking for. Also, thanks to Sean for suggesting the History paper. I sent it on, hope it does the trick :) Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Manlio Perillo complained about: buildPartitions xs ns = zipWith take ns . init . scanl (flip drop) xs $ ns Miguel Mitrofanov wrote: takeList = evalState . mapM (State . splitAt) Ha! Bravo! As the author of the offending zipWith/scanl version, I can say that love those State monad one-liners. However, ironically, I stopped using them for pretty much the same reason that Manlio is saying. The difference is that zipWith and scanl are classic Haskell idioms that any Haskell programmer will learn fairly early on. Whereas State monad one-liners used to be thought of as new and fancy and esoteric. But now they are becoming more mainstream, so perhaps I should go back to them. So the bottom line is that Manlio is right, really. It's just that Haskell is still very different than what most programmers are used to. So it does take a while to get a feeling for what is too smart. Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] about Haskell code written to be too smart
Miguel Mitrofanov wrote: takeList = evalState . mapM (State . splitAt) I wrote: However, ironically, I stopped using them for pretty much the same reason that Manlio is saying. Dan Piponi wrote: Are you saying there's a problem with this implementation? It's the only one I could just read immediately... It says exactly what it means, almost in English. Yes, I agree. But at a time when the majority of experienced Haskellers couldn't easily see that because they weren't comfortable enough with the State monad, using it would have cost more on average (for debugging, refactoring, etc.). Whereas now I don't think that's a problem anymore. Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Delivery to haskell-platf...@projects.haskell.org
After a reboot, community.haskell.org is now responding again on port 25. Please check to see if the mailing lists are working again. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Delivery to haskell-platf...@projects.haskell.org
Erik de Castro Lopo wrote: ...my mail server is rejecting the message coming back to me... Nun.haskell.org really should have a reverse DNS entry Ah, that is probably a casualty of the recent upgrade of the haskell.org server. As part of that process, control of the domain was moved from Yale to the community. I think someone at Galois is admin for the domain now, I'll see if I can get them to put the reverse DNS back in. I'm also creating a support ticket for community.haskell.org and taking the liberty of making you the requestor. Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] IsString instances for attoparsec-text
Hi Felipe, Thanks so much for implementing the attoparsec-text package. Could you please add an IsString instance for Parser Text, parallel to the one in attoparsec? You may have missed this because of it being an orphan instance in attoparsec. It should be something like: instance IsString (Parser T.Text) where fromString = string . T.pack Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Using IsString with attoparsec
Using the IsString instance for Parser in attoparsec is really nice, but unfortunately, you can't use it out of the box for the most common case. One would like to be able to write parsers in this style: ( * stuff * ) But the types of * and * are too general - there is no way for the type checker to figure out which instance of IsString to use for the discarded parameter. I suggest adding the following type-specialized variants to Data.Attoparsec.Char8: (*.) :: Applicative f = f a - f ByteString - f a (*.) = (*) (.*) :: Applicative f = f ByteString - f a - f a (.*) = (*) Once attoparsec-text gets its IsString instance, I would add the same thing to Data.Attoparsec.Text, with ByteString replaced by Text. I have been using those for both attoparsec and attoparsec-text, and I find them extremely useful. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Ranges show error
Christian Maeder wrote: Let's notify the maintainer to use an ordinary minus sign I actually did that two days ago. Other people probably did too. But I haven't seen any response yet. -Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] community.haskell.org is down
The community server, on which resides the domains: community.haskell.org projects.haskell.org code.haskell.org trac.haskell.org planet.haskell.org is down, due to a hacker attack. Rather than trying to repair the old machine it was on, this is the time to migrate this server (finally) to the new machine that has been allocated for it. We are now putting together a strike team to get this done. Hopefully, the server will be up again in a few days. We'll try to keep the community updated about progress. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
