Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 06:57, Ben wrote: sorry, i was only trying to make a helpful suggestion! just to clarify: i'm not championing asciitext (or any other format) -- i only heard about it recently in a comment on http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html i checked it out and it sounded cool, so i thought it'd be a helpful pointer to whomever is working on new haddock -- they are of course welcome to ignore it. totally understand that overmuch debate is not helpful (though i'm not sure it's fair to call it bikeshedding, since it is a primary feature of the proposed project!) best, ben On Apr 27, 2013, at 2:02 PM, Bryan O'Sullivan wrote: On Sat, Apr 27, 2013 at 1:47 PM, Ben midfi...@gmail.com wrote: asciidoc has been mentioned a few times in comments, i think it's worth looking at. This is the problem I was afraid of: for every markup syntax under the sun, someone will come along to champion it. The choice of one or N syntaxes is ultimately up to the discretion of the student, guided by their mentor. It is in our collective interest to avoid prolonging a bikeshed discussion on this, as a long inconclusive discussion risks dissuading any sensible student or mentor from wanting to pursue the project in the first place. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe These two posts are exactly why I believe that extending Haddock itself would be of more benefit than simply adding a Markdown extension to it: with addition to core features, integrating any of the N syntaxes that people want suddenly becomes the question of just writing reader and writer modules for Pandoc instead of a full project on marshalling yet another markup as an extension directly to Haddock. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRggwfAAoJEM1mucMq2pqXHmAP/R2nHmXiNHDVqWEAoLQHSNeC psgcNm2hAclo6AxYprPsNHkqIUYh4HVpsc8FZw+RsAwkpUrGiaaMD/OTNB5857V+ 296lzHNOLNvge7B77FfVTa5wx1j2M+N0+pcOzcxr8qX5opfJNOcMPPtaXqD0nMS7 6EsBac/pQAjOHVYOTHEpsxAbl70s/QFBa/kW6tZPJmWKdHp6c3VmL5qx9CY9lZO4 1QKmyKqQMhxN0hmxcFHcYsa/IsohSAFewrs6JDErShn5ffIvtkhEM0UKVCBM26G4 Eu4Hadrv/AyoDT6UdtMgVllzY0XrykfLJ1nXzpp0QklYml0/SMmNrwqO9wfooMfF XKWiW2T8QWN5dFJO4kM9JA6UqpQ2uvrK6qWREL3jv8/jbEvg0WVko3zTW/BNzjF2 /Pn/9Z1vxYEee4A3Oa0sT7NGhKqK9KRtIgdfuXvTCnctvFYBxwtGHCcKuxgHVNNM GIJAqMtUtwr1Kjt37Gf0F+r1TBQfOsJL7tzRPayZKYPl7uA/ugrHHnYxL5JqIyAq bMUqLxAsDNW2tXIPzmNi4QYPqaopaUmwAD8IPvFk9e/1vI0QnU8b1URLjt5zl3O+ mFyWYTQd/UuaFOmOEmfLMJz+n2tRqL51LOCYcHwEjpH10WuTpX1DS3LWErcwppO5 bUZggQ5DwewgRIfCNEfS =nnP/ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is it time to start deprecating FunDeps?
In your class Sum example,
class Sum x y z | x y - z, x z - y
your own solution has a bunch of helper classes
First of all, on the top of other issues, I haven't actually shown an
implementation in the message on Haskell'. I posed this as a general
issue.
In special cases like below
class Sum2 a b c | a b - c, a c - b
instance Sum2 Z b b
instance (Sum2 a' b c') = Sum2 (S a') b (S c')
-- note that in the FunDeps, var a is not a target
-- so the instances discriminate on var a
I didn't doubt the translation would go through because there is a
case analysis on a. But the general case can be more complex. For
example,
class Sum2 a b c | a b - c, a c - b
instance Sum2 Z Z Z
instance Sum2 O Z O
instance Sum2 Z O O
instance Sum2 O O Z
In your overlap example you introduce a definition that won't compile!
{- -- correctly prohibited!
instance x ~ Bool = C1 [Char] x where
foo = const True
-}
You expect too much if you think a mechanical translation will 'magic' a
non-compiling program into something that will compile.
I do expect equality constraints to not play well with overlaps. Combining
FunDeps with overlaps is also hazardous. I'm only claiming that EC's will
be at least as good.
I don't understand the remark. The code marked `correctly prohibited'
is in the comments. There are no claims were made about that code. If
you found that comment disturbing, please delete it. It won't affect the
the example: the types were improved in t11 but were not
improved in t21. Therefore, EC's are not just as good. Functional
dependencies seem to do better.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Hello, everyone, I was just in the process of trying to get Haskell 7.6 installed. First I surveyed all the current OSes that seemed to support it. FreeBSD 9.1 seemed like a good candidate. However, FreeBSD 9.1 has many practical problems of its own. So far, I have 7.4 installed, but not 7.6. Would the MAC be better at this? Anyway, it seems that much of Hackage will not be usable. Perhaps I should just run it on Windows, as it seems likely to install there and much of Hackage already didn't work there. I welcome any constructive suggestions. Best Regards, Byron Hale On 5/1/2013 10:27 PM, Adrian May wrote: Hi All, Please don't interpret this as a rant: I'm just feeling a bit disappointed about probably having to give up on Haskell. Let's face it: this decision to change the default syntax in GHC7 means that right now Haskell looks about as stable as Ruby on Rails. I just tried to use Flippi. It broke because of the syntax change so I tried WASH. I couldn't even install it because of the syntax change. I persisted for a while but gave up because getPackageId doesn't exist in any form at all anymore. This was only the install script: what would WASH itself have in store for me to get my brain around? What are my choices here: 1) Revert to GHC6 or put pragmas and compiler switches everywhere, switch 2010 off globally with cabal or even make an alias of ghc: That means I'll gradually clash with people who decide ... 2) Convert all my code and a lot of other peoples' to the new syntax, thereby exacerbating the problem that ruled out 1. Either way, we're looking at a long period during which a large portion of the libraries will be incompatible with the other portion, and nobody will know which style to write. I don't know if or when WASH or any other library will convert, or even if I'd prefer that to happen sooner or later, because that would depend on when other libraries do and how I'd worked around it in the meantime. Altogether that means I can't sensibly decide to rely on any library, so I can't use Haskell. I'll just have to go back to fumbling around in XSL, PHP and the like. Is Haskell 2010 really so much better that it justifies this? I just saw that movie The Words: the moral of the story is that you shouldn't try to change your mistakes. ... Apparently it's not only 2010. I now find that buildng the Haskell Platform wants GHC 7.4.2, not 7.4.1 because of the line import Prelude (if I remember rightly,) and even when I follow the rules precisely I still get several different deprecation warnings. The prelude is not exactly obscure. If you deprecate that you've broken everything. Is it really impossible to keep such a basic mantra meaningful from one minor version to the next? Java was fond of deprecating things in the early days, but when they said deprecated they didn't mean switched off, let alone that it would lead to a syntax error. They just meant not trendy anymore. It's a very common illusion to believe that the central thing in your life is also the central thing in everybody else's. That's why things like Norton take over your whole machine: those guys believe that the only reason you bought the computer was to fight viruses, because that's what most of the machines in their office were bought for. There seems to be something similar going on in the way Haskellers are expected to update all their code whenever GHC decide to issue an update. But in reality we have jobs of our own. I'd like to choose Haskell over XSL because I think it'll enable me to write web sites more efficiently, not because I want to forget all about my job and savour the brilliance of the latest Haskell version. But in reality I'm just sitting here waiting for the Platform to compile just in case it's the Ubuntu package's fault, but I know it won't help. I'll just get other problems instead. Reality is that the whole ecosytem is in disarray because of this lack of respect for backward compatibility. At least Rails can plead that it's relatively new, but Haskell has been around for over 20 years. I understand that progress has to be made, and it would be nice if people did just update all their code quickly so you could switch off old stuff and move on. But it's not hard to survey the code that's out there and see how much stuff you'd be breaking if you did. If it's not a lot, then switching it off to wake them up would be an acceptable compromise. But it looks to me as if a lot of very important stuff is still failing on the GHC from November 2010, so clearly things are going too fast. Adding new stuff is great, and sometimes the new stuff clashes with the old stuff. But how much of that deprecated stuff really *needed* to be switched off, and couldn't the new stuff have been designed so as not to force that? In principle this is the best language on the planet, but with all these version gotchas I don't know that I can use it
Re: [Haskell-cafe] Backward compatibility
Adrian May adrian.alexander.may at gmail.com writes: this decision to change the default syntax in GHC7 what decision? what syntax? here's the release notes (7 vs. 6) http://www.haskell.org/ghc/docs/7.0.1/html/users_guide/release-7-0-1.html I guess you are referring to hierarchical module names? (import List = import Data.List) Indeed, I cannot build WASH http://hackage.haskell.org/package/WashNGo-2.12.0.1 on ghc-7.6.3, and I don't see how it could have worked on 7.0, as hackage claims it did. (building the executables: when using base and haskell89, import Prelude is ambiguous; when using haskell98 only, modules like System.Exit are not available.) I think this could be fixed in a straightforward way, but that fixing it is necessary at all, just proves your point. - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskell job / adaptive learning
Dear Haskellers, Erudify (http://erudify.com/) is looking for software engineers to join our team. We are developing an autonomous interactive online tutor. We sell our product to enterprise and provide it for free to schools and consumers. We are looking for software engineers who are smart and friendly, have several years of programming experience, and a passion for building practical and high quality software. Haskell is our main language and we are using JavaScript on the client side. The field of automated learning and teaching is still in its infancy and we are thrilled about the work we are doing to improve how people learn. So what are we looking for? We expect you to prefer design principles compatible with Unix and the Web. You make an effort to learn new technologies that could be helpful and you work to master those you already use. You have worked with a broad range of technologies in your career. You get things done and realise that trade-offs are necessary, but compromising the long-term goal is not. You have experience with Haskell, but might not be an expert. Erudify consists of eleven people -- six of us are Engineers, of which four are specialised in Haskell (with another Haskeller joining soon). We are based in Zürich and our working language is English. Please email us at j...@erudify.com if you are curious. Also, two of our engineers, Bas van Dijk and Simon Meier, will be at the Odessa hackathon from 2 May to 6 May -- they'd be delighted to chat with you. Best wishes, Carl Baatz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Byron Hale byron.hale at einfo.com writes: I was just in the process of trying to get Haskell 7.6 installed. You cannot install Haskell 7.6. Haskell is a language. You can install a language implementation (compiler/interpreter). There may be several. You can also install a set of libraries. These may be bundled (one compiler with one set of libraries). One such bundle is called the Haskell platform. Is this what you are trying to install? (But then the version is nothing like 7.6, this looks more like a compiler version.) Of course this naming error is directly suggested by haskell.org, where we have the equally meaningless Download Haskell right on the front page. - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
Hi, It seems that during the recent suggestions about what markup to choose (Markdown, Creole, Asciidoc, etc.), we've forgotten about one of the goals that seem very important to me for Haskell: the ability to write *math formulas*. I have experienced on StackExchange that just adding MathJAX to Markdown leads to many surprising errors that can be fixed only by strange hacks. Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). Extending Haddock with new features and a syntax for math formulas would certainly require to design such a specification, which isn't easy, and using an existing one would simplify the process a lot. Also I believe that newcomers to Haskell would definitely appreciate working with an existing markup language (and I'm sure not only them) instead of having to learn Haddock's syntax. Best regards, Petr 2013/5/2 Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 06:57, Ben wrote: sorry, i was only trying to make a helpful suggestion! just to clarify: i'm not championing asciitext (or any other format) -- i only heard about it recently in a comment on http://www.codinghorror.com/blog/2012/10/the-future-of-markdown.html i checked it out and it sounded cool, so i thought it'd be a helpful pointer to whomever is working on new haddock -- they are of course welcome to ignore it. totally understand that overmuch debate is not helpful (though i'm not sure it's fair to call it bikeshedding, since it is a primary feature of the proposed project!) best, ben On Apr 27, 2013, at 2:02 PM, Bryan O'Sullivan wrote: On Sat, Apr 27, 2013 at 1:47 PM, Ben midfi...@gmail.com wrote: asciidoc has been mentioned a few times in comments, i think it's worth looking at. This is the problem I was afraid of: for every markup syntax under the sun, someone will come along to champion it. The choice of one or N syntaxes is ultimately up to the discretion of the student, guided by their mentor. It is in our collective interest to avoid prolonging a bikeshed discussion on this, as a long inconclusive discussion risks dissuading any sensible student or mentor from wanting to pursue the project in the first place. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe These two posts are exactly why I believe that extending Haddock itself would be of more benefit than simply adding a Markdown extension to it: with addition to core features, integrating any of the N syntaxes that people want suddenly becomes the question of just writing reader and writer modules for Pandoc instead of a full project on marshalling yet another markup as an extension directly to Haddock. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRggwfAAoJEM1mucMq2pqXHmAP/R2nHmXiNHDVqWEAoLQHSNeC psgcNm2hAclo6AxYprPsNHkqIUYh4HVpsc8FZw+RsAwkpUrGiaaMD/OTNB5857V+ 296lzHNOLNvge7B77FfVTa5wx1j2M+N0+pcOzcxr8qX5opfJNOcMPPtaXqD0nMS7 6EsBac/pQAjOHVYOTHEpsxAbl70s/QFBa/kW6tZPJmWKdHp6c3VmL5qx9CY9lZO4 1QKmyKqQMhxN0hmxcFHcYsa/IsohSAFewrs6JDErShn5ffIvtkhEM0UKVCBM26G4 Eu4Hadrv/AyoDT6UdtMgVllzY0XrykfLJ1nXzpp0QklYml0/SMmNrwqO9wfooMfF XKWiW2T8QWN5dFJO4kM9JA6UqpQ2uvrK6qWREL3jv8/jbEvg0WVko3zTW/BNzjF2 /Pn/9Z1vxYEee4A3Oa0sT7NGhKqK9KRtIgdfuXvTCnctvFYBxwtGHCcKuxgHVNNM GIJAqMtUtwr1Kjt37Gf0F+r1TBQfOsJL7tzRPayZKYPl7uA/ugrHHnYxL5JqIyAq bMUqLxAsDNW2tXIPzmNi4QYPqaopaUmwAD8IPvFk9e/1vI0QnU8b1URLjt5zl3O+ mFyWYTQd/UuaFOmOEmfLMJz+n2tRqL51LOCYcHwEjpH10WuTpX1DS3LWErcwppO5 bUZggQ5DwewgRIfCNEfS =nnP/ -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
My 2c (before such coins disappear...) On 2 May 2013, at 09:14, Petr Pudlák wrote: Hi, Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). So TeX/LaTeX is out then :-( Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 09:26, Andrew Butterfield wrote: My 2c (before such coins disappear...) On 2 May 2013, at 09:14, Petr Pudlák wrote: Hi, Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). So TeX/LaTeX is out then :-( Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe With a reader and write module for new Haddock, you should be able to write LaTeX and convert that to Haddock and vice-versa. Some kind of Markdown was requested by popular demand but if we end up going the Pandoc way, we'll end up getting the plethora of already supported formats basically for free. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRgifxAAoJEM1mucMq2pqXtS0P/Rxx/JHS0vprqi0oCVDPcVTG 0ZCzptgVUYGlbVfdJYsbFChC+7SjWnb6/AXlsEfVnwhpVTparlwRdWu11+LxWWaH sHWqWX6mHk236rBcxllbpE92u/WqOcn4YsOLArClz8xbTVw2YkUHzFUBnnSGvClS V7Qq2jf0xnJWzPcFw1WY9/UdIhcOUif526VW41pkggXCzxp6/gr2VtKJbWJ/ljHX YCdrRRZXypT9UZKKt1oeKWp+XCs5Oh6nBZuJNNTeBQo03wyap4SYrnDlAnhPu911 Fb8+eqGTJKDsKIstERwgWfVSO/qzWUfOTc0orsvJHvy9SCATGKNkwRIvWX2SZj12 bl1D1Z0YQhHl3yRb2G7ZZXGcC6GXfAMk9/I/tgu74HtqM0hxHvZwGwPCX0Ql30EU GJsVBgabv8v6TS96/iipRTZTAUphqSTopl/JWhg0n+p5OVtZKOu/OI/xefmgqI26 Hx1I4yZKDMHkzYJFYhoi9QBLy+XzwlRctjNcEZClse+St1hlgR6lLLjhLHJQoRDg V5TWkzkaO3SvrnKFeObaRdt/Q8BxNgfOcWqyLcioobbu4Un0j6ncpcHZnAFHF0i7 FkE0CGxMiwLrB9F8sw+VTgFnCk3xm0QwgfpDeQVifhD83Jk51pJc8L/vg63ANEGN FI4KKji7k/J2NbfQHxDG =2xQm -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] remote-build-reporting: cabal phoning home?!
Scott Lawrence byt...@gmail.com wrote: I think (and a quick reading of source seems to bear this out) that that only happens when you run cabal report. Which isn't quite undocumented - see cabal report --help. That's reassuring. Thanks a lot! Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Adrian May adrian.alexander@gmail.com wrote: Please don't interpret this as a rant: I'm just feeling a bit disappointed about probably having to give up on Haskell. [rant that update broke stuff] Well, it is a rant, so you can just as well concede it. =) The Haskell community and its descendants (Agda, Disciple, Idris, ...) differ from all other developer communities I know in one point: We don't fear change. There is a reason why other communities do: Non-downward-compatible changes will break stuff. We are aware of that. Occasionally things will break, when they worked perfectly before an update. Does that mean that Haskell sucks? Not really. It means that some library developers will have to get rid of their old bad habits. This is unlikely to happen for unmaintained projects like WASH. So the question you should be asking yourself is: Do you really want to use WASH? I'm surprised that you could build it with any GHC 7.x at all. If you don't like this experimentalism and the rigor with which we get rid of old problems (which isn't even that rigorous -- Functor and Monad are still independent classes even today), then Haskell may indeed be the wrong choice for you. However, you should always ask yourself: Who is the one with bad habits? Consider PHP: It was broken since the beginning and is still broken today. The developers carefully make sure that it stays broken, because fixing it would break applications. They don't want them to break. That means that you can rely on all of your old bad habits, keep your SQL injection vulnerabilities, your broken program logic, etc. Is this good or bad? Consider Debian, the PHP of Linux distributions: Their philosophy is never to touch a running system, so instead of employing architectural changes they keep the old code bases as long as possible and follow a rigorous backporting policy. They don't want you to have to rewrite your configuration files or update your shell scripts or whatever at-most-five-minutes steps would usually be necessary after an update. It should Just Work. Is this good or bad? To express this question in a broader context: Are you leaving a broken tool and replacing it with a new shiny one? Or are you really just replacing a small problem by a big one? Haskell's change policy is a small problem that prevents you from big problems. PHP is a big problem all by itself. Do you really want to leave this wonderful realm just because of one setback? Keep in mind that this setback is an integral part of why Haskell shines where PHP sucks. Think about it. ;) In principle this is the best language on the planet, but with all these version gotchas I don't know that I can use it anymore. What a tragedy. I can't even think of a suggestion as to how Haskell should try to get out of this mess now. We all have to deal with these gotchas. However, I'm still much more productive with Haskell than with any other language. When I go to a new GHC major version I always expect some old packages to fail, and I'm often surprised by the small number of packages that actually do. So my closing comment is: Haskell is one of the best languages, but that greatness comes at a price. Deal with it. Going back to PHP is not the answer. Instead you should recognize that now is the time to look into one of the big three web frameworks of today: Happstack, Snap and Yesod. The tool that is broken and needs to be replaced is WASH, not Haskell. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Hi Ertugrul, Well, it is a rant, so you can just as well concede it. =) By my standards that was a lullaby ;-) Everything you said is correct. Just like everything I said. The best policy lies between the two extremes. Your extreme would be fine if Haskell presented itself as a purely theoretical research tool. But it actually wants people to use it for stuff that peoples' livelihoods depend on. So there are some shiny new frameworks out there which unlike WASH didn't break yet. Thanks for the pointers. I tripped over blaze a moment ago (so no I didn't stomp back to PHP after all) which mentions something called Snap. I'll check out your other suggestions too. But what about two years from now? Will they still be working by then or will their developers have got just as sick of continually moving goalposts as those of WASH evidently did? Or would I be taking on the job of maintaining it myself? I guess you'll be telling me that Happstack is a bad habit of mine and I should rewrite my whole system in whatever the new thing is by then. I mentioned this trade-off that you talk about towards the end of my rantaby. It's true that we can't have the best of both worlds but perhaps a little restraint would be appropriate. I mean, are you saying that Haskell was really bad when it could make up its mind what import Prelude meant? If you really want to change something that basic, how about calling the new one Prelude2? I kinda liked Haskell even in 1998. I just don't see why switching new things on has to mean switching old things off. You can't have your cake and eat it, but I see no reason to shit all over one half of the cake just because you're more interested in the other half. Also, there's no real value in blaming these problems on the maintainers for retaining the bad habits that they learned from Haskell. The reality is that the forums are crammed with people suffering this kind of thing. It doesn't make a difference who you blame. Either way, the ecosystem looks untrustworthy, so fewer people will adopt it, and it'll be retreating from its original stated goal, which IIRC was to be a standard and widely used FL. It might be very rigorous and clever, but that's not much use if it's only being used by the people who have a full time job making it even cleverer. Not a lot of people in industry are using Haskell. More are using Erlang, Ocaml, XSL, J#, etc so it can't be just because they're scared of FP. If you'd rather see more using Haskell, I strongly suggest you get a grip on what real companies actually have to worry about. It ain't mathematical rigour. Backward compatibility is a big chunk of it. Adrian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Hello. On 2 May 2013 14:33, Adrian May adrian.alexander@gmail.com wrote: Hi Ertugrul, Well, it is a rant, so you can just as well concede it. =) By my standards that was a lullaby ;-) Everything you said is correct. Just like everything I said. The best policy lies between the two extremes. Your extreme would be fine if Haskell presented itself as a purely theoretical research tool. But it actually wants people to use it for stuff that peoples' livelihoods depend on. There are 2 extremes: 1). [enterprise extream] do thing once - let it work forever without changes, 2). [developer extreme] - change your applications in a continuous way. Both extremes are not right: first hides a problem, and when a problem got revealed everything is so terribly broken that you need to start from the begining, second extreme require work on things as soon as environment changes (dependencies updates, libraries changes, bugs revealed and fixed). The correct way is scheduled upgrade and Haskell in very close to it. If you see a bug or missfieature or improvement, and it's better - deprecate old, and do changes, then give a time gap for others to fix. That is a really good way, if you have to do changes it means that smth have not done right. As for WASH it has extremely long gap to be fixed, and it simply should be fixed without any philosophical letters to ML. So there are some shiny new frameworks out there which unlike WASH didn't break yet. Thanks for the pointers. I tripped over blaze a moment ago (so no I didn't stomp back to PHP after all) which mentions something called Snap. I'll check out your other suggestions too. But what about two years from now? Will they still be working by then or will their developers have got just as sick of continually moving goalposts as those of WASH evidently did? Or would I be taking on the job of maintaining it myself? I guess you'll be telling me that Happstack is a bad habit of mine and I should rewrite my whole system in whatever the new thing is by then. I mentioned this trade-off that you talk about towards the end of my rantaby. It's true that we can't have the best of both worlds but perhaps a little restraint would be appropriate. I mean, are you saying that Haskell was really bad when it could make up its mind what import Prelude meant? If you really want to change something that basic, how about calling the new one Prelude2? I kinda liked Haskell even in 1998. I just don't see why switching new things on has to mean switching old things off. You can't have your cake and eat it, but I see no reason to shit all over one half of the cake just because you're more interested in the other half. Also, there's no real value in blaming these problems on the maintainers for retaining the bad habits that they learned from Haskell. The reality is that the forums are crammed with people suffering this kind of thing. It doesn't make a difference who you blame. Either way, the ecosystem looks untrustworthy, so fewer people will adopt it, and it'll be retreating from its original stated goal, which IIRC was to be a standard and widely used FL. It might be very rigorous and clever, but that's not much use if it's only being used by the people who have a full time job making it even cleverer. At least in Gentoo you can just use a wrapper for haskell packages there are ~600-700 pkgs like in debian but with difference that they can be built on ghc-6.1(not everytime), 7.4, 7.6, and some on HEAD, and we use frontline versions (latest available+some more for quickly changing packages) is used. All packages are patched accordingly if compatibility between them is broken and we tries to send patches upstream. Not a lot of people in industry are using Haskell. More are using Erlang, Ocaml, XSL, J#, etc so it can't be just because they're scared of FP. If you'd rather see more using Haskell, I strongly suggest you get a grip on what real companies actually have to worry about. It ain't mathematical rigour. Backward compatibility is a big chunk of it. Adrian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Alexander ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 5:30 PM, Ertugrul Söylemez e...@ertes.de wrote: To express this question in a broader context: Are you leaving a broken tool and replacing it with a new shiny one? So I read the original post, and it really wasn't clear to me what exact changes were causing the issues; I don't think I'm alone in thinking the OP could have been a bit more explicit about the nature of the problem. Also, at least Flippa is explicitly unmaintained (according to the first hit googling Flippa Haskell), and I hadn't seen mention of WASH for a year or more. And of course, ghc-7.0 was released 2.5 years ago, ghc-7.6 is the current version, and there's been ample time for incompatibilities to accumulate. Despite those issues I'm rather sympathetic to the OP, in part because most of these breaking changes aren't replacing a broken tool. If the Functor/Applicative/Monad hierarchy were fixed it would cause a lot of breakage, and I (like many of us I'm sure) would have to update a lot of packages, but I wouldn't mind because that would be a clear improvement. But replacing import List with import Data.List? That's not even a problem. Consider another breaking change, requiring newtype constructors be in scope for foreign imports. This required a lot of code churn, especially as IIRC the CDouble constructor wasn't exported previously (for reasons of abstraction, which I can also rant about), so of course it wouldn't have been in explicit import lists. At least this has some marginal utility if you care about Safe Haskell. I did a lot of work to get packages compilable with ghc-7.6 and submitted patches to probably a dozen different repos. Aside from one exception (related to the FFI), every breaking change was either related to namespacing/import issues, or bumping versions in .cabal files (I consider the whole try/catch mess to be an import issue, although at least in that case the benefit is more obvious). Two pragmas existed that duplicate functionality, one was deprecated in the last release and now the other one is deprecated while the first has been un-deprecated. It's just rearranging deck chairs. It doesn't feel like a significant improvement, and it's even harder to bill as one. I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity. Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake. (Unfortunately I'm not really sure what we can learn from this particular case, but maybe somebody wiser than me could point the way) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Adrian May adrian.alexander@gmail.com wrote: [...] If you'd rather see more using Haskell, I strongly suggest you get a grip on what real companies actually have to worry about. It ain't mathematical rigour. Backward compatibility is a big chunk of it. I'm not saying that you are wrong, but you may be looking at it from the wrong angle: Unmaintained projects depending on one of the major web frameworks still compile today. The strong version constraints used by packages and taught by the package versioning policy makes this possible. When you install it, it does the right thing. WASH on the other hand is really a legacy from the stone age of real world development in Haskell. As said, I'm surprised that you could even compile it today. I consider it a proof of concept that web application development is very possible with Haskell and the community has moved on to implement real web frameworks made for production use. This happens for all languages, not only Haskell. You may find that one or the other C/C++ package breaks with GCC 4 when it compiled just fine with GCC 2. This is why we have the major/minor/patch-level split in the first place. You can't expect that nothing will break when you update from GCC 3 to GCC 4. The same holds for GHC and even for strongly keep-being-retarded language implementations like PHP. At some (quite recent) point in time the whole language was revised and is called Haskell 2010 now. You can still compile with Haskell 98 and many old packages should still work, unless they are broken by the new base library. With the new language it's simply that the type system has changed in an incompatible way. It's not that features have been removed, but simply that you have to express them differently now. This is most noticable for local bindings, but you will also find that the base library has undergone some breaking changes. This was the most legacy-breaking change I can remember, but it was necessary. We all suffered from bad decisions made in the old days. This is also likely the change that broke WASH. Other than this the Haskell ecosystem is actually comparatively stable. It is so stable that actually we run into another problem, which we refer to as the Cabal Dependency Hell. Semisolutions like cabal-dev are available, but we really need to do some work here. This is probably the weakest part of the Haskell ecosystem right now. However, it's also actually a very hard problem. Other languages have the same problem, but they fix it by ignoring it. Programmers in those languages just pretend that it's impossible to install multiple versions of the same package, but if operating systems like NixOS gain more popularity they will have to reconsider their philosophy when they face sudden segfaults. Haskell's Cabal would have warned them. They don't have such a tool. In other words, you are likely suffering from the one big breaking change made in Haskell's modern history (i.e. post 1998). Don't be discouraged by that and enjoy the improved language and base library. Enjoy an ecosystem that acknowledges the existence of problems and the tools you get to find a solution that fits you. You are going into the right direction now. =) Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
John Lato jwl...@gmail.com wrote: I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity. I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today. Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing. Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake. I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users. With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 1:27 AM, Adrian May adrian.alexander@gmail.comwrote: Let's face it: this decision to change the default syntax in GHC7 means that right now Haskell looks about as stable as Ruby on Rails. I just tried to use Flippi. It broke because of the syntax change so I tried WASH. I couldn't even install it because of the syntax change. I persisted for a while but gave up because getPackageId doesn't exist in any form at all anymore. This was only the install script: what would WASH itself have in store for me to get my brain around? I'm going to give you the flip side of this one. I've been active in the Perl community (admittedly in something of an off and on fashion for health reasons) for years. Perl 5 is in some ways the epitome of maintain backward compatibility: there is a lot of Perl code out there that was written under Perl 4 or earlier. (cpanel, I'm looking at you. Among others. I recently got to debug some code related to someone's RADIUS server that looked like it hadn't been touched since perl3.) And this is the direct cause of the Perl ecosystem being a sewer. Nobody is willing to take the step of making Perl default to the eminently sane behavior of checking for invalid inputs, because it will break too much existing (already horribly broken, in reality) code. Nobody will risk disabling the walking security hole and encouragement of sloppy, buggy code that is Perl's 2-argument open(). (If you ever wondered why Perl 6 decided to throw out source compatibility, here's your reason.) The Haskell98 ecosystem wasn't nearly that bad, but maintaining compatibility with it did prevent fixing various flaws in things like exception handling. Between the two, I'd rather see older code broken in the name of current code actually working correctly. And in Haskell I get a lot of help from the compiler to bring that older code up to date. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
So WASH is ancient history. OK, lets forget it. How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? That's how I spent my afternoon today, instead of getting on with my job. Now you might think I was silly not to have uninstalled the linux package first, but I tried, and then decided against it because it thought the entire OS depended on it and actually proposed to remove everything from clib to googleearth as a solution. It's not Haskell's fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it's better not to keep moving the furniture around. Why was I trying to build the Haskell Platform at all? Because it wasn't obvious to me that a 7 year old library would be doomed. I find it perfectly normal to be able to compile C code from the 1970s but still run STL through the same compiler. That's why I blamed the system instead of the library. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH in that long-forgotten era when Barack Obama was barely known, a Russian spy was poisoned with Polonium and a Sudanese man was ordered to marry a goat he was caught in an intimate position with, then I still see it that way. Adrian. On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote: John Lato jwl...@gmail.com wrote: I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity. I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today. Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing. Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake. I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users. With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
If you are actively using something then keep it up to date, encourage someone to keep it up to date, pay someone to keep it up to date, or migrate off of it. If you try building with a fresh set of packages every so often, you can catch breaking changes early and deal with them when it's typically pretty clear why things broke. On May 2, 2013 6:33 AM, Adrian May adrian.alexander@gmail.com wrote: So WASH is ancient history. OK, lets forget it. How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? That's how I spent my afternoon today, instead of getting on with my job. Now you might think I was silly not to have uninstalled the linux package first, but I tried, and then decided against it because it thought the entire OS depended on it and actually proposed to remove everything from clib to googleearth as a solution. It's not Haskell's fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it's better not to keep moving the furniture around. Why was I trying to build the Haskell Platform at all? Because it wasn't obvious to me that a 7 year old library would be doomed. I find it perfectly normal to be able to compile C code from the 1970s but still run STL through the same compiler. That's why I blamed the system instead of the library. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH in that long-forgotten era when Barack Obama was barely known, a Russian spy was poisoned with Polonium and a Sudanese man was ordered to marry a goat he was caught in an intimate position with, then I still see it that way. Adrian. On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote: John Lato jwl...@gmail.com wrote: I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity. I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today. Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing. Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake. I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users. With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Backward compatibility
On Thu, May 02, 2013 at 09:26:15PM +0800, Adrian May wrote: How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. I'm uninformed in such matters, but from http://www.haskell.org/platform/changelog.html it looks like GHC 7.4.2 is *part* of Haskell Platform 2012.4.0.0, so it doesn't make sense to talk about the latest Platform without 7.4.2. I know that sounds like a technicality, but I don't think it actually is! The important question is whether *your* old code breaks with the latest Platform, not whether the latest Platform breaks with GHC 7.4.1. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
If you are actively using something then keep it up to date, encourage someone to keep it up to date, pay someone to keep it up to date, or migrate off of it. If you try building with a fresh set of packages every so often, you can catch breaking changes early and deal with them when it's typically pretty clear why things broke. Not necessarily. Let's take Flippi as an example. What seems to be happening there is that Text.Html is incompatible with CGI.Html, or something like that. Those are both vanilla modules that would not be under my control. If somebody else decides to make them incompatible, there's nothing I can do. Not without a total rewrite, but by then I might have 20 man-years invested in it. Nobody is gonna do a big project in a language with this attitude. What if Android were written in Haskell for instance. At the famous 10:1 ratio there'd be roughly 5 million lines of it. Nice update guys - we only had to rewrite 100,000 lines this time. Then you'd be afraid of change cos it would be your own phone you were breaking. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 6:26 AM, Adrian May adrian.alexander@gmail.comwrote: How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. I think you're missing the point of the platform! It is an explicit set of versions, including GHC, that make a stable reference set of packages on which to build, test, and deploy. Each version of the platform explicitly states with equality constraints the exact version of each component so that it will be the same for everyone. You use the HP - with the GHC it comes with (or specifies) - as a set. You want to use GHC 7.4.1? Use HP 2012.2.0.0. Once installed you can install newer versions of the component packages if needed (though cabal-dev or cabal sandboxing is strongly encouraged in such a case to avoid cabal hell.) And unless somebody can explain to me how I would rescue my business now if I had opted for WASH By patching it. Surely we are talking about minor changes here. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
I think you're missing the point of the platform! I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the platform. As I say, the reason I was trying to build it was that I wrongly blamed the ubuntu package for WASH not working. But that was not dumb unless you consider it obvious that 7 year old code would be broken, in which case it would be obvious that nobody would trust this language in production. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH By patching it. Surely we are talking about minor changes here. Yeah but how many minor changes? This trigger-happiness is rife. And that's the first time anybody suggested the necessary changes to WASH should be minor. Everybody else thinks I was nuts to expect anything from 7 year old code. I don't know because I couldn't get past the install. Somebody had deleted getPackageId. Please would somebody explain to me what getPackageId did to incriminate itself? I'm sure there's something much groovier now, like getting it inside a monad in case it changes during the installation itself (pretty likely AFAICT) but it's really just a package id. Can we honestly philosophise about the mathematical rigour of getPackageId? It was needlessly assassinated. For all I know WASH might be just fine apart from that, and maybe I would have liked it, even if it is from the dark ages. Yes there are times when something has to change. I acknowledged that in my original post. But I see no evidence whatsoever that anybody in control of Haskell is holding fire even on things as innocent as getPackageId or as ubiquitous as the prelude. I'm not asking for the opposite extreme of conservatism, just a bit of common sense instead of this bloodbath. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 10:36 AM, Adrian May adrian.alexander@gmail.comwrote: I think you're missing the point of the platform! I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the Having to build it already indicates that something is wrong, unless you're porting to an unsupported OS/hardware. platform. As I say, the reason I was trying to build it was that I wrongly blamed the ubuntu package for That said, may I point out that the Ubuntu packages *are* broken? They shipped a mangled Platform which can't be relied on for much; instead of a well-tested set of packages, they took a good Platform and replaced bits with minimal testing. Yes, this has actually caused problems for people. Yes there are times when something has to change. I acknowledged that in my original post. But I see no evidence whatsoever that anybody in control of Haskell is holding fire even on things as innocent as getPackageId or as ubiquitous as the prelude. I'm not asking for the opposite extreme of conservatism, just a bit of common sense instead of this bloodbath. You're assuming here that someone deliberately targeted your favorite pet. I don't know the details but I VERY STRONGLY doubt anyone said oh, we should break that function. But I ALSO find it likely that it was the victim of something sufficiently pervasive that the options were break it or live with something else being broken forever, just like Perl vs. cpanel! This, sadly, is the real world. The holy grail of fixing bugs without breaking any program ever anywhere is impossible, and even fix this bug without breaking many other programs is extremely unlikely. Your choices are this, or Perl/PHP we do not dare fix bugs or misdesigns because someone's pet program will die. (Other examples of this: - Python 3. Note how many existing Python packages still require Python 2. - The C and C++ standards are increasingly Byzantine due in large part to backward compatibility issues; but I'm guessing from your complaints that this is your ideal model because old programs still work. Lucky you, you can happily pretend that it's because they have found some magical way to do the fundamentally impossible --- right up until reality bites back. ) -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 7:36 AM, Adrian May adrian.alexander@gmail.comwrote: I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the platform. This is not for the faint of heart. Like *ALL* language distributions I know (C++ included), boot-strapping the next rev is never easy. Consider building the stdc and stl for version gcc x with gcc x-1 - Or trying to assemble and test packages for python 2.x with only python 2.(x-1) just a bit of common sense instead of this bloodbath. Now you're being hysterical. The changes don't rise to that level at all. Vast swaths of haskell code have continued to work just fine over the last many years of changes. And many more have continued to work with only minimal maintenance. The changes over the last several years are no more extreme than I see in other systems. Consider that Mac OS X ships with Python2.5 and 2.6 and 2.7 all installed because of incompatibilities in the base set of libraries. If you are comparing it C++ library stability you are being myopic: The situation in C++ system libraries was so complex that it spurred the monster that is autoconf! That the most common libs have settled into a very stable set that can be expected to work over several years and major releases, has only been true in the last decade. The prior three decades of C (and later C++) were filled with tons of this sort of versioning difficulty, compounded by multiple systems. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 02, 2013 at 10:36:18PM +0800, Adrian May wrote: Please would somebody explain to me what getPackageId did to incriminate itself? What's getPackageId? It does not appear in the WASH source. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
What's getPackageId? It does not appear in the WASH source. It's in Setup.lhs, in WashNGo. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 02, 2013 at 11:10:33PM +0800, Adrian May wrote: What's getPackageId? It does not appear in the WASH source. It's in Setup.lhs, in WashNGo. Which source of WashNGo are you using? It doesn't appear in either of these versions: http://hackage.haskell.org/package/WashNGo-2.12 http://hackage.haskell.org/package/WashNGo-2.12.0.1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Summer school on Applied Functional Programming at Utrecht University
We offer a summer school on Applied Functional Programming in Haskell August 19 - 30, 2013 Utrecht University. The deadline for registration is May 20, 2013. Almost 20 students have already registered. In the previous four occasions students were all very happy with the school and we plan to repeat this success this year. Among the intended audience are prospective master students who gained an interest in Functional Programming, e.g. by taking a general course on programming languages, and want to learn more about Haskell and its typical programming patterns. In previous years we have taught an introductory part (advanced bachelor level), an advanced part (beginning master level) and a shared part for both groups. Topics covered are, besides some examples of domain specific languages, monads, monad transformers, arrows, parser combinators and self-analysing programs, underlying principles, type inferencing, etc. Half of the course time is spent on a larger programming exercise; you can also come with a problem of your own if you want, and get help from the Utrecht University Software Technology group in finding the proper Haskell idioms, tools and libraries, for solving it. More information: http://www.cs.uu.nl/wiki/USCS/ Please forward this announcement to potential participants. Best, Doaitse Swierstra, Atze Dijkstra and Johan Jeuring ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Which source of WashNGo are you using? It doesn't appear in either of these versions: http://hackage.haskell.org/package/WashNGo-2.12 http://hackage.haskell.org/package/WashNGo-2.12.0.1 http://www.informatik.uni-freiburg.de/~thiemann/WASH/WashNGo-2.12.tgz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 02, 2013 at 11:23:12PM +0800, Adrian May wrote: Which source of WashNGo are you using? It doesn't appear in either of these versions: http://hackage.haskell.org/package/WashNGo-2.12 http://hackage.haskell.org/package/WashNGo-2.12.0.1 http://www.informatik.uni-freiburg.de/~thiemann/WASH/WashNGo-2.12.tgz I get a 403 FORBIDDEN on that. How did you get it? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On 3 May 2013 01:04, Brandon Allbery allber...@gmail.com wrote: On Thu, May 2, 2013 at 10:36 AM, Adrian May adrian.alexander@gmail.com wrote: I think you're missing the point of the platform! I suppose I did miss the point of the platform: I was trying to build it, which requires at least part of the Having to build it already indicates that something is wrong, unless you're porting to an unsupported OS/hardware. Or you have a source-based distro, or you prefer building it yourself rather than using distro packages (as they might be out of date or b0rked), etc. ... ;-) -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Adrian May adrian.alexander@gmail.com wrote: I attached the tarball. Don't say you got it from me, OK. That's a weird thing to demand in a public mailing list with public search-engine-locatable archives. =) Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a bug of 32bit ghc on mac ?
so confused... I have asked one of my friends to compile this code. And he also got an fail It seems this bug only occurs on a 32-bit version ghc update: my friends said he changes the decode line into a ugly way: let x = decode $(C.pack. C.unpack) au :: Maybe AuctionInfo then he got an ok but i did so, also fail... Subject: Re: [Haskell-cafe] a bug of 32bit ghc on mac ? From: hutch-li...@recursive.ca Date: Wed, 1 May 2013 05:43:46 -0400 CC: haskell-cafe@haskell.org To: s...@live.com I compiled and ran it a few hundred times in a script with no failures. I've got the same version of GHC on OS X 10.8.3. BTW, it's not just Yesod that has that bug you mentioned in the 64-bit version. Cheers,Bob On 2013-04-30, at 11:37 PM, Sray s...@live.com wrote: hi all it seems i have met some bug on a MAC 32bit GHC version 7.4.2 to make long stroy short, my code is about parse a json file using aeson here is my code http://pastebin.com/0VcVhdvX and here is test data http://pastebin.com/PvtSvst5 and test steps save the code , and name it a.hs (or what you want) save the test data ,name it a.json (do not change its name) $ ghc a.hs -o a $ ./a what i get from the output is fail and when i run the command below for a few times $ runghc a.hs i even got some ok and some fail mixed together but i copy the code and compile it on my linux, everything goes fine, the output is OK i have run uninstall-hs and install a 64bit ghc, also goes fine i delete one line randomly chosen from my test data , got an ok roll back ,delete another line, also an ok... I just want to make sure is this my bug or a bug of ghc p.s. the reason using 32bit ghc is yesod, which has met another bug on 64bit mac ghc :( thanks sray ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 02, 2013 at 11:35:27PM +0800, Adrian May wrote: I get a 403 FORBIDDEN on that. How did you get it? I guess you just gotta know the right people ;-) I attached the tarball. Don't say you got it from me, OK. That tarball still doesn't contain the string getPackageId. You're complaining that you can't build a package, which hasn't been maintained for several years, which you got from a secret source, and whose whose Hackage page specifically says it doesn't build beyond GHC 7.0. I don't think this is indicative of a serious failure of Haskell. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Hi Adrian I don't want to argue against your rant for the sake of it, but Haskell is a fairly conservative language. The Glasgow Haskell Compiler supports it's own dialect Glasgow Haskell which is fast moving, but the developers of GHC do work hard to maintain compatibility with standard Haskell 98 and Haskell 2010 (optionally enabled with compiler flags). Afterall Haskell now is fairly widely used as a teaching language which befits stability as course textbooks, lecture plans etc. can't be in hock to a language that changes every year. Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
@Adrian May if you want that much backward compatibility you probably need to move to an operating system that suports it. NixOS, already mentioned by another commentator, would be my recommendation if you really need the backward compatibility I just finished compiling both Flippi and WashNGo with ghc-7.0.4. I do not want the GHC maintainers to be tied down by maintenance concerns any more then they already are, there time is more productively spent on concerns other then increasing backward compatibility. For anyone who works on GHC thank you for helping support such a great ecosystem that enables this level of experimentation and rate of new features. Patrick Wheeler On Thu, May 2, 2013 at 11:50 AM, Tom Ellis tom-lists-haskell-cafe-2...@jaguarpaw.co.uk wrote: On Thu, May 02, 2013 at 11:35:27PM +0800, Adrian May wrote: I get a 403 FORBIDDEN on that. How did you get it? I guess you just gotta know the right people ;-) I attached the tarball. Don't say you got it from me, OK. That tarball still doesn't contain the string getPackageId. You're complaining that you can't build a package, which hasn't been maintained for several years, which you got from a secret source, and whose whose Hackage page specifically says it doesn't build beyond GHC 7.0. I don't think this is indicative of a serious failure of Haskell. Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Patrick Wheeler patrick.john.whee...@gmail.com patrick.j.whee...@rice.edu patrick.whee...@colorado.edu ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
indeed. That approach seems like the most likely to be successful within the scope of a single summer. That said, this does raise the question of what needs to be fixed up / added to the haddock grammar to a) make it a rich target for pandoc b) make sure the augmented haddock grammar is human friendly and we can give helpful syntax errors etc. Whats the status of this proposal for this years GSOC? Done well / right, it'd be super valuable for the community -Carter On Thu, May 2, 2013 at 4:46 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 09:26, Andrew Butterfield wrote: My 2c (before such coins disappear...) On 2 May 2013, at 09:14, Petr Pudlák wrote: Hi, Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). So TeX/LaTeX is out then :-( Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe With a reader and write module for new Haddock, you should be able to write LaTeX and convert that to Haddock and vice-versa. Some kind of Markdown was requested by popular demand but if we end up going the Pandoc way, we'll end up getting the plethora of already supported formats basically for free. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRgifxAAoJEM1mucMq2pqXtS0P/Rxx/JHS0vprqi0oCVDPcVTG 0ZCzptgVUYGlbVfdJYsbFChC+7SjWnb6/AXlsEfVnwhpVTparlwRdWu11+LxWWaH sHWqWX6mHk236rBcxllbpE92u/WqOcn4YsOLArClz8xbTVw2YkUHzFUBnnSGvClS V7Qq2jf0xnJWzPcFw1WY9/UdIhcOUif526VW41pkggXCzxp6/gr2VtKJbWJ/ljHX YCdrRRZXypT9UZKKt1oeKWp+XCs5Oh6nBZuJNNTeBQo03wyap4SYrnDlAnhPu911 Fb8+eqGTJKDsKIstERwgWfVSO/qzWUfOTc0orsvJHvy9SCATGKNkwRIvWX2SZj12 bl1D1Z0YQhHl3yRb2G7ZZXGcC6GXfAMk9/I/tgu74HtqM0hxHvZwGwPCX0Ql30EU GJsVBgabv8v6TS96/iipRTZTAUphqSTopl/JWhg0n+p5OVtZKOu/OI/xefmgqI26 Hx1I4yZKDMHkzYJFYhoi9QBLy+XzwlRctjNcEZClse+St1hlgR6lLLjhLHJQoRDg V5TWkzkaO3SvrnKFeObaRdt/Q8BxNgfOcWqyLcioobbu4Un0j6ncpcHZnAFHF0i7 FkE0CGxMiwLrB9F8sw+VTgFnCk3xm0QwgfpDeQVifhD83Jk51pJc8L/vg63ANEGN FI4KKji7k/J2NbfQHxDG =2xQm -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Lambda Calculus question on equivalence
Hi, I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be observationally equivalent, but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Cheers -- Ian Price -- shift-reset.com Programming is like pinball. The reward for doing it well is the opportunity to do it again - from The Wizardy Compiled ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
The notion of equivalence you are talking about (normally L is referred to as a context) is 'extensional equality'; that is, functions f and g are equal if forall x, f x = g x. It's pretty easy to give a pair of functions which are not alpha equivalent but are observationally equivalent: if collatz_conjecture then true else bottom true / bottom (Depending on whether or not you think the collatz conjecture is true...) Cheers, Edward Excerpts from Ian Price's message of Thu May 02 12:47:07 -0700 2013: Hi, I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be observationally equivalent, but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Cheers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
At Thu, 02 May 2013 20:47:07 +0100, Ian Price wrote: I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be observationally equivalent, but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Yes, they can. Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’. These terms are not ‘definitionally’ equal (which could be the α-equivalence you cite but can be extended to fancier checks on the term structure). However, for all (well typed) inputs the result of those two functions are the same: they are ‘extensionally’ equal [1]. The first part (...(L A) is equivalent to (L B)...) holds: the same function will always produce the same output given definitionally equal arguments. You stumbled upon a subject that generated a great deal of research in the field of type theory [2]. There are various developments focusing on having a ‘better’ equality that identifies more things are equal. Your intuition of ‘observationally’ equal will probably be close to the notion of isomorphism between two sets, and in fact one of the more exciting developments right now concerns a type theory where equality is based on isomorphism [3]—however the computational ‘details’ haven’t been worked out yet :). There are other attempts [4] that fix the instance above (function extensionality) but don’t quite go all the way (not without reasons, since the isomorphism business has far reaching consequences that could be seen as impractical). Francesco [1]: https://en.wikipedia.org/wiki/Extensionality [2]: https://en.wikipedia.org/wiki/Intuitionistic_type_theory#Extensional_versus_intensional [3]: https://en.wikipedia.org/wiki/Homotopy_type_theory [4]: http://www.cs.nott.ac.uk/~txa/publ/obseqnow.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Markdown extension for Haddock as a GSoC project
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/05/13 20:52, Carter Schonwald wrote: indeed. That approach seems like the most likely to be successful within the scope of a single summer. That said, this does raise the question of what needs to be fixed up / added to the haddock grammar to a) make it a rich target for pandoc b) make sure the augmented haddock grammar is human friendly and we can give helpful syntax errors etc. Whats the status of this proposal for this years GSOC? Done well / right, it'd be super valuable for the community -Carter On Thu, May 2, 2013 at 4:46 AM, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: On 02/05/13 09:26, Andrew Butterfield wrote: My 2c (before such coins disappear...) On 2 May 2013, at 09:14, Petr Pudlák wrote: Hi, Personally I'd incline to choose some existing, well-established markup language with formal specification that supports math (hopefully there is one). So TeX/LaTeX is out then :-( Andrew Butterfield Tel: +353-1-896-2517 Fax: +353-1-677-2204 Lero@TCD, Head of Foundations Methods Research Group Director of Teaching and Learning - Undergraduate, School of Computer Science and Statistics, Room G.39, O'Reilly Institute, Trinity College, University of Dublin http://www.scss.tcd.ie/Andrew.Butterfield/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe With a reader and write module for new Haddock, you should be able to write LaTeX and convert that to Haddock and vice-versa. Some kind of Markdown was requested by popular demand but if we end up going the Pandoc way, we'll end up getting the plethora of already supported formats basically for free. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe Last time I checked, there are two proposals filed for this. One, to extend Haddock with features that have been long missing and extend it with things like GADTs etc. Then implement a Markdown notation alongside it. The other one is to extend Haddock to be... compatible with Pandoc and writing the modules. Only then, if time allows, any new extended features will be put in. Both effectively reach the goal of allowing Markdown but the first one provides support for just Markdown and now the ability to write the Pandoc modules if desired while the second one provides support for whatever formats Pandoc currently works with and allows for feature extensions from that point. I think that if more time was given and both projects were worked on independently, they would eventually reach the same level of features. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRgtUoAAoJEM1mucMq2pqXOvkQAJspywchNrrcphMUG6Rnk2pF 0ExpkcVGgbxeGLRBIlH3obi00yWdyPmaei4axbeMSdBB/fKvhb4pVxMKdlwr5mXc x+VAFPOuk5a+3C7FvAd+npkbQJumBGKWhtwKofJe45V8bYIVq+FlSBc/Z/Q4fmbH YFHt/kQy4oEmotxt2Y9BXNw+CNlx7PRMjXTj4I/C4rVjl3KOnna0pM6bJr2KHcp1 wqmDWo4GdoQQRfOkReBInuukZhIo2nfwkMH0NdC89Y4syiKHW4i1x2B7Yedp8H3u dB8H+K5WcX5T4WGzTexAi0yX08KKj11ZJ+d486Io89hmaCR64kMsfmwDpaP9npwX aUTO5dco4YziN5NFYFdM1ol5YgQlGpBMTbSiZQlY+HAHjfS9U04wU/pcijrxmxVh g0m0tbzcHRoEkdC97EsTpxPwjx7HFc8epu9W63bz8Q2Mu4CpxjL2XKl5qtiwfDig HV/v0tnvnH2l0Daz0+6SuFxn3st4H/UV/rnus1ZSb112rMu4XzROKLgyBj4BhRwb l0f+kLNF4dyBmRMuvfA8JG1ZnznN22tL0FDZEgYM+BkSwsyyUC9gEAj8sMFwG7+Y ch2yqxgKEQICFi0ryJanXOvU78ijDNVBgGUi6zDrgX5HySDiZkr4ggDYLGDM989o zxufPmUUXBzVEGlT4KPr =ijHF -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
On 05/02/2013 10:42 PM, Francesco Mazzoli wrote: At Thu, 02 May 2013 20:47:07 +0100, Ian Price wrote: I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be observationally equivalent, but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Yes, they can. Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’. Those are not lambda terms. Furthermore, if those terms are rewritten to operate on church numerals, they have the same unique normal form, namely λλλ 3 2 (3 2 1). These terms are not ‘definitionally’ equal (which could be the α-equivalence you cite but can be extended to fancier checks on the term structure). However, for all (well typed) inputs the result of those two functions are the same: they are ‘extensionally’ equal [1]. The first part (...(L A) is equivalent to (L B)...) holds: the same function will always produce the same output given definitionally equal arguments. ... (I guess the question is about untyped lambda calculus.) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
At Thu, 02 May 2013 23:16:45 +0200, Timon Gehr wrote: Yes, they can. Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’. Those are not lambda terms. How are they not lambda terms? Furthermore, if those terms are rewritten to operate on church numerals, they have the same unique normal form, namely λλλ 3 2 (3 2 1). You are assume things about the implementation of natural numbers, of *, and + (admittedly they were underspecified on my side :). They could be implemented in different way, or I could simply change the second definition to ‘λ x → x * 2’, in which case execution would be stuck on the abstract variable. In any case, definitionally different functions can be extensionally equal, there is little doubt on that. These terms are not ‘definitionally’ equal (which could be the α-equivalence you cite but can be extended to fancier checks on the term structure). However, for all (well typed) inputs the result of those two functions are the same: they are ‘extensionally’ equal [1]. The first part (...(L A) is equivalent to (L B)...) holds: the same function will always produce the same output given definitionally equal arguments. ... (I guess the question is about untyped lambda calculus.) I don’t think so, since Ian talked about ‘terminating’ λ-calculus, while the untyped λ-calculus isn’t... otherwise you can’t normalise and compare. Besides that, the typed calculi I cited are interesting because they internalise some notion of equality, but the observation about function extensionality holds with or without types. Francesco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
Excerpts from Timon Gehr's message of Thu May 02 14:16:45 -0700 2013: Those are not lambda terms. Furthermore, if those terms are rewritten to operate on church numerals, they have the same unique normal form, namely λλλ 3 2 (3 2 1). The trick is to define the second one as x * 2 (and assume the fixpoint operates on the first argument). Now they are not equal. Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
IIRC, Barendregt'84 monography (The Lambda Calculus: Its Syntax and Semantics) has a significant part of it devoted to this question. * Ian Price ianpric...@googlemail.com [2013-05-02 20:47:07+0100] Hi, I know this isn't perhaps the best forum for this, but maybe you can give me some pointers. Earlier today I was thinking about De Bruijn Indices, and they have the property that two lambda terms that are alpha-equivalent, are expressed in the same way, and I got to wondering if it was possible to find a useful notion of function equality, such that it would be equivalent to structural equality (aside from just defining it this way), though obviously we cannot do this in general. So the question I came up with was: Can two normalised (i.e. no subterm can be beta or eta reduced) lambda terms be observationally equivalent, but not alpha equivalent? By observationally equivalent, I mean A and B are observationally equivalent if for all lambda terms L: (L A) is equivalent to (L B) and (A L) is equivalent to (B L). The definition is admittedly circular, but I hope it conveys enough to understand what I'm after. My intuition is no, but I am not sure how to prove it, and it seems to me this sort of question has likely been answered before. Cheers -- Ian Price -- shift-reset.com Programming is like pinball. The reward for doing it well is the opportunity to do it again - from The Wizardy Compiled ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
On 05/02/2013 11:33 PM, Francesco Mazzoli wrote: At Thu, 02 May 2013 23:16:45 +0200, Timon Gehr wrote: Yes, they can. Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’. Those are not lambda terms. How are they not lambda terms? I guess if + and * are interpreted as syntax sugar then they are lambda terms with free variables. In this case, they are not equivalent. Furthermore, if those terms are rewritten to operate on church numerals, they have the same unique normal form, namely λλλ 3 2 (3 2 1). You are assume things about the implementation of natural numbers, of *, and + (admittedly they were underspecified on my side :). They could be implemented in different way, or I could simply change the second definition to ‘λ x → x * 2’, in which case execution would be stuck on the abstract variable. AFAICS this does not show anything either, as the terms λλλ 3 2 (3 2 1) and λλ 2 (λ 2 (2 1)) are not extensionally equivalent. (since their domain is not restricted to terms corresponding to church numerals. Eg. feed them λλ 2.) In any case, definitionally different functions can be extensionally equal, there is little doubt on that. These terms are not ‘definitionally’ equal (which could be the α-equivalence you cite but can be extended to fancier checks on the term structure). However, for all (well typed) inputs the result of those two functions are the same: they are ‘extensionally’ equal [1]. The first part (...(L A) is equivalent to (L B)...) holds: the same function will always produce the same output given definitionally equal arguments. ... (I guess the question is about untyped lambda calculus.) I don’t think so, since Ian talked about ‘terminating’ λ-calculus, while the untyped λ-calculus isn’t... 'terminating' does not occur in the original post. otherwise you can’t normalise and compare. ... The terms in question are already normalised. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
On 05/02/2013 11:37 PM, Edward Z. Yang wrote: Excerpts from Timon Gehr's message of Thu May 02 14:16:45 -0700 2013: Those are not lambda terms. Furthermore, if those terms are rewritten to operate on church numerals, they have the same unique normal form, namely λλλ 3 2 (3 2 1). The trick is to define the second one as x * 2 (and assume the fixpoint operates on the first argument). Now they are not equal. Edward Neither equal nor extensionally equivalent. mult = λm.λn.λf. n (m f) mult 2 = λn.λf. n (2 f) mult 2 = λn.λf. n (λx. f (f x)) flip mult 2 = λm.λf. 2 (m f) flip mult 2 = λm.λf.λx. m f (m f x) (λn.λf. n (λx. f (f x)) const = λf. const (λx. f (f x)) = λf.λa.λx. f (f x) This is clearly not the same as: (λm.λf.λx. m f (m f x)) const = λf.λx. f ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Lambda Calculus question on equivalence
At Fri, 03 May 2013 00:44:09 +0200, Timon Gehr wrote: On 05/02/2013 11:33 PM, Francesco Mazzoli wrote: At Thu, 02 May 2013 23:16:45 +0200, Timon Gehr wrote: Yes, they can. Take ‘f = λ x : ℕ → x + x’ and ‘g = λ x : ℕ → 2 * x’. Those are not lambda terms. How are they not lambda terms? I guess if + and * are interpreted as syntax sugar then they are lambda terms with free variables. In this case, they are not equivalent. + and * should be interpreted as term definitions, that can be replaced with the actual body, whatever that might be. I’m not sure about the ‘sugar’ you are talking about... but again these details don’t really matter. You are assume things about the implementation of natural numbers, of *, and + (admittedly they were underspecified on my side :). They could be implemented in different way, or I could simply change the second definition to ‘λ x → x * 2’, in which case execution would be stuck on the abstract variable. AFAICS this does not show anything either, as the terms λλλ 3 2 (3 2 1) and λλ 2 (λ 2 (2 1)) are not extensionally equivalent. (since their domain is not restricted to terms corresponding to church numerals. Eg. feed them λλ 2.) That’s a good point, but I was talking about typed terms. I guess the discussion does change if you go into the untyped lambda calculus but then you are opening a big can of worms regarding to termination (see below). I don’t think so, since Ian talked about ‘terminating’ λ-calculus, while the untyped λ-calculus isn’t... 'terminating' does not occur in the original post. ‘normal form’ does, which is what I was referring to. otherwise you can’t normalise and compare. ... The terms in question are already normalised. ‘(L A)’ and ‘(L B)’ are clearly not normalised (if L is a function). If the calculus is not terminating you need to explain what’s your strategy when comparing things that are not in a normal form already. Francesco ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
I'm sorry: it was showPackageId. And the tarball came from this page: http://www.informatik.uni-freiburg.de/~thiemann/WASH/ which certainly isn't secret to Gooliath: I got it by searching for haskell cgi html. I don't know why you can't download it. Anyway, I've noted your opinions but today I really need to get something done. Thanks for the discussion. Adrian. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Google Summer of Code Proposal - Communicating with mobile devices
Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish commented version because it was a project for my University, I will replace it for an English version in the next weeks) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be really grateful if you could give me your opinion about this project and the proposal. I want some feedback in order to know if this would be a useful tool and what you would like to get out of it. *Communicating with mobile devices* * * *Abstract* The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. Once we have this libraries, I will investigate the possibility of mainting a back and forth communication between a server and mobile devices and I will develop a library to handle this. * * *Motivation and expected benefits* I think this idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner. Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast). This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed. This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available. The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc. As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user. *Deliverables.* * * * An API library to build and send messages including: - GCM and a demo Android app. - APN and a demo iOS app. - Microsoft Push Notification Service (Windows Phone) and a demo app. - Documentation for all the code developed. Including the explantation on how to use the server library and how to try the demo apps. * A library to handle a back and forth comunication between a server and mobile devices. Tools to mantain a state of the connection and manage with a lot of devices at the same time. A Yesod app example of the use of this library and a demo app for each OS (Android, iOS, Windows Phone, etc) to manage this communication. * Optionally:
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 6:26 AM, Adrian May adrian.alexander@gmail.comwrote: So WASH is ancient history. OK, lets forget it. How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. GHC is up to 7.6. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? About 12 seconds, if you read http://www.haskell.org/platform/linux.html: Download the source tarball for Unix-like systems: here - *haskell-platform-2012.4.0.0.tar.gzhttp://lambda.haskell.org/platform/download/2012.4.0.0/haskell-platform-2012.4.0.0.tar.gz * - SHA-1: 7976508c50305969f64c721a1d095ae22efff8b7 Get and install GHC 7.4.2 prior to building the platform: - GHC 7.4.2 http://haskell.org/ghc/download_ghc_7_4_2.html Finally, unpack the Haskell Platform source tarball, and run (possibly with 'sudo'): ./configure make make install ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Google Summer of Code Proposal - Communicating with mobile devices
On 3 May 2013 08:53, Marcos Pividori marcospivid...@gmail.com wrote: Greetings, I am a Computer Science student from Argentina. I am interested in working this summer in a project related to Haskell for the Google Summer of Code. I have been discussing my idea with Michael Snoyman in order to have a clearer idea. Now, I would like to know the community interest in this project. I want to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. To pass a subject, I have recently worked with Yesod (a Web Framework based in Haskell) developing a server to comunicate with Android-powered devices through Google Cloud Messaging. (It is available: https://github.com/MarcosPividori/Yesod-server-for-GCM – It is a Spanish commented version because it was a project for my University, I will replace it for an English version in the next weeks) To develop this project, I have read a lot about this service and Yesod libraries, and I developed two programs, a server written in Haskell and an Android application for mobile phones. Also, I developed an EDSL to write programs which exchange information with the devices. I would be really grateful if you could give me your opinion about this project and the proposal. I want some feedback in order to know if this would be a useful tool and what you would like to get out of it. Communicating with mobile devices Abstract The aim of this project is to develop a server-side library in Haskell for sending push notifications to devices running different OS, such as Android, iOS, Windows Phone, BlackBerry, and so on. The fact is that every company is developing Push Notification services, and these are very similar. Then, I want to find the fundamental concepts to construct a library which enable to configure the options for the different services and send messages easily. When I say they are very similar, I refer to the fact that they all are asynchronous, best-effort services that offers third-party developers a channel to send data to apps from a cloud service in a power-efficient manner. The most popular are: - Google Cloud Messaging (Android) - Apple Push Notification Service (iPhone / iPad) - Microsoft Push Notification Service (Windows Phone) - BlackBerry Push Service (BlackBerry) - Windows Push Notification Services (Windows 8) - etc. Once we have this libraries, I will investigate the possibility of mainting a back and forth communication between a server and mobile devices and I will develop a library to handle this. Motivation and expected benefits I think this idea would be very useful because it will allow all Haskell developers to open to a new world of mobile devices and to build useful programs/services that interact with them. Pushing data to smartphones provides users with instant access to desired updates as they happen, such as news and weather, sports scores, stock prices and other time-sensitive content. The push services provide an efficient way to quickly push timely information updates to many smartphones at once, in a centrally managed and controlled manner. Generally, you can also be very selective in who you send information to, including individual customers or many customers (multicast). This services minimizes the impact on the smartphones battery life. Instead of actively checking for new data, the applications can remain closed. Once the data is delivered, the application can be launched in the background to process it as needed. This processes offer an alternative to other less efficient methods, such as polling, where a device regularly polls an application server to see if new content is available. The main differences between the services, refer to details as: the maxim payload length, the quality of service, queueing the messages or not, and the time limit for this, the way the messages are handled in the devices, etc. As all the libraries to access to these services are developed in Java, I thought that it would be a good idea to offer an option to Haskell programmers. Taking advantage of the similarity of these services, I could develop a very adaptable library which fits the necessities for each one and at the same time offer an abstraction to the user. Deliverables. * An API library to build and send messages including: - GCM and a demo Android app. - APN and a demo iOS app. - Microsoft Push Notification Service (Windows Phone) and a demo app. - Documentation for all the code developed. Including the explantation on how to use the server library and how to try the demo apps. * A library to handle a back and forth comunication between a server and mobile devices. Tools to mantain a state of the connection and manage with a lot of devices at the same time. A Yesod app example of the
Re: [Haskell-cafe] Backward compatibility
Emphatic agreement on this point. Likewise, the strong type system and the often helpful type error messages make it really easy to update code to work with more modern libs! -Carter On Thu, May 2, 2013 at 9:39 AM, David Thomas davidleotho...@gmail.comwrote: If you are actively using something then keep it up to date, encourage someone to keep it up to date, pay someone to keep it up to date, or migrate off of it. If you try building with a fresh set of packages every so often, you can catch breaking changes early and deal with them when it's typically pretty clear why things broke. On May 2, 2013 6:33 AM, Adrian May adrian.alexander@gmail.com wrote: So WASH is ancient history. OK, lets forget it. How about the Haskell Platform? Is that ancient history? Certainly not: it doesn't compile on anything but the very newest GHC. Not 7.4.1 but 7.4.2. Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? That's how I spent my afternoon today, instead of getting on with my job. Now you might think I was silly not to have uninstalled the linux package first, but I tried, and then decided against it because it thought the entire OS depended on it and actually proposed to remove everything from clib to googleearth as a solution. It's not Haskell's fault that linux package management is as broken as any other for the same reasons, but in an imperfect world, it's better not to keep moving the furniture around. Why was I trying to build the Haskell Platform at all? Because it wasn't obvious to me that a 7 year old library would be doomed. I find it perfectly normal to be able to compile C code from the 1970s but still run STL through the same compiler. That's why I blamed the system instead of the library. And unless somebody can explain to me how I would rescue my business now if I had opted for WASH in that long-forgotten era when Barack Obama was barely known, a Russian spy was poisoned with Polonium and a Sudanese man was ordered to marry a goat he was caught in an intimate position with, then I still see it that way. Adrian. On 2 May 2013 19:57, Ertugrul Söylemez e...@ertes.de wrote: John Lato jwl...@gmail.com wrote: I don't think there's anything wrong with moving at a fast pace, nor do I think backwards compatibility should be maintained in perpetuity. I think this statement pretty much covers the mindset of the Haskell community and also explains the higher breakage rate of Haskell packages when compared to other languages, in particular non-static ones: We move at a very fast pace. Innovations are made all the time. Without this feature we wouldn't be where we are today. Of course Haskell, being a rigorously static and correct language and a community that equally rigorously insists on correctness of design patterns we have to live with the fact that we need to fix the breakages we introduce, and we do that. This is a good thing. Unfortunately this leaves a lot of scope for migrations to be handled poorly, and for unintended consequences of shiny new systems. IMHO both have caused issues for Haskell developers and users in the recent and more distant past. This is an issue where I think the community should continually try to improve, and if a user calls out a difficulty we should at least try to learn from it and not repeat the same mistake. I think we do that. The most severe breakages are introduced by new GHC versions. That's why there is the Haskell Platform. If users decide to move to new versions sooner they should be prepared to handle the breakages. In particular a Haskell beginner simply shouldn't use GHC-HEAD. Our type system makes us aware of the breakages we introduce and gives us the opportunity to fix them properly before exposing them to the users. With this in mind I don't think there is anything to learn from this particular case. You wouldn't use WASH today for the same reasons you wouldn't use Linux 0.x. It's a legacy, and the ideas from it have inspired the more recent web frameworks, which are more convenient, faster, more real-world-oriented. In fact I totally expect a new generation of web frameworks to pop up in the future, more categorical, even more convenient and less error-prone. Greets, Ertugrul -- Key-ID: E5DD8D11 Ertugrul Soeylemez e...@ertes.de FPrint: BD28 3E3F BE63 BADD 4157 9134 D56A 37FA E5DD 8D11 Keysrv: hkp://subkeys.pgp.net/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org
Re: [Haskell-cafe] Backward compatibility
Now that's rapid maintenance, but it's still version hell because you've got to have that compiler installed first (even though HP is supposed to be a way to acquire haskell) and you probably haven't. You've probably got the one from the linux package which hasn't been maintained since, ooh, must have been at least a week ago, so you install the new one and you've trashed cabal. How long is that puzzle gonna take to unravel? About 12 seconds, if you read http://www.haskell.org/platform/linux.html: Download the source tarball for Unix-like systems: here - *haskell-platform-2012.4.0.0.tar.gzhttp://lambda.haskell.org/platform/download/2012.4.0.0/haskell-platform-2012.4.0.0.tar.gz * - SHA-1: 7976508c50305969f64c721a1d095ae22efff8b7 Get and install GHC 7.4.2 prior to building the platform: - GHC 7.4.2 http://haskell.org/ghc/download_ghc_7_4_2.html Finally, unpack the Haskell Platform source tarball, and run (possibly with 'sudo'): ./configure make make install Also, the Haskell Platform ./configure step checks which version of GHC you have installed, and requires you to pass the option --enable-*unsupported*-* ghc*-version in order to compile it with anything other than GHC 7.4.2. Did you try an unsupported version? And now you're complaining? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Also, the Haskell Platform ./configure step checks which version of GHC you have installed, and requires you to pass the option --enable-* unsupported*-*ghc*-version in order to compile it with anything other than GHC 7.4.2. Did you try an unsupported version? And now you're complaining? This is getting into minutia now, but yes I tried the unsupported flag and as I already explained it barfed about the prelude. So I installed 7.4.2 from source but that confused cabal because my attempt to uninstall the ubuntu package with 7.4.1 in had failed with dependency-hell. Figuring out why (or even that) my packages weren't being seen was the puzzle I was referring to. The point is that we wouldn't have to be talking about this at all if people didn't move the furniture around all the time. Likewise, the strong type system and the often helpful type error messages make it really easy to update code to work with more modern libs! I'm also a big fan of the error messages, but it's nice to know if I caused them or somebody else did. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
On Thu, May 2, 2013 at 8:43 PM, Adrian May adrian.alexander@gmail.comwrote: Also, the Haskell Platform ./configure step checks which version of GHC you have installed, and requires you to pass the option --enable-* unsupported*-*ghc*-version in order to compile it with anything other than GHC 7.4.2. Did you try an unsupported version? And now you're complaining? This is getting into minutia now, but yes I tried the unsupported flag and as I already explained it barfed about the prelude. How is it minutia that you expect an unsupported version of GHC to work? Yes, I try it out sometimes. And if it works, great. If not, too bad, I'll wait until the next Haskell Platform. I don't whine about it in public. So I installed 7.4.2 from source but that confused cabal because my attempt to uninstall the ubuntu package with 7.4.1 in had failed with dependency-hell. Figuring out why (or even that) my packages weren't being seen was the puzzle I was referring to. So the complaint is about Ubuntu? The point is that we wouldn't have to be talking about this at all if people didn't move the furniture around all the time. That's not a very good point. It sounds as though you're the one who moved furniture around, considering that you managed to mix up Ubuntu's GHC package with your hand-built ones. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal / cabal-install: special installation
Hi. This question dovetails off my previous thread. I described how I got ghc-7.6.3 installed from source onto an old RHEL5 machine. Naturally, I want to get cabal-install installed and start building great Hackage software. However, I have this quirk: I installed GHC to a special directory using ./configure --prefix=/specialdirectory/local. It is in my path, and works just fine. But when I try to build cabal-install, it claims it can't find Base, Cabal, and a few other things I know are installed. I know they are installed because I can see where they are installed and I can import stuff from them within GHCI. The result is the same whether I use the boot script, or whether I use runhaskell Setup configure (with or without a --prefix option). Is there another environment variable I need to set or something like that? (I need to emphasize that I do not want to install anything to $HOME, because my $HOME directory is shared across multiple systems.) -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Backward compatibility
Yes, I try it out sometimes. And if it works, great. If not, too bad, I'll wait until the next Haskell Platform. I don't whine about it in public. May I venture a guess that you never tried to manage a 5-10 million line project? That's what I do. I'm not a programmer, I'm a manager. I run teams of a few dozen people on subprojects within huge telecom-related projects, and my job is to try and keep it all from collapsing in a heap of bugs. If you had any experience of that you'd run a mile from any technology with this hit and miss attitude. I can't tell people what version they should be using because half of them work for a completely different company. They have their own dependencies coming from other projects that I'm not even allowed to know about. One of the ways I keep codebases alive is by telling people not to assume that somebody else is following the instructions in their heads. If anybody in my team wants to assume anything about the versions of anything they interact with, they'll need a very good argument as to why they can't make their bit more flexible. But I never had to be scared of upgrading any compiler, except python that is. Is anybody in the Haskell community still interested in attracting new users? If so I suggest you go play with Ruby on Rails. Then you'll know what it's like to approach a complex and unfamiliar system where every crumb requires a precise version of every other. If you had my job, you'd find out what you needed to know within half an hour. So I installed 7.4.2 from source but that confused cabal because my attempt to uninstall the ubuntu package with 7.4.1 in had failed with dependency-hell. Figuring out why (or even that) my packages weren't being seen was the puzzle I was referring to. So the complaint is about Ubuntu? I think we all know that package management is tricky and ubuntu are struggling, but that would be another topic. The point is that we wouldn't have to be talking about this at all if people didn't move the furniture around all the time. That's not a very good point. It sounds as though you're the one who moved furniture around, considering that you managed to mix up Ubuntu's GHC package with your hand-built ones. Well now you're just playing with words. I've already explained how it happened. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
