Re: [Haskell-cafe] Re: Hackage accounts and real names
On 6 April 2010 05:32, Ivan Miljenovic wrote: > 5) No-one is convincing anyone else to their point of view, so we have > a stale mate. Let me summarise the main arguments against the restriction: 1. It stops people from contributing to hackage. (It is immaterial that if you were in their position, you would have no problem with the restriction. Because of this policy, we have fewer libraries on hackage.) The reason this came up is because someone on IRC wrote a great implementation of which(1) as a Haskell library. I suggested they put it on hackage, and they told me they wouldn't because of this policy. The community loses out. 2. Inconsistency. If someone is known by their pseudonym on the mailing list, IRC, haskellwiki, blogs and so on, that is how I know them. How am I meant to find out their real name, in general? The rest of the internet works off pseudonyms and it is more convenient for everyone if hackage follows suit. 3. Privacy issues. Some people simply cannot reveal their real names. I've been over this thread and couldn't see anywhere where you'd made an attempt to refute these arguments, so I guess you take them as solid. On the other hand, every argument put forward by the pro-restriction group has been picked at and argued against by those against the restriction. That is not a stalemate. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hackage accounts and real names
On 6 April 2010 05:01, Luke Palmer wrote: > When you say convincing, you are talking about yourself being > convinced, right? So this paragraph means "The arguments against my > position haven't convinced me, but the arguments for my position > have." Had I been told a convincing reason for the restriction, I would have changed my mind on the issue. This paragraph was pointing out that I hadn't. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage accounts and real names
2010/4/6 Jonas Almström Duregård : > Maybe users could choose between using a real name and being given a > random one (like Anonymous). This will (1) protect from data > mining, (2) protect from government persecution and (3) keep the > damned 1337 Haxxor names away from Hackage :) I think this is a bad idea as it ruins recognisability. How am I meant to know that anonymous1 on hackage is the same person as mrfoo on haskellwiki, for example? P.s. if (3) is your real reason for supporting this restriction, please rethink your perspective. You are supporting a policy that is hurting the community for mere aesthetic reasons. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage accounts and real names
On 5 April 2010 23:52, Jason Dusek wrote: > There certainly is a significant subculture of anonymity on > the internet but maybe it has spread beyond its useful limits? > There are places where it is helpful (Allberry's examples > above come to mind) but I don't think contributing code to > Hackage (or Cheeseshop or anything else) is like that. You're coming at this from the wrong angle. Rather than saying, "why should we allow pseudonyms?" we should ask "why are we restricting the freedom of users that just wish to contribute code?" If I'm honest, I'm really surprised so many people have replied in favour of the restriction. I've stated an explicit way in which it's hurting the community, and the only person to say anything in the policy's defence other that "well, why not?" has been Ross (and I hope I dealt with the flaky arguments he linked to in my reply). (P.s., I certainly wouldn't describe the use of pseudonym anonymity a "subculture". Perhaps it's not the norm in academic circles, but virtually all websites requiring a registration allow you to use whatever you like as a username. As does email. As does IRC. I can't think of many bits of the internet that don't.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage accounts and real names
On 5 April 2010 12:52, Ross Paterson wrote: > Basically http://meatballwiki.org/wiki/RealNameUserAdvantages, especially > simplicity, trust and recognizability. Allow me to respond to some of these points. I find none of them particularly convincing, especially not when compared to the disadvantage that it's holding back contributors to hackage. > Simplicity. It's the simplest thing. You need a name, you use your name. Disagreed. For those people who consistently use an online pseudonym, the simplest thing is to continue that consistency, rather than remember a list of exceptions who had a real names policy. Moreover it makes things more difficult for everyone else. If someone uses their pseudonym on IRC, on the wiki, on the mailing lists, on their website and so on and so forth, that's how I know them. If I want to find their hackage contributions, now I need to know their real name. Where do I find this information, in general? (I presume this addresses your "recognisability" point as well.) > Trust. If a person doesn't use their RealName, there is a reason for it. > There are many possible reasons, most of them mean problems. So the community > will not trust people without RealName - except if there is a really credible > explanation. This is an incredible claim. The number of online communities that mandate real names is tiny. This article seems to imply that the vast majority of online communities would be rife with mistrust. This is simply not how the internet works, or has ever worked. The rest of that article is a list of barrel-scraping excuses, e.g., * "Authorship. Being recognized (and honored) as the author." (Why doesn't that apply to a pseudonym?) * "Reputation. Using a RealName is the most credible way to build a combined online and RealLife identity." (Some people don't want this, for whatever reasons.) * ... and so on. > I don't recall anyone else refusing to use their real name, though > a number of people have not responded to enquiries I made of them. > Of course some may have been put off by the User accounts page. There was at least one other person in the conversation who mentioned they'd be put off by this policy. A few others chimed in with general support, if not a specific mention of boycott. IMO this policy is hurting the community in much greater weight than any purported advantages. I'd like to see the restriction lifted. -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Hackage accounts and real names
.On 5 April 2010 03:57, Ivan Lazar Miljenovic wrote: > I can understand wishing to be anonymous in these kinds of situations, > but in terms of submitting open source software? Unless their employer > is worried about them releasing proprietary software on Hackage, I don't > see the potential for embarrasment there. I think the bottom line is that this is preventing people from contributing to Hackage, and there is no good reason behind it other than "Why not". ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Hackage accounts and real names
Hi, An issue came up on #haskell recently with Hackage accounts requiring real names. The person in question (who didn't send this email as he's wishing to remain anonymous) applied for a Hackage account and was turned down, as he refused to offer his real name for the username. Those of us in the conversation thought this a bit of an odd policy, and were wondering where this came from. It also emerged that a couple of other people had been held back from getting Hackage accounts because of this reason. Seeing as it's also trivially easy to fake a name, what's the purpose of this restriction? Thanks, -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] language proposal: ad-hoc overloading
2008/8/31 Ryan Ingram <[EMAIL PROTECTED]>: > My proposal is to allow "ad-hoc" overloading of names; if a name is > ambiguous in a scope, attempt to type-check the expression against > each name. It is only an error if type-checking against all names > fails. If type-checking succeeds for more than one then the > expression is ambiguous and this is also an error. -1, at least for now. Haskell already has one method of overloading: type classes. What you propose is a seemingly innocent extension that I now doubt has extremely far-reaching consequences into the language. Such a feature should be properly researched before it is added to the language. Here's an example of such a concern: you write the following: import Data.Map foo = map What is the type of `foo'? I can think of several solutions to this problem: one that springs to mind is to create something akin to an "on-the-fly" typeclass "class HasMap h where map :: h" and add instances for [a] and Ord k => Map k a. But I suspect there are other options, with differing semantics. What if you further define bar = map (+1), what happens then? Etc. etc. The point I'm trying to make is that such a seemingly simple change is in actual fact not nearly as simple as you might expect. So we should consider carefully how this changes the language, and whether it's worth it. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax of 'do'
2008/8/29 Philip Weaver <[EMAIL PROTECTED]>: > It sounds like you tried to redefine (>>) and (>>=) and make 'do' use the > new definitions. This is not possible, regardless of what types you give > (>>) and (>>=). Watch out for rebindable syntax: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#rebindable-syntax At first reading, I thought that -XNoImplicitPrelude was required to turn this on. But now I'm not sure: it seems that if you hide Prelude.>>= and Prelude.return, that ought to be enough to make do notation work with your alternative definitions. I'm not at home, so I can't try this right now. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Syntax of 'do'
2008/8/29 Maurício <[EMAIL PROTECTED]>: > x :: Prelude.Monad a > y :: Prelude.Monad b > foo :: b -> Prelude.Monad c Monad is not a type, it is a type class, so you probably mean: x :: Monad m => m a y :: Monad m => m b foo :: Monad m => b -> m c With the further understanding that all three `m's must be the same. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Haskell symbol ~
2008/8/28 Maurício <[EMAIL PROTECTED]>: > After the explanations, I think I got it, and just > updated the wiki. Glad you've understood it. Seems I arrived a little late at this thread, but there is also: http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching In addition, the first three chapters of that page might be worth reading if you're a little unclear about laziness etc. in general. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cleaning up the Debian act (report from the trenches)
2008/8/25 Ketil Malde <[EMAIL PROTECTED]>: > 1. Etch comes with ghc-6.6, and that didn't work with my .cabal file. Is it not an option to make your software work with the not-quite-latest compiler? 6.8 is less than a year old, so I imagine 6.6 is still in quite a few major distro's stable repositories. I don't know the details of what changed with Cabal between 6.6 and 6.8, and you didn't provide any details of what broke, so this might not be an option. But something to consider. -- -David ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: darcs hacking sprint (25-26 October)
2008/8/17 Eric Y. Kow <[EMAIL PROTECTED]>: > Correction! We have a tentative offer for space near *Cambridge* > (thanks to Ganesh) and to Ian for picking up on the blunder. Where exactly? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language semantics
Andrew Coppin writes: > I wonder what the layout for that is... something like this? > > case foo of > patter1 > | guard1 -> ... > | guard2 -> ... > pattern2 > | guard3 -> ... > | guard4 -> ... Something like that should work. If the patterns are more indented than the 'case', and the guards are more indented than the patterns, then the layout rule should work fine. As always, once you get used to the way layout works, everything is pretty intuitive. > Well, I'll have to go try it... Always a nice solution to these kinds of problems! > I always thought of guards as being a nice shorthand for if-expressions > - but if they can affect the order of pattern matching, clearly they are > more drastically different than I realised. (Generally, I never ever use > 'em!) A useful rule to remember with guards is that "once you cross the equals sign, you can't go back". So if one of your patterns matches and a guard on that pattern is true, that right-hand side will be evaluated and there is no way to fall back to another guard or pattern. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] lazy patterns versus where-clauses
Peter Padawitz writes: > Is f(~p(x))=e(x) semantically equivalent to: f(z)=e(x) where p(x)=z? Yep. See also http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching regarding lazy patterns. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Useful IDE features -
peterv writes: > That's nice. When will a new Haskell standard become official? It seems so > many new extensions exist, that one cannot judge the language by looking at > "Haskell98" anymore. When haskell-prime is ready, which won't be before the MPTC Dilemma [1] gets resolved, which probably won't be until associated types get fully implemented in GHC, a new version of GHC gets released and people start to use them. [1]: http://hackage.haskell.org/trac/haskell-prime/wiki/MultiParamTypeClassesDilemma -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Haskell mode for emacs - some questions
peterv writes: > Yes, but I can only use GHCI for error checking, because I'm using > GTK2HS/SOE which does not work well with GHCI under Windows, it only runs > when using GHC. Why is this? I'm not that familiar with Gtk2Hs, but I don't understand why it wouldn't work with GHCi if it works with GHC. They use the same code to compile it. On the other hand, you could always just set up a Makefile (which is pretty trivial) and use M-x compile (which you should bind to a key if you use it a lot). -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Collections
Andrew Coppin writes: > Maybe it's just a culture thing then... In your typical OOP language, > you spend five minutes thinking "now, what collection type shall I use > here?" before going on to actually write the code. In Haskell, you just > go "OK, so I'll put a list here..." The design stage of any Haskell program should include a lot of time thinking about your data structures, type classes, and how they all interact. If anything this plays a larger role than in OOP. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Collections
Andrew Coppin writes: > > Data.Graph -- graph type > > > > What would you use that for? (And what does it do?) It's for graphs, in the graph-theory [1] sense. The referenced page gives a list of example problems in the area, most of which are very practical. [1]: http://en.wikipedia.org/wiki/Graph_theory > > Data.Tree -- rose tree type > > > > What's a rose tree? (I only know about binary trees. Well, and N-ary > trees... but nobody uses those.) Well, it is said that a rose tree by any other name would be just as N-ary. (I think they're the same concept :)). -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Collections
Andrew Coppin writes: > However, Haskell only has 1 type of collection: linked lists. (And only > single-linked at that.) Woah there, what about: Data.Map -- lookup tables Data.Array -- lookup tables with enumerated keys. Mutable interfaces are also available. Data.Sequence -- two-ended sequence type supporting a fast variety of operations quicker than lists Data.Graph -- graph type Data.Set -- unordered collection Data.Tree -- rose tree type And those are just the ones distributed with GHC. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell mode for emacs - some questions
peterv writes: > - How can I just compile and run in one go without having to type "ghc > --make main.hs" as arguments for the "compile..." command and then typing > "main.exe" for "shell command..."? This is what you do all the time when > using Visual Studio, Eclipse, etc: just hit the F5 key which builds all the > dependencies and runs one or more generated executables. Easy. Visual > Haskell does this (in the cases it does not hang for some unknown reason). > Of course I could dig into ELISP, but somehow I feel this must be supported > somehow. Use C-c C-l to load the file into GHCi. This is better than just compiling it: you get an interactive environment in which to play around with, test out functions, etc. You can still 'run' your program by typing 'main' in GHCi. > - There seems to be support for "Haskell Font Lock Symbols", which should > convert \, -> and maybe other symbols to good looking Unicode fonts. I can't > get the correct fonts working on Windows. Now as I understood this is not > really supported because of indentation problems, as underneed the single > Unicode arrow character is converted into ->? This is unfortunate, because > that's one of the things I really like about Sun's Fortress: the usage of > Unicode symbols makes the text look much more mathematically, versus the > half-century-old ASCII text. Furthermore in almost all Haskell books the > richer font symbols are used for clarity. Any hints on this topic? I wouldn't be surprised if this code had bit-rotted, or if there never has been Windows support. It's a corner function, used by few and therefore not that polished. By all means, try it out, and if it doesn't work, feel free to submit patches, but I doubt it'll get changed any time soon by a haskell-mode developer :) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] IDE?
peterv writes: > But people, emacs is so weird for a Windows user... Yes, there's no denying this. > For example, ALL windows (and motif?) programs use CTRL-Z for undo. But not > emacs... So after some googling, I found and installed CUA, to get more > Windows compliant keys. CTRL-Z does undo, woohoo! My personal recommendation is that as soon as you're familiar with Emacs, turn off CUA mode. It shouldn't take too long to retrain your brain to use the new shortcuts, and with CUA mode you can't really use Emacs to its full potential. > But CTRL-Y doesn't do redo yet, as in ALL windows programs. Emacs uses a different (and more powerful) undo model to everyone else. The 'Undo' section of the Emacs tour [1] explains this well. [1]: http://www.gnu.org/software/emacs/tour/ > Select a block, press delete. ALL Windows text editors will delete the block, > but not emacs, it just deselects the block and deletes the current character. Place (delete-selection-mode 1) in your .emacs. > I also couldn't get the auto indentation working, not sure why, I thought > that pressing ENTER would automatically indent my code, especially when I end > my line with $. Pressing TAB will not insert a TAB, like in ALL Windows > editors. It's more traditional in Emacs to use TAB to indent code, and Enter (aka RET in Emacs circles) just creates a newline. You can use C-j to perform a newline and indent. Make sure you read up on how indentation works in haskell-mode, though, otherwise you'll confuse yourself. The Haskell wiki page for haskell-mode [2] would be a good place to start. [2]: http://haskell.org/haskellwiki/Haskell_mode_for_Emacs#Indentation > But I have no interest in learning emacs, I just want to learn Haskell > without having to perform too much manual text editing that one does not > expect to do in the 21st century :) You will have to learn Emacs in order to use Emacs. But once you do, you'll never go back. That's my experience at least. > No pun intended; I know Emacs is an incredible system (I used to work with > it on OS/2, and if I recall correctly, I could even read my email right > inside of it, heck it could even make me lispy breakfast! ;), but it's just > so... alien, at least when looking at it from a Windows perspective. In fact I read your mail and am reponding using the excellent VM [3], a mail reader for Emacs :) [3]: http://www.wonderworks.com/vm/ > And that's why IMHO for Windows users, one needs a friendly IDE to get > started with Haskell in a modern way. And the Windows version should comply > to the Windows styleguides. Haskell is such a nice language, it should reach > a larger audience, and just like Concurrent Clean, that could be done by > providing a simple IDE. Emacs isn't a Windows editor, that's for certain. However, that doesn't mean it isn't worth sticking with. > Phew, my frustration leaked into this email, but at least now I got rid of > it, sorry guys ;) It's the same frustration I felt when I was looking for a good Haskell IDE. I really didn't want to try Emacs because I was under the impression that it would be arcane and impossible to learn. But it's the most powerful editor around today, and let me tell you, if you can learn Haskell, you can certainly learn Emacs :) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Andrew Coppin writes: > The only ones I managed to actually edit files with are Nano and Pico. > But given the choice, I'd *much* rather use KWrite. (Or Kate if I really > have to.) Despite it exhibing virtually none of your own aforementioned IDE features? Emacs may be hard to get used to, but its power makes it worth it. Give it a fair try over a weekend or so, count the experience as gaining a life skill. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Andrew Coppin writes: > Well, part 1 would be being *graphical*. I really have no time for ugly > cryptic ASCII art "graphical" UIs... I just like being able to *see* > what's happening. Is that too much to ask? Did you read the rest of my email? For every feature you cited I gave links and screenshots to the Emacs equivalents, none of which (AFAIK -- I don't actually use them all) use ASCII art. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Useful IDE features - What abaut automatically adding import statements?
Marc Weber writes: > Eclipse does have this which saves you a lot of time: > Fix imports. Could you describe the semantics of that more precisely? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Andrew Coppin writes: > > > Personally, I really hate text-mode editors. (I won't even go into how > > > many times I've had to reboot Linux just to get *out* of Vi!) > > > > 'Z Z' is the command to quit vi, right? > > > > Sometimes. Sometimes it just types "zz" in the document. It depends on > the alignment of the planets. Ah, then you're in the wrong mode. Press ESC first. > It's a text-mode editor. With graphical support. > quod erat demonstrandum. Please don't be so quick to jump to conclusions like that. > Since it only operates in text-mode, it cannot possibly provide things > like clickable fold points, http://www.emacswiki.org/cgi-bin/wiki/CategoryOutline I'm not sure any of those supply _clickable_ points, but there's no reason in principle it couldn't be done. Emacs users just feel that using the keyboard is quicker. > or a side-bar containing a bunch of icons representing the objects in the > current file, Speedbar: http://cedet.sourceforge.net/speedbar.shtml http://www.emacswiki.org/cgi-bin/wiki/SpeedBar http://cedet.sourceforge.net/speedbar-multi-2.jpg -- screenshot http://jdee.sunsite.dk/jdedoc/html/jde-ug/images/speedbar1.gif -- screenshot Not sure about integration with haskell-mode, but there's no reason this couldn't be done in Emacs. > or a spell checker, Flyspell: http://www.emacswiki.org/cgi-bin/wiki/FlySpell http://prog.vub.ac.be/~cderoove/geekery/emacslatex/flyspell_menu.png -- screenshot > or an interactive debugger, As previously mentioned, debugging in Haskell hasn't really reached maturity yet, but there's an Emacs interface to gdb: http://www.emacswiki.org/cgi-bin/wiki/GdbMode http://www.inet.net.nz/~nickrob/gdb-ui.png -- screenshot > or any of those other features that require a GUI. Perhaps you ought to revise your opinions on what constitutes a GUI. (By the way, all those screenshots above show Emacs with horrible fonts that haven't been anti-aliased. By checking out the unicode-2 branch of Emacs, which will be merged into the trunk before Emacs 23, you can easily get XFT support. I wouldn't live without it.) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Andrew Coppin writes: > > Why not contribute an afternoon's hacking? > > > > 1. I'm not good enough. How do you intend to remedy that, apart from by writing Haskell code? Start small, fix small typos or bugs, and build it up from there. Seriously, just give it a go, I doubt any of your patches will be rejected out of hand. Rather, you'll get comments on your coding style which will help you become a better programmer. > Personally, I really hate text-mode editors. (I won't even go into how > many times I've had to reboot Linux just to get *out* of Vi!) 'Z Z' is the command to quit vi, right? > What I would *really* like is a nice big IDE... but it seems there isn't > one for Haskell. :-( This was my attitude, too, for a long time when I started to learn Haskell. I'd only heard that Emacs was hard to get used to, hard to use, and somewhat old-fashioned. Seeing as there was nothing better, I decided to spend a weekend learning Emacs and count it as a life skill, as my productivity was sure to increase. What did I find out? Well, the first of those complaints is true, there's no doubting that, but the second isn't really and the third most certainly not. It might not be the most conformist of editors but that doesn't make it old-fashioned, nor arcane, nor irrelevant. Give it a go. Start out with the Emacs tutorial [1] so that you have your feet on solid ground, then jump to the Emacs tour [2] to whet your appetite to the breadths of features that Emacs provides. [1]: Use C-h t (hold Ctrl, press h, then let go of both and press t) inside Emacs [2]: http://www.gnu.org/software/emacs/tour/ -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] hSetBuffering woes
Eric writes: > I tried to turn off buffering with the command hSetBuffering (from > System.IO) but my app still blocks on hGetContents (from > Data.ByteString). Does anyone know what's happening? I very much doubt anyone will be able to help you unless you include some code for us all to look at. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
Andrew Coppin writes: > Dude... somebody should write the world's next killer editor in Haskell, > just to show how awsome Haskell is! Yi [1] does exist, with roughly this aim. Why not contribute an afternoon's hacking? [1]: http://haskell.org/haskellwiki/Yi However, one of the reasons that Emacs is so great is the absolute wealth of libraries available for it. It's been aroud a long time and people like it a lot so there's pretty much an Emacs Lisp library to integrate _any_ tool, to help editing _any_ kind of source/configuration file etc. It would take many lifetimes to replicate this in a different language. I've thought a little about writing a Haskell → Elisp compiler, so that people could contribute to Emacs by writing Haskell, but I've got doubts about its feasibility. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] IDE?
[EMAIL PROTECTED] writes: > The point I wanted to make is, that I can't find an > easy-to-install-ready-to-use-and-rock-n-roll IDE for Windows that comes with > all or most of those features. I mean something like Borland TurboPascal > from the 80's, Visual Studio 2005, IntelliJ IDEA or Eclipse. Would you rather have a different editor for every language, and be forced to learn new editor paradigms, keyboard shortcuts, tools and so on, or have one editor for every language? This is one of Emacs's greatest strengths, IMO: it can handle _everything_. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memo + IORef
Tony Morris writes: > Yes, but where does the IORef live? Wouldn't I have to pass it back and > forth between invocations? If not, where do I get the IORef from on > subsequent invocations? Got a short example? That's where the unsafePerformIO comes in. With unsafePerformIO and IORefs, you can have global mutable variables: {-# NOINLINE #-} memo :: IORef Int memo = unsafePerformIO (newIORef Nothing) f = unsafePerformIO $ do ref <- readIORef memo case ref of Just val -> return val Nothing -> let val = complexCalculation in writeIORef memo val >> return val Something like that. If f took an argument then you'd probably use a IORef Map or IORef IntMap or something in place of IORef Int. Be careful to: 1) Not break referential transparency. I.e. in my example, f will always return the same value, how ever many times you call it. It's possible to break this property using this trick. 2) Not use polymorphic references, as they lead to type unsafety [1]. 3) Always use the {-# NOINLINE #-} pragma on any IORefs you create this way. [1]: http://haskell.org/ghc/docs/latest/html/libraries/base/System-IO-Unsafe.html#v%3AunsafePerformIO -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE?
[EMAIL PROTECTED] writes: > - syntax highlighting > - quick navigation (goto symbol, goto instance, find usages, etc) > - code completion Emacs with haskell-mode can do this. > - cross module refactoring Refactoring doesn't feature as heavily in Haskell workflow as, say, Java, just because of the differing natures of the language (e.g. Haskell features more powerful polymorphism). So you can pretty much get by without refactoring tools, although some do exist. HaRe, for example, has Emacs integration. > - "debugging" (not imperative debugging, so no breakpoints, but just > plugging in a visualizer/pretty printer for a function in a separate > dedicated window, like what http://www.apple.com/shake does on each "node") Debugging in Haskell is a bit of a no-show for now. There's some support in the latest versions of GHCi, but I don't think it's very mature. -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell record extension?
Paul Johnson writes: > This is a feature, not a bug. Haskell in general does not let you give > two functions the same name (which is what you want to do). Record namespacing would still be nice to have, so perhaps call it a "limitation" rather than a bug, but it's not really a "feature". -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Parsec problem
On 06/06/07, Christian Maeder <[EMAIL PROTECTED]> wrote: "try names" does not consume input when names fails, but it may also not consume input when names succeeds on the empty input. In that (latter) case the other alternative (type) is not tried. But in that case it'd be successful and return Right. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] What puts False before True?
On 05/06/07, PR Stanley <[EMAIL PROTECTED]> wrote: Hello What do the ≤ symbols represent? 'Less than or equal to'. To say that x ≤ y, if x and y are numbers, means that x is either less than y, or x and y are equal (so x cannot exceed y). However, in the spirit of mathematics, the symbol now actually means slightly more than just that. There's a general concept called a "partial order" which is quite important in all of mathematics, especially in computer science. Here ≤ still means 'less than or equal to', but that takes on a different meaning depending on which partial order you're talking about. For example, you can order sets by inclusion, so that {1, 2, 3} ≤ {1, 2, 3, 4, 5, 6} because {1, 2, 3} is a subset of {1, 2, 3, 4, 5, 6}. Or you could order the natural numbers by 'divisibility', i.e. you could say that x ≤ y if and only if x is a factor of y (so that 2 ≤ 4, and 3 ≤ 18). You could say that a function f ≤ another function, g, if and only if f(x) ≤ g(x) for every x. If you're familiar with denotational semantics, the partial order on expressions used there roughly corresponds to how many evaluation steps you've gone through, so that 1:2: ≤ 1:2:3:4:, and (, ) ≤ ("hello", 4.3). The reason these are "partial" orders is because sometimes it makes no sense to say that x ≤ y, and it makes equally little sense to say that y ≤ x. For example, if you had the sets {1, 2} and {4, 5}, neither is a subset of the other, so {1, 2} ≤ {4, 5} is false, but {4, 5} ≤ {1, 2} is false, too. http://en.wikipedia.org/wiki/Partial_order contains a formal definition and a few more examples. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] newbie question on Parsers from "Programming In Haskell"
On 04/06/07, Alfonso Acosta <[EMAIL PROTECTED]> wrote: Hugs is probably complaining because it identifies "x <- item" (which is not a simple expression) as the last element of do. That was my first guess, too, but it's not the case, switch to a monospaced font to see this. Juozas, you could only use do-notation if your Parser type were declared an instance of the Haskell type-class Monad. Seeing as you haven't done this, you have to stick to the "de-sugared" version involving (>>=) and return: p :: Parser (Char, Char) p = item >>= \x -> item >>= \_ -> item >>= \y -> return (x, y) -- LINE 34 You might also need a line at the top of your file that looks like this: import Prelude hiding (return, (>>=)) This instructs Hugs not to load the default Haskell definitions of return and (>>=), so that you can use the versions you've defined in your file. The proper solution is to declare Parser an instance of Monad. Unfortunately, this isn't as simple as writing "instance Monad Parser where...", because 'Parser a' is a type synonym, and there's a rule that type synonyms have to be fully applied, but 'Parser' on its own is missing an argument. The only sane way to do it is to make a newtype: newtype Parser a = P (String -> [(a, String)]) Then you can write your instance declaration, using the definitions of return and (>>=) you provided, modified slightly now that Parser has a constructor we need to use: instance Monad Parser where return v = P $ \inp -> [(v, inp)] fail _ = P $ \inp -> [] p >>= f = P $ \inp -> case parse p inp of [] -> [] [(v, out)] -> parse (f v) out (Note also that it's called fail, not failure.) item and parse need to change slightly to reflect the fact that you've got a P constructor floating around: item :: Parser Char item = P $ \inp -> case inp of [] -> [] (x:xs) -> [(x, xs)] parse :: Parser a -> String -> [(a, String)] parse (P p) inp = p inp You should find with those definitions that you can write p as you would expect. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Existentials and type var escaping
On 31/05/07, Isaac Dupree <[EMAIL PROTECTED]> wrote: foo undefined = undefined That's not true. When you evaluate foo undefined, it matches the first (irrefutable) pattern immediately, without any deconstruction of the undefined argument (which is the entire point of it being a lazy pattern). So it becomes the right hand side, C . Only when you force that would you have to force the undefined argument, so foo undefined = C undefined: *Main> foo undefined C *** Exception: Prelude.undefined -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Just for a laugh...
On 31/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Note that the challenge asks for the "internal" bitmap representation of an IEEE double-precision integer - not the mathematical binary expansion. (In particular, things like Infinity and NaN have special bit sequences.) Ah, sorry, then disregard my solution. I did wonder why you'd immediately jump to Data.Bits. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Just for a laugh...
On 31/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: If you're bored... can you come up with a solution to this? Try using floatToDigits: http://haskell.org/ghc/docs/latest/html/libraries/base/Numeric.html#v%3AfloatToDigits "floatToDigits takes a base and a non-negative RealFloat number, and returns a list of digits and an exponent." -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Crazy idea: overloading function application notation
On 31/05/07, Jon Harrop <[EMAIL PROTECTED]> wrote: Is it possible to implement this in Haskell using type classes? Is there any way this could actually be practicable? I had a go but didn't manage to quite get it. Here's my attempt, and the error it produces: {-# OPTIONS_GHC -fglasgow-exts #-} type Endo a = a -> a -- Dummy instances to satisfy the (Show n, Eq n) => Num n constraints instance Show (Endo a) where show _ = "" instance Eq (Endo a) where _ == _ = False instance Num a => Num (Endo a) where fromInteger x = (fromInteger x *) x + y = \z -> x z + y z x * y = \z -> x z * y z abs x = error "Aaargh." signum x = error "Aaargh." main = print (2 3) /home/david/hs/sandbox/application-multiplication.hs:15:14: No instance for (Num (t -> a)) arising from the literal `2' at /home/david/hs/sandbox/application-multiplication.hs:15:14-16 Possible fix: add an instance declaration for (Num (t -> a)) In the first argument of `print', namely `(2 3)' In the expression: print (2 3) In the definition of `main': main = print (2 3) Failed, modules loaded: none. It seems to be wanting a more general instance than the one I'm providing, for whatever reason. Using print ((2 :: Endo Integer) 3) works, but that's hardly satisfactory. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cute code [was: The C Equiv of != in Haskell miscommunication thread]
On 29/05/07, Vincent Kraeutler <[EMAIL PROTECTED]> wrote: anyhow. if someone has a "pedestrian's guide to the fixed point operator" lying around, a link would be much appreciated. Here's a paraphrased quotation from Pierce's "Types and Programming Languages": Suppose we want to write a recursive function definition of the form h = (body containing h) -- i.e., we want to write a definition where the term on the right-hand side of the = uses the very function that we are defining. The intention is that the recursive definition should be "unrolled" at the point where it occurs; for example, the definition of factorial would intuitively be if n=0 then 1 else n * (if n-1=0 then 1 else (n-1) * (if n-2=0 then 1 else (n-2) * ...)) This affect can be achieved using the fix combinator by first defining g = \f. (body containing f) and then h = fix g. For example, we can define the factorial function be g = \fct n. if n == 0 then 1 else n * (fct (n-1)) factorial = fix g Figure 5-2 shows what happens to the term factorial 3 during evaluation: factorial 3 fix g 3 g (fix g) 3 -- Using fix f = f (fix f) if 3 == 0 then 1 else 3 * (fix g 2) -- Using the definition of g 3 * (fix g 2) 3 * (g (fix g) 2) 3 * (if 2 == 0 then 1 else 2 * (fix g 1)) 3 * (2 * (fix g 1)) 3 * (2 * (g (fix g) 1)) 3 * (2 * (if 1 == 0 then 1 else 1 * (fix g 0))) 3 * (2 * (1 * (fix g 0)) 3 * (2 * (1 * (g (fix g) 0))) 3 * (2 * (1 * (if 0 == 0 then 1 else 0 * (fix g -1 3 * (2 * (1 * 1))) 6 The key fact that makes this calculation work is that fix g n evaluates to g (fix g) n. That is, fix g is a kind of "self-replicator" that, when applied to an argument, supplies _itself_ and n as arguments to g. Wherever the first argument appears in the body of g, we will get another copy of fix g, which, when applied to an argument, will again pass itself and that argument to g, etc. Each time we make a recursive call using fix g, we unroll one more copy of the body of g and equip it with new copies of fix g that are ready to do the unrolling again. (Adapted from pp59-60, Types and Programming Languages, Benjamin C. Pierce.) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The C Equiv of != in Haskell
On 29/05/07, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote: Well, not quite :) You forgot "-> Bool" at the end :) Ha! Sorry, what a lovely ironic typo. :) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The C Equiv of != in Haskell
On 29/05/07, Daniel McAllansmith <[EMAIL PROTECTED]> wrote: Just in case there was some sort of miscommunication, the actual answer to your question is (/=) :: a -> a -> Bool, as Neil said. Almost, (/=) :: Eq a => a -> a. (Just for completeness.) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Curiose types
On 28/05/07, Rodrigo Queiro <[EMAIL PROTECTED]> wrote: After a little too long trying, I managed to get code from which the type system will infer that type, without using 'undefined': Yes, but you do it by writing a coerce :: a -> b, which is surely cheating. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language extensions
On 27/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Almost all language extensions seem to be of the form "hey, let's see what happens if we randomly change the type checking rules so that *this* is permitted. What would that be like?" Usually it's an extreme struggle to even wrap my brain around what the extension *is*, never mind why this would be a useful thing... I've read through pretty much all your arguments, and I think they boil down to this: "I don't understand why X is useful, and therefore it can't be useful." Probably the reason why you don't understand why X is useful is because you don't understand X itself in the first place. How can you claim GADTs, existentials etc. aren't useful without understanding what they are in the first place? If you're looking for a good reference to learn these, I suggest the papers apfelmus pointed you towards, or the Wikibook at http://en.wikibooks.org/wiki/Haskell. Moreover, if you've ever written a full-sized Haskell program you'd probably find a use case for at least one of these extensions. For example, you're writing low-level code, and you want in-place array updates. Sounds like a job for the ST monad, which would completely crippled and inherently type-unsafe without rank-2 polymorphism. Or say, as I have done recently, you're writing some forum software, and have a type to represent a Forum, Thread and Post. Now say you want to write some generic code to handle the addition of any one of these -- so this one piece of code allows you to add a new forum, thread or post. Without a splattering of type-system extensions (I used at least MPTCs, FDs and existentials), this isn't going to be possible. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Language extensions [was: Memoization]
On 27/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: So... ∀x . P means that P holds for *all* x, and ∃ x . P means that x holds for *some* x? (More precisely, at least 1 possible choice of x.) Exactly. There's also a lesser-used "there exists a unique", typically written ∃!x. P, which means that P is true for one, and only one, value of x. For some examples of how these "quantifiers" are used: ∀x in R. x^2 >= 0 (real numbers have a nonnegative square) ∃x in N. x < 3 (there is at least one natural number less than 3) ∃!x in N. x < 1 (there is only a single natural number less than 1) For the LaTeX versions, http://www.mathbin.net/11020. Erm... oh...kay... That kind of makes *slightly* more sense now... I wrote most of the second article, I'd appreciate any feedback you have on it. Seriously. Haskell seems to attract weird and wonderful type system extensions like a 4 Tesla magnet attracts iron nails... And most of these extensions seem to serve no useful purpose, as far as I can determine. And yet, all nontrivial Haskell programs *require* the use of at least 3 language extensions. It's as if everyone thinks that Haskell 98 sucks so much that it can't be used for any useful programs. This makes me very sad. I think Haskell 98 is a wonderful language, and it's the language I use for almost all my stuff. I don't understand why people keep trying to take this small, simple, clean, elegant language and bolt huge, highly complex and mostly incomprehensible type system extensions onto it... Ever tried writing a nontrivial Haskell program? Like you said, they require these type system extensions! :) Obviously they don't "require" them, Haskell 98 is a Turing-complete language, but they're useful to avoid things like code-reuse and coupling. One of Haskell's design aims is to act as a laboratory for type theory research, which is one of the reasons why there are so many cool features to Haskell's type system. Anyway, existential types (and higher-rank polymorphism), along with multi-parameter type classes, some kind of resolution to the "MPTC dliemma" -- so functional dependencies or associated types or something similar -- and perhaps GADTs are really the only large type system extensions likely to make it into Haskell-prime. They're really more part of the Haskell language than extensions now, so well-used are they. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bug in GADT Implementation?
On 26/05/07, Dominic Steinitz <[EMAIL PROTECTED]> wrote: This seems even worse to me. A is not inhabited so how can 42 be of type A? I think it should work. The context on the F constructor says that A is an instance of Num, so you could only have an F value if you could prove that A was an instance of Num. Therefore, when deconstructing in bar's pattern, if you match an F, then A must be an instance of Num, so to say 42 :: A is valid. F is a proof, or witness, of A's instantiation of Num. As A isn't, in actuality, an instance of Num, you can never have an F value, but that doesn't matter: all that bar does is express the fact that _if_ you have a value F, then it's valid to say 42 :: A. In a way, it's a bit like saying the following is a true statement: If there are 8 days in the week, then pigs can fly. Neither of the substatements ("there are 8 days in the week" and "pigs can fly"), when taken by themselves, are true. However, the statement as a whole is true. Here are a couple of ways of explaining this: * If you can prove that there are in fact 8 days in the week, then you must have a faulty logic system, so you could prove anything (including "pigs can fly"). * In order to disprove the statement, you'd have to prove that "there are 8 days in the week" is true and simultaneously that "pigs can fly is false". However, you can't do this, because you could never prove that "there are 8 days in the week" is true. Hence, the statement can't be false, so it must be true. (I'm ignoring the difference between truth and provability; think of my arguments as classical rather than intuitionistic.) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Darcs users [was: New book: Real-World Haskell!]
On 26/05/07, Donald Bruce Stewart <[EMAIL PROTECTED]> wrote: darcs.pugscode.org/_darcs/ www.n-heptane.com/nhlab/repos/cabalDebianTemplate/_darcs/ www.khjk.org/~sm/code/advopost/_darcs/ These are also Haskell repos that you missed, bringing the figure up to 8. Still, I wouldn't describe that as "just used by Haskellers". It's also interesting to note that there's a fairly large percentage of Ruby users using darcs. Perhaps we out to push more on this front? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] New book: Real-World Haskell!
On 26/05/07, Matthew Sackman <[EMAIL PROTECTED]> wrote: (On the other hand, I don't know of anyone outside immediate "haskellers" using Darcs.) A lot of people in the Emacs subcommunity use darcs; many of them may have heard of Haskell but certainly wouldn't describe themselves as Haskellers. See http://www.emacswiki.org/cgi-bin/wiki/DaRcs for a few links. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] global variables
On 24/05/07, Adrian Hey <[EMAIL PROTECTED]> wrote: Or even at compile time (which is why I think it's reasonable to regard operations like newIORef etc.. as not really being "IO" operations at all). You can allocate heap space at compile time? (Well, I guess you could, but that wouldn't still be usable at run time...) I imagine newIORef as mallocing() some room, then returning a pointer to that memory. That doesn't seem like something that could be done at compile time. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Should "do 1" compile
On 23/05/07, David House <[EMAIL PROTECTED]> wrote: Why should it compile? Expressions in a do-block have to have the type m a for some monad m, don't they? Further developments on #haskell: dmhouse: where in the report does it say that do blocks constrain types inherently? SamB_XP: I was under that impression, nothing more. dmhouse: ah. well, you would kind of think it would. but it looks like do is defined by translation, and like the Monad constraint only comes from >> and >>= SamB_XP: right, so do (1 :: Int); (2 :: Int) is illegal as it doesn't match the type of (>>), but do (1 :: Int) isn't? dmhouse: so it would seem -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Should "do 1" compile
On 23/05/07, Neil Mitchell <[EMAIL PROTECTED]> wrote: As discussed on #haskell, the following code: module Foo where foo = do (1 :: Int) Compiles fine on Yhc, but doesn't on Hugs and GHC. Why should it compile? Expressions in a do-block have to have the type m a for some monad m, don't they? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Editor
On 21/05/07, Michael T. Richter <[EMAIL PROTECTED]> wrote: Easy, quick access to online documentation for said functions and declarations. I'm writing this for Emacs right now. At the moment both Emacs and Vim can access everything that GHCi has to offer on a function, which means where it's defined, it's type and so on, but not Haddock documentation. I'm extending haskell-mode's inf-haskell.el to take this into account. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small error
On 19/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: How about this? do y <- if x < 0 then do ... else do ... As with many other things in Haskell, the rule is "Give it a go and see if it works!" You should find that the above code runs fine. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A small error
On 19/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Um... why doesn't this work? my_fn x = do if x < 0 then do let y = 5 return () else do let y = 8 return () print y (Error: "y" is not in scope.) let-blocks only scope over the do-block they're contained in. Here y is out of scope once you leave the inner do-block. The solution is to do something like the following: do let y = if x < 0 then 5 else 8 print y -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Accepted by Hugs, not by GHC
On 19/05/07, Hans van Thiel <[EMAIL PROTECTED]> wrote: causes no problems in Hugs (-98 flag) but compiling with GHC produces: There's the solution to your problem: type synonym instances aren't Haskell98, so you have to pass the -98 flag ('turn on extensions') to Hugs in order for it to work. The corresponding GHC flag is -fglasgow-exts. Try that. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Debunking tail recursion
On 18/05/07, Albert Y. C. Lai <[EMAIL PROTECTED]> wrote: Lazy evaluation says, to evaluate x, call f first, then x is the last call. x may be the last to be evaluated, but you still have to pass through f's call context 'on the way out'. For example, suppose in the expression 'f x y' you have f = (+), x = 2 and y = 3, then lazy evaluation looks something like the following: f x y (+) x y (+) 2 3 5 Notice that you still have to evaluate x and y before you can perform the addition. In other words, although you may perform the manipulations that the definition of f describes on thunks, and only later force those thunks, you still have the call context of the f to pass through: you're not evaluating those thunks for no particular reason, you're evaluating them so that f may return. Your argument also seems to be using the reflexivity of the = operation, which doesn't really hold at the binding level. To exemplify, set f = (:) and y = 1, so that you have: (0) x = (:) 1 x (1) (:) 1 x = x The first sets up a binding for 'x', that when evaluated will yield the infinite list [1, 1, 1, ...]. The second sets up a binding for the function '(:)', which when given two arguments, the first of which is 1, will evaluate to its second. I don't really see these as being the same expression. Define (2)cs = 'c' : cs Is (2) a tail recursion? No, for the same reason discussed above: you still have to pass through the call context of (:) once cs is evaluated. What I'm trying to do is disassociate the concept of tail recursion from evaluation order. To say something is tail recursive is to say that a call to itself appears at the top of the call stack: to say it's the "last thing you do" is helpful intuitively but starts to fall apart once you move away from the traditional strict evaluation order semantics. Let's have one more example to explain what I mean by 'call stack'. The classic tail recursive function is foldl, contrasting with the non-tail recursive function foldr. Equations from both these functions are shown below, with their right-hand sides transformed into a tree (ASCII art: don't use a proportional font): foldl f z (x:xs) = foldl f (f z x) xs foldl-+--+-+ | | | f f--+ xs | | z x foldr f z (x:xs) = f x (foldr f z xs) f-+--+ | | x foldr-+--+--+ | | | f z xs Tail recursion, then, expresses the idea that a function appears at the top of its call stack, or at the top of the tree of its right-hand side. It's got nothing to do with evaluation order. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Bad "let..do" syntax
On 17/05/07, Chad Scherrer <[EMAIL PROTECTED]> wrote: But GHC complains of "Empty 'do' construct". Because it takes the indented following lines as being new bindings in the let-block. The trick is to intent them past the 'sum': let b = sum $ do y <- [0..x + 1] return y Or to bypass layout altogether: let { b = sum $ do y <- [0..x + 1] return y } (Of course, in this specific case I'd write sum [0..x + 1], but I guess that this is an example of a general case.) -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] reversing big list with constant heap space used
On 16/05/07, Sergey Perminov <[EMAIL PROTECTED]> wrote: How to solve task of reversing big list with constant heap space used? I think that as lists are singly-linked in Haskell, reversing a list will always be O(n) space. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Code layout in Emacs' haskell-mode
On 14/05/07, Christopher L Conway <[EMAIL PROTECTED]> wrote: For example, here's the "Hello, world" example from the tutorial, with the indentation induced by pounding Tab in haskell-mode. test.hs: module Test where import IO main = do putStrLn "Hello, world" Prelude> :l test [1 of 1] Compiling Test ( test.hs, interpreted ) Are you learning from YAHT, by any chance? That's the only place I've seen the weird convention of placing the 'where' of the 'module X' bit on a separate line. By far the most common convention in normal Haskell is to do as follows: module X where [rest of module] Things should work better if you follow this convention. What you describe still sounds like a bug, though. Again, if I hit tab on the "then" or "else" lines, emacs reports "Sole indentation". But if I manually change the indentation, it works. This too looks like a bug. As you remark, if statements within do-blocks have different indentation to everywhere else, confusingly. Does haskell-mode support code layout? Are there conventions I need to know about to make it behave properly? I have haskell-mode version 2.1-1 installed from the Ubuntu feisty repository. You should install 2.3 from the haskell-mode page [1]. Isaac Jones, maintainer of the Debian haskell-mode package has been contacted in order to get the latest version in the Debian repository, so it should happen soon, but in the mean time you could download and install the latest version yourself. It features quite a few bugfixes and new features that I imagine are documented on the aforementioned page. haskell-mode's indentation engine is still one thing I'm yet to get my head around, and its being written in Emacs Lisp doesn't help the matter! Still, it's on my todo list. [1]: http://haskell.org/haskell-mode -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Monad pronounced like gonad?
On 10/05/07, Dan Weston <[EMAIL PROTECTED]> wrote: I've been pronouncing monad like gonad (moh-nad), but it occurs to me that it might be pronounced like monoid (mah-nad). You say monoid mah-nad? I've always said mon-oyd, to rhyme with void or annoyed. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re [Haskell-cafe] Vanishing polymorphism
On 08/05/07, Matthew Sackman <[EMAIL PROTECTED]> wrote: > :t let f r s = let g (fn::forall n . (Num n) => n -> n) = return (fn r, fn s) in (return negate) >>= g in f Ah, I may have been off the mark earlier. I think the problem is due to the fact that you can't pass higher-order polymorphic functions around. I.e., the following is a classic example of something people expect to work, but doesn't: runST $ ... runST is a rank-2 polymorphic function, and you're attempting to pass it as a parameter to the ($) function, which doesn't work. I think your problem is similar. Here's the module I used to investigate goings on: {-# OPTIONS_GHC -fglasgow-exts #-} import Data.Complex g :: (Num a, Num b, Monad m) => a -> b -> (forall n. Num n => n -> n) -> m (a, b) g r s fn = return (fn r, fn s) f :: Maybe (Int, Complex Float) f = return negate >>= g (4 :: Int) (1 :+ 2) You're attempting to pass the rank-2 polymorphic function "g (4 :: Int) (1 :+ 2)" as a parameter to (>>=), which doesn't work. General point: couldn't GHC's error reporting be improved at times like these? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Vanishing polymorphism
On 08/05/07, Matthew Sackman <[EMAIL PROTECTED]> wrote: > :t let f r s = (return negate) >>= (\(fn::forall n . (Num n) => n -> n) -> return (fn r, fn s)) in f :1:35: Couldn't match expected type `a -> a' against inferred type `forall n. (Num n) => n -> n' In the pattern: fn :: forall n. (Num n) => n -> n In a lambda abstraction: \ (fn :: forall n. (Num n) => n -> n) -> return (fn r, fn s) In the second argument of `(>>=)', namely `(\ (fn :: forall n. (Num n) => n -> n) -> return (fn r, fn s))' I.e. why does the polymorphism get destroyed? Here fn is bound by a lambda abstraction, and is therefore monomorphic. I can't find anything in the Report about that, but that is how it works. It might be how a H-M type system works in general, I'm not sure. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (Chaos) [An interesting toy]
On 07/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: (Anybody know what the difference between GHC.Prim.Double# and GHC.Float.Double is?) It's the difference between unboxed and boxed types. A boxed type's representation is in fact a pointer to the unboxed type (I think), so that a Double would be internally represented to a pointer to a Double#. As a consequence, a Double can be _|_, because this can be represented by a null pointer. So such luck with unboxed types. So working with unboxed types is quicker and consumes less memory, but don't use them in any kind of high level because the lack of a _|_ will bite you sooner or later. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] c2hs errors when compiling hsGnuTls
On 06/05/07, Duncan Coutts <[EMAIL PROTECTED]> wrote: Try the latest darcs version of c2hs, it has a new C parser which should fix issues like this. We should have a new tarball release soon. Works great. Thanks very much. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Arbitrary precision?
On 06/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: Oh, by the way, thanks for the extra syntax. It's really annoying having to locate Notepad.exe on the start menu, type "import Blah", save it as "Thing.hs", open Windoze Explorer, locate Thing.hs, and then double-click it just so that I can try stuff out in GHCi... Any reason you can't use :module Blah in GHCi? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Silly mail client
On 06/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: OK, this is hacking me off now... Does ANYBODY know how I can convince Thunderbird to send replies to Haskell Cafe rather than sending them to the original poster? This is really becoming tiresome... Is there a 'Reply to All' option? That's what it's called in Gmail, you just have to remember to click that instead of the vanilla 'Reply'. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intermediate Haskell Books?
On 06/05/07, Adrian Neumann <[EMAIL PROTECTED]> wrote: Are there any good books about intermediate to advanced Haskell? The descriptions here http://haskell.org/haskellwiki/Books_and_tutorials aren't very helpful. One of the aims of the Haskell wikibook [1] is to provide a good coverage of the more advanced topics interesting to a Haskell programmer. A lot of the sections are incomplete as yet, but there's still quite a lot of good stuff there. We'd appreciate very much any feedback you have: a good place to send this is the wikibook mailing list [2]. If you're reading this as a competent Haskell programmer, why not spend an hour or so improving one of the advanced sections? If there's something you want to write about but that isn't a current chapter, just start it anyway and we'll include it in. [1]: http://en.wikibooks.org/wiki/Haskell [2]: [EMAIL PROTECTED] -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] c2hs errors when compiling hsGnuTls
Hey there, I'm getting the following errors when I try to compile hsGnuTls [1]: ~/hs/sandbox/hsgnutls $ c2hs --version C->Haskell Compiler, version 0.14.5 Travelling Lightly, 12 Dec 2005 build platform is "i486-pc-linux-gnu" <1, True, True, 1> ~/hs/sandbox/hsgnutls $ runhaskell Setup.lhs build Setup.lhs: Warning: The field "hs-source-dir" is deprecated, please use hs-source-dirs. Preprocessing library hsgnutls-0.2.3... c2hs: Error in C header file. /usr/include/bits/pthreadtypes.h:69: (column 6) [FATAL] >>> Syntax error! The symbol `;' does not fit here. Setup.lhs: got error code while preprocessing: Network.GnuTLS.GnuTLS c2hs version: I've attached the file it references in case that's relevant. Any tips on how I might address this? Thanks in advance, -David House, [EMAIL PROTECTED] /* Copyright (C) 2002, 2003, 2004, 2005, 2006 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details. You should have received a copy of the GNU Lesser General Public License along with the GNU C Library; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. */ #ifndef _BITS_PTHREADTYPES_H #define _BITS_PTHREADTYPES_H 1 #define __SIZEOF_PTHREAD_ATTR_T 36 #define __SIZEOF_PTHREAD_MUTEX_T 24 #define __SIZEOF_PTHREAD_MUTEXATTR_T 4 #define __SIZEOF_PTHREAD_COND_T 48 #define __SIZEOF_PTHREAD_COND_COMPAT_T 12 #define __SIZEOF_PTHREAD_CONDATTR_T 4 #define __SIZEOF_PTHREAD_RWLOCK_T 32 #define __SIZEOF_PTHREAD_RWLOCKATTR_T 8 #define __SIZEOF_PTHREAD_BARRIER_T 20 #define __SIZEOF_PTHREAD_BARRIERATTR_T 4 /* Thread identifiers. The structure of the attribute type is not exposed on purpose. */ typedef unsigned long int pthread_t; typedef union { char __size[__SIZEOF_PTHREAD_ATTR_T]; long int __align; } pthread_attr_t; typedef struct __pthread_internal_slist { struct __pthread_internal_slist *__next; } __pthread_slist_t; /* Data structures for mutex handling. The structure of the attribute type is not exposed on purpose. */ typedef union { struct __pthread_mutex_s { int __lock; unsigned int __count; int __owner; /* KIND must stay at this position in the structure to maintain binary compatibility. */ int __kind; unsigned int __nusers; __extension__ union { int __spins; __pthread_slist_t __list; }; } __data; char __size[__SIZEOF_PTHREAD_MUTEX_T]; long int __align; } pthread_mutex_t; typedef union { char __size[__SIZEOF_PTHREAD_MUTEXATTR_T]; long int __align; } pthread_mutexattr_t; /* Data structure for conditional variable handling. The structure of the attribute type is not exposed on purpose. */ typedef union { struct { int __lock; unsigned int __futex; __extension__ unsigned long long int __total_seq; __extension__ unsigned long long int __wakeup_seq; __extension__ unsigned long long int __woken_seq; void *__mutex; unsigned int __nwaiters; unsigned int __broadcast_seq; } __data; char __size[__SIZEOF_PTHREAD_COND_T]; __extension__ long long int __align; } pthread_cond_t; typedef union { char __size[__SIZEOF_PTHREAD_CONDATTR_T]; long int __align; } pthread_condattr_t; /* Keys for thread-specific data */ typedef unsigned int pthread_key_t; /* Once-only execution */ typedef int pthread_once_t; #if defined __USE_UNIX98 || defined __USE_XOPEN2K /* Data structure for read-write lock variable handling. The structure of the attribute type is not exposed on purpose. */ typedef union { struct { int __lock; unsigned int __nr_readers; unsigned int __readers_wakeup; unsigned int __writer_wakeup; unsigned int __nr_readers_queued; unsigned int __nr_writers_queued; /* FLAGS must stay at this position in the structure to maintain binary compatibility. */ unsigned int __flags; int __writer; } __data; char __size[__SIZEOF_PTHREAD_RWLOCK_T]; long int __align; } pthread_rwlock_t; typedef union { char __size[__SIZEOF_PTHREAD_RWLOCKATTR_T]; long int __align; } pthread_rwlockattr_t; #endif #ifdef __USE_XOPEN2K /* POSIX spinlock data type. */ typedef volatile int pthread_spinlock_t; /* POSIX barriers data type. The structure of the type is deliberately not exposed. */ typedef union { char __size[__SIZEOF_PTHREAD_BARRIER_T]; long int __
Re: [Haskell-cafe] Is Excel a FP language?
On 05/05/07, Andrew Coppin <[EMAIL PROTECTED]> wrote: I just had a thought... Why doesn't somebody implement a spreadsheet where Haskell is the formula language? 8-) http://sigfpe.blogspot.com/2006/11/from-l-theorem-to-spreadsheet.html may interest. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
On 2 May 2007 16:16:57 -, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: * It would be nice if this worked inside the do-notation, too: do x :: Ordering x <- m (This is curently a syntax error.) I think the following works with -fglasgow-exts: do (x :: Ordering) <- m -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what exactly does "deriving (Functor, Monad, MonadIO)" do?
On 01/05/07, Brandon S. Allbery KF8NH <[EMAIL PROTECTED]> wrote: I think all this does is save you from having to write a bunch of wrappers that unwrap the contained value, do something to it, and rewrap the result. Exactly. Basically what newtype deriving does is if you have a declaration like the following: newtype T = TConstructor M And M instantiates some class (like Monad, Functor etc), you can derive that class for T. For example, here's how the Functor instance would look for the following newtype: newtype MyMaybe a = MM (Maybe a) deriving (Functor) -- The instance looks like this: instance Functor MyMaybe where fmap f (MM a) = MM (fmap f a) The instance just unwraps and rewraps the newtype constructor. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
On 29/04/07, David House <[EMAIL PROTECTED]> wrote: It's worth pointing out that Emacs's haskell-mode already has this. For anyone that uses the major mode but hasn't heard of the inf-haskell features: I did forget to mention that this won't help with your 'offside' functions, though. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Displaying infered type signature of 'offside' functions
On 28/04/07, Georg Sauthoff <[EMAIL PROTECTED]> wrote: Well, I mention this, because I would like to integrate some lookup feature (for type signatures) into vim (if it doesn't exist yet). It's worth pointing out that Emacs's haskell-mode already has this. For anyone that uses the major mode but hasn't heard of the inf-haskell features: C-c C-t inferior-haskell-type: looks up a type of the function under point, built-in or user-defined. C-c C-i inferior-haskell-info: looks up the info, à la GHCi :info, of the identifer under point, built-in or user-defined. C-c M-. inferor-haskell-find-definition: jumps to the definition of the function, class or datatype etc. under point. See the Haskell wiki page [1] for more information. [1]: http://haskell.org/haskellwiki/Haskell_mode_for_Emacs#inf-haskell.el:_the_best_thing_since_the_breadknife -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Poor first impression
On 29/04/07, Derek Elkins <[EMAIL PROTECTED]> wrote: Much quicker than waiting for a configure script to detect the problem. The fact remains that there is a bug in the build process (configure doesn't check for all the dependencies), and that users have fallen afoul of the bug, so it should be fixed, no matter how well the workaround is documented. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IDE support
On 22/04/07, Philipp Volgger <[EMAIL PROTECTED]> wrote: What IDE support is available for Haskell (Visuall Haskell, EclipseFP), anything else? There is pretty decent Emacs support. haskell-mode [1] provides the basis of this support. There are Emacs Lisp libraries for Haskell indentation, Haskell syntax highlighting, and many other things. Make sure you read the notes on the Haskellwiki [2], as they contain a lot of helpful hints for getting the best out of the mode. There are also libraries for integration of common Haskell tools like hoogle [3] and hpaste [4] in the form of hoogle.el [5] and hpaste.el [6]. Enjoy! [1]: http://www.haskell.org/haskell-mode/ [2]: http://haskell.org/haskellwiki/Haskell_mode_for_Emacs [3]: http://haskell.org/hoogle [4]: http://hpaste.org [5]: http://haskell.org/haskellwiki/Hoogle.el [6]: http://haskell.org/haskellwiki/Hpaste.el -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Beginner's Question] How to read filenames from a DirStream
On 09/04/07, Albert Lee <[EMAIL PROTECTED]> wrote: mapM putStrLn files Seeing as you're not doing anything with the results of this map, you probably want to use mapM_ instead. Then the result type of ls_dir1 can be IO (), which is neater. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Short-circuiting a fold
On 05/04/07, Kurt Hutchinson <[EMAIL PROTECTED]> wrote: Straightforward: > ssfold p f z = head . dropWhile ( not . p ) . scanl f z I'd prefer find instead of head . dropWhile (not . p), making the result type a Maybe, as this is essentially equivalent to searching through the result of a scan for a specific value, so it should follow find's example and use Maybe for its partiality. I want to see some real creativity here, so pull out all the stops. You may also be interested in the Compose experiment [1]: a bit of fun seeing how many different ways compose :: [a -> a] ->(a -> a) could be defined. Most are quite silly, but the solution involving the State monad, for example, is really quite elegant. [1]: http://haskell.org/haskellwiki/Compose -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Unresolved overloading error
On 31/03/07, Bryan Burgers <[EMAIL PROTECTED]> wrote: As a matter of style suggestion, it might make 'binom' more clear if you use 'div' as an infix operator: > binom n j = (fac n) `div` ( fac j * fac (n - j) ) You can even drop the first set of parentheses: binom n r = fac n `div` (fac r * fac (n - r)) Remember that prefix function application has a higher precedence than pretty much anything else. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A wish for relaxed layout syntax
On 28/03/07, Steve Schafer <[EMAIL PROTECTED]> wrote: Another alternative: mylist = [ quite_lengthy_list_item_number_one , quite_lengthy_list_item_number_two , quite_lengthy_list_item_number_three ] I see this a lot. My personal preference is: mylist = [ foo, bar, baz, qux, quux, foo, bar, baz, qux ] -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why the Prelude must die
On 28/03/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote: I would vote for a Combinators module with the most important combinators, and a somewhat larger Prelude to support quick scripts and demonstrations. I'd hate to have to import a module just to get at ($). Like I've mentioned before, some combinators are so ubiqutos they're almost like syntax. Seeing as the actual syntax will always be in scope, these common combinators would also have to be in scope all the time, which means placing them in the narrowed Prelude. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why the Prelude must die
On 28/03/07, Simon Marlow <[EMAIL PROTECTED]> wrote: I support both reducing the prelude to just a few commonly used combinators, and requiring an explicit import Prelude. Just to clear things up: would you need to do an import Prelude to get at these few commonly used combinators, or would the import pull in the 'wider' Prelude, with a more expansive selection, more akin to the current Prelude? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why the Prelude must die
On 25/03/07, Ian Lynagh <[EMAIL PROTECTED]> wrote: You wouldn't have to import a number of different modules like Data.Function, you could just import Prelude. I guess what I was getting at was that Haskell is very good at blurring the distinction between userland function and actual syntax. E.g. to the untrained eye 'otherwise' may seem like a keyword, but it's defined in Data.Bool. Functions like map and catamorphisms like maybe and foldr are used just like control structures, not to mention things like when and unless which are built to directly emulate control structures in other languages. As real control structures, like if and case, are always in scope, having _no_ functions imported by default would drive an unnatural wedge between function and control structure. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why the Prelude must die
On 25/03/07, Ian Lynagh <[EMAIL PROTECTED]> wrote: I've submitted: http://hackage.haskell.org/trac/haskell-prime/ticket/124 which I hope covers the essence of the result of this thread. I'd hate to have to import things like Data.Function for such trivial functions as (.) and ($), which are so often used that they become almost like control structures and keywords in themselves. What did people think of my idea of a stripped down prelude containing primarily the functions like (.) and ($)? Here'd be my list: 1. Almost like control structures otherwise (.) flip ($) 2. To make including literals sane Char String Int Integer Num(..) 3. Other basic functions Eq(..) Ord((<), (>), (<=), (>=)) Show(show) 4. Miscellaneous id const undefined Of course, the precise details would be debateable. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why the Prelude must die
On 24/03/07, Stefan O'Rear <[EMAIL PROTECTED]> wrote: This is a ranty request for comments, and the more replies the better. Without responding to any particular comment, my opinion is that we should have a minimal Prelude with functions like (.) that couldn't be reasonably redefined in any function. Most of the list functions should have to be imported, to encourage people to use a Map or Array and so on. Read should be in Text.Read to encourage people to use Parsec and so on. I wouldn't necessarily be against a minimal Prelude/expanded Prelude split determined by a 'module M where' declaration, as suggested by Sebastian. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell and a new web developement mailinglist?
On 20/03/07, Marc Weber <[EMAIL PROTECTED]> wrote: I've been talking to Chris Eidhof the last days and we'd like to suggest adding another specialized haskell mailinglist: Haskell and web developement. I'd love to contribute here. You should be able to find an appropriate email to ask for this mailing list on the haskell.org site. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what I learnt from my first serious haskell programm
On 19/03/07, Fawzi Mohamed <[EMAIL PROTECTED]> wrote: Vectors don't act like numbers, a vector space is not a field, even if they have some common operations. As I said in my previous email, this is because Num is too big. We need to split it down, but there's no sane way of doing this without your average numeric function needing about a thousand different constraints on it. Type class synonyms [1] look promising, but no-one's implemented them yet AFAIK. [1]: http://repetae.net/john/recent/out/classalias.html -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what I learnt from my first serious haskell programm
On 19/03/07, Fawzi Mohamed <[EMAIL PROTECTED]> wrote: This is is very ugly in my opinion, because for me a type class should represent something more than just a way to overload, is something is not a number then it should not have the class Num. Num is a collection of types whose members can be added and subtracted and so on. As numbers are the most common example of this, one could say the members of Num _act like numbers_, rather than are numbers in themselves. Really typeclasses are all about overloading. For example, Eq is the collection of types that the equality predicate (==) applies to. I don't see this as ugly; quite the contrary, in that if you know a type instantiates Eq you can use (==) without worrying about using a type-specific equality predicate. E.g. it's nice to see the same (==) everywhere rather than seeing (say) (Int.==), (Bool.==) and so on. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what I learnt from my first serious haskell programm
On 17/03/07, Fawzi Mohamed <[EMAIL PROTECTED]> wrote: * namespaces * First off something that disturbed me but does not seem to be discussed much are namespaces, or rather the lack of them. I'm also in the middle of writing a medium-sized program in Haskell, but my experiences have been somewhat the opposite; I've found that although most people complain about the lack of namespaces I haven't really missed them. Yes I know that haskell does have namespaces, but with object oriented languages you basically get a namespace for each class, in haskell you need modules, and I often like to have groups of related types in the same module. Surely within a group of related types there'd be no overlapping names anyway? Records then also put everything in the module namespace, and it seems that this misfeature has already been discussed. I like to prefix my record accessors with three letters that describe the type. For example, in my forum software, the author of a post can be pulled out of a Post value using pstAuthor. Although this is somewhat low-tech, it's a solution that works well and makes reading code easier, while of course solving the one-namespace problem. I don't really see why anything more complex would be needed. So I am wondering how people cope with them, share your opinion, for me the best thing seem to be to try to use one module per "big" type, and then "import qualified x as y", what are good coding practices? A practice I've seen a lot in small- to mid-sized programs is to have a Types module that contains definitions of the types used in the program. * vector & matrices * A thing that bothered me a little was the absence of good standardized vectors and matrices, for now I rolled my own 3x3, I have seen numerical prelude, maybe in the future thre will be a standard interface for matrixes... Rolling my own mattrixes/vectors I have hit against some limitations of classes, nothing terrible, but not so nice, and something that I gather is known for example the fact that you cannot overload + or (in haskell 98) you cannot have overlapping instances. Why not write up your module then send it off to the [EMAIL PROTECTED] mailing list? If this has frustrated you then it's probably frustrated others. Why not contribute something back and polish this problem off? And you can overload (+), just make your matrix type an instance of Num. If some operations shouldn't be supported (like signum, perhaps), the general strategy is just to use error (this is basically due to the fact that Num has too many methods because we don't have a sane way of splitting up type classes. Type class synonyms -- google for them -- look like a good solution, but are lacking an implementation). -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Church Encoding Function
On 10/03/07, Joachim Breitner <[EMAIL PROTECTED]> wrote: Is there a name for these functions? "Characteristic Church Encoding Functions" maybe? Are there more than these: Catamorphisms is indeed the name I've heard. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Usage of . and $
On 08/03/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: NB that infix type constructors must start with ":", just like infix data constructors. Now that's just not true. {-# OPTIONS_GHC -fglasgow-exts #-} type a $ b = a b data Foo a = Foo a deriving (Show) data Bar = Bar (Foo $ Int) deriving (Show) main = print (Bar (Foo 4)) GHCi session: Prelude> :load "/home/david/hs/sandbox/infix-tycons.hs" [1 of 1] Compiling Main ( /home/david/hs/sandbox/infix-tycons.hs, interpreted ) Ok, modules loaded: Main. *Main> main Bar (Foo 4) *Main> There would be no reason for this restriction. The only reason to start infix data constructors with ':' would be to seperate them lexically from infix functions -- just as a leading capital serves to seperate prefix data constructors from prefix functions. There is no such clash with type constructors as there are no type functions. Hence the classic example: class Arrow (~>) where ... -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Usage of . and $
On 07/03/07, Thomas Conway <[EMAIL PROTECTED]> wrote: Of course, what really gets me, is when I start trying to use $ in type signatures and declarations: ... Map ByteString $ foo (bar baz) qux It's almost possible! GHC gives us infix type synonyms: type a $ b = a b (Probably needs -fglasgow-exts.) Sadly we don't have a fixity system for type operators :( -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Usage of . and $
On 07/03/07, Nicolas Frisby <[EMAIL PROTECTED]> wrote: 1) Emacs does the counting for me 2) parens don't surprise me if I happen to use rank-2 types. i was bit enough times when learning why $ and runST don't like each other that I've grown averse of $. I also like thinking of building a composite function instead of sequencing applications--this has helped me see patterns in other places like writing monad transformer instances and other stuff, so maybe it's a good thing. I don't use rank-2 types that often and when I do I'm aware of the restriction on ($) and similar hofs. I tend to use ($) only when the right-hand side gets very messy; a multiple-line do or similar. For example: blah = fromMaybe $ do x <- blah1 y <- blah2 guard (x == f y) g x The closing parenthesis would make things a little messy, so ($) is nice. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google summer of code
On 06/03/07, Malcolm Wallace <[EMAIL PROTECTED]> wrote: Well, our wiki to gather ideas is now up-and-running again: http://hackage.haskell.org/trac/summer-of-code We should probably remove projects that were succeessfully completed last year, along with the lists of interested students on every project. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Usage of . and $
On 06/03/07, Nicolas Frisby <[EMAIL PROTECTED]> wrote: Composition with (.) builds a function, but you eventually want an Int, so we can't just use (.), but we can come pretty close. (sum . IntMap.elems . IntMap.IntersectionWith (\x y -> x*y) queryVector) rationalProjection Often written: f . g . h $ x This is often prefered to the alternative: f $ g $ h $ x As it's visually lighter, and involves less editing if you wanted to get rid of the x (say, you were eta-reducing the expression). As to why: f . g . h . x doesn't work, (.) can only compose two functions, but x is not a function, it is a value, so you have to apply it to the composite function f . g . h using the ($) operator or parentheses. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPTCs and rigid variables
On 06/03/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: I'm not against adding "type is too monomorphic" or something like that if you think it'd help, but I'd like to say something about the incompatibility of 'a' and 'Int'. No? Here's a proper draft, then. Foo.hs: foo :: [a] -- line 1 foo = "hello" -- line 2 Error message: Inferred type is not as polymorphic as type signature claims. Inferred type: [Char] Expected type: [a] Provided by the type signature: foo :: [a] at ~/foo.hs:1 (`a', a polymorphic type variable, could not be unified with `Char', a monotype.) In the expression: "hello" at ~/foo.hs:1:8 In the definition of `foo': foo = "hello" How's that sound? -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPTCs and rigid variables
On 06/03/07, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: 4. The "rigid type variable" thing isn't just an implementation question. What *would* you like the error message to say when you write f :: ([a], Int) -> Int f (x:xs, y) = x+y Here we unify 'a' with Int, which is wrong. What would a nicer error message say? "Inferred type was monomorphic but a polymorphic type was given", or something. Hugs says "Inferred type not as polymorphic as expected", which is the right kind of area. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] RE: MPTCs and rigid variables
On 03/03/07, C Rodrigues <[EMAIL PROTECTED]> wrote: class Foo a b | a -> b where foo :: a -> FooBox b data FooBox b = forall c. Foo b c => FooBox (Maybe c) Existential boxes is indeed the method I've used to tackle this in practice. However, it's kind of annoying, hence my email asking whether there's a good reason it's not possible. I guess there are no theoretical limitations, because, as you've just shown, you can hack your way around it. -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MPTCs and rigid variables
On 03/03/07, Bryan Burgers <[EMAIL PROTECTED]> wrote: As far as I know, you should be defining the type of bar in the class declaration for Foo, not in an instance declaration. I think I over-reduced my problem. Here's a more complex issue that can't be resolved by moving bar to be a method of the class: {-# OPTIONS_GHC -fglasgow-exts #-} class Foo a b | a -> b where foo :: Foo b c => a -> Maybe c instance Foo String () where foo _ = Nothing instance Foo Int String where foo 4 = Just (); foo _ = Nothing -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] MPTCs and rigid variables
class Foo a b | a -> b instance Foo Int String bar :: Foo Int b => b bar = "rargh" Is there any reason why that shouldn't work? GHC gives one of its silly "b is a rigid variable" errors (aside: that's a really confusing error; I'd prefer something like Hugs's "Infered type is not general enough"). -- -David House, [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe