Re: [Haskell-cafe] MapReduce reverse engineered
Any idea how one might implement a multi note map and reduce network? Lets assume I have network of nodes that act as master and salve. How can I take a user code (containing his map reduce logic) and actually run it on different nodes? Daryoush 2009/2/24 Galchin, Vasili vigalc...@gmail.com Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/http://www.cs.vu.nl/%7Eralf/MapReduce/ Kind regards, Vasili ___ 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] Re: Hoogle and Network.Socket
Brandon Allbery wrote: On 2009 Feb 21, at 20:47, Jonathan Cast wrote: On Sat, 2009-02-21 at 07:25 -0700, John A. De Goes wrote: Not showing platform-specific packages by default *might* make package writers more likely to develop cross-platform packages. We've heard many times someone say, I don't know if it works on Windows, never really thought of that. Um, why *should* I think of that? I have to second this; I'm a Unix sysadmin, 98% of the time if I'm writing a program it's for Unix *and* requires POSIX APIxs, and even if it could apply to Windows the program needed there would be very significantly different. And we have a Windows group for that. I completely disagree, for the following reasons: 1. It's often easier (and almost never more difficult) to design for cross-platform support from the beginning than to add it later. 2. As of now, the Windows Group seems to be mostly Duncan. And while I greatly appreciate all the time and effort he continues to put into Windows support, he's got a lot to do and could use some help. If you can't help by joining the Windows group, at least you could make your own packages cross-platform. 3. It contributes to the Avoid success at all costs mantra often attributed to Haskell. I'm pretty sure that some people prefer this, but many (including myself) consider it at best misguided, and possibly harmful. 4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that? In some situations, it is true that a project is particularly tied to a Posix (or Windows) feature, and it wouldn't make sense to attempt a cross-platform version. If you're a Unix sysadmin and you use Haskell, that may be true most or all of the time. But for many packages, including most packages on hackage, it should be given consideration. Cheers, John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
I wonder what software licence I can use to release my application. I've developed some education tool with the following dependencies: % ghci Main.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main, UI, Lambda, Lambda.Eval, Lambda.Zipper, Lambda.Show, Lambda.Parser, Lambda.Common. Prelude Main main Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package time-1.1.2.2 ... linking ... done. Loading package glib-0.10.0 ... linking ... done. Loading package cairo-0.10.0 ... linking ... done. Loading package gtk-0.10.0 ... linking ... done. Loading package glade-0.10.0 ... linking ... done. I just don't know the options and I think licensing is subtle enough to ask for suggestions. Thanks in advance. -- Victor ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal: local documentation
Duncan Coutts wrote:
On Tue, 2009-02-24 at 17:42 +0100, Svein Ove Aas wrote:
2009/2/24 Felipe Lessa felipe.le...@gmail.com:
Just pass '--enable-documentation' to 'cabal install'. On *nix they're
generated at ~/.cabal/share/doc.
Or edit ~/.cabal/config and set the documentation key to True
However this does not maintain a complete module index like I think
Martijn is after.
Thank you all for the very helpful suggestions. I edited ~/.cabal/config
to generate documentation by default, and I set up Apache to serve the
documentation from http://haddock. I put a small PHP (gasp!) file in
~/.cabal/share/doc that lists all packages for which there is
documentation; see below. This is a good enough approximation for now.
Thanks again!
Martijn.
---
html
head
titleLocal Hackage packages/title
/head
body
h1Local Hackage packages/h1
ul
?
$handle = opendir(dirname(__FILE__));
while (false !== ($pkg = readdir($handle))) {
if ($pkg == . || $pkg == ..) continue;
$link = $pkg/html/;
if (file_exists(${link}index.html)) {
echo 'lia href=' . $link . '' . $pkg . '/a/li' . \n;
}
}
?
/ul
/body
/html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: forall ST monad
Ryan Ingram wrote: It believe that it's true that ((forall a. t a) - t') does not entail (exists a. t a - t') in constructivist logic, but I can't come up with a proof off the top of my head. Intuitively, to construct a value of type (E t t') you need to fix an a, and I don't think it's possible to do so. Here's something close to a counterexample, but I'm really confused. The objects of discourse are red, blue and green glass marbles T[a] = a is red \/ a is blue S= forall a. T[a] = all marbles are red or blue Now, (forall a. T[a]) - S is clearly true while exists a. (T[a] - S) should be nonsense: having one example of a marble that is either red or blue does in no way imply that all of them are, at least constructively. (It is true classically, but I forgot the name of the corresponding theorem.) I'm not quite sure how to make that rigorous; I would like to turn the above into a proper model of intuitionistic logic. The other problem is that in Haskell, forall does not quantify over glass marbles, but over types/propositions. Take T[a] = a S= forall a. T[a] = _|_ Once again, (forall a. T[a]) - S is true, but what about exists a. (a - _|_) = exists a. not a ? I mean, a can be a proposition now, so what about taking a = forall b.b = _|_ ? Does exists a imply that the example proposition constructed should true or is it enough to be able to construct a proposition at all? Regards, apfelmus -- http://apfelmus.nfshost.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
On Wed, 2009-02-25 at 14:22 +0300, Victor Nazarov wrote: I wonder what software licence I can use to release my application. I've developed some education tool with the following dependencies: % ghci Main.hs GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer ... linking ... done. Loading package base ... linking ... done. Ok, modules loaded: Main, UI, Lambda, Lambda.Eval, Lambda.Zipper, Lambda.Show, Lambda.Parser, Lambda.Common. Prelude Main main Loading package syb ... linking ... done. Loading package array-0.2.0.0 ... linking ... done. Loading package containers-0.2.0.0 ... linking ... done. Loading package bytestring-0.9.1.4 ... linking ... done. Loading package Win32-2.2.0.0 ... linking ... done. Loading package parsec-2.1.0.1 ... linking ... done. Loading package mtl-1.1.0.2 ... linking ... done. Loading package old-locale-1.0.0.1 ... linking ... done. Loading package time-1.1.2.2 ... linking ... done. Loading package glib-0.10.0 ... linking ... done. Loading package cairo-0.10.0 ... linking ... done. Loading package gtk-0.10.0 ... linking ... done. Loading package glade-0.10.0 ... linking ... done. I just don't know the options and I think licensing is subtle enough to ask for suggestions. Note that glib, gtk, cairo and glade are LGPL-2 (both the C libs and the Haskell libs). So that does not affect your license much. Read the LGPL version 2 for the details. Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MapReduce reverse engineered
Vasili, What do you mean? Googles MapReduce is already a published / well understood concept so no reverse engineering is needed. If you are asking about pre-existing implementations, there is at least one [1] but only for reference, not speed. If you are asking about community interest, great and you might want to say something on the haskell proposals reddit [2]. [1] http://www.cs.vu.nl/~ralf/MapReduce/ [2] http://www.reddit.com/r/haskell_proposals 2009/2/24 Galchin, Vasili vigalc...@gmail.com: Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/ Kind regards, Vasili ___ 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] MapReduce reverse engineered
I've read this article too, and I must say that it is indeed a very interesting and exciting read, both in terms of understanding MapReduce and its capabilities somewhat better, and in terms of beholding the beauty of Haskell. It is not exactly reverse engineering, but it is expressing the essense of MapReduce algorithms, prerequisites, axioms, dimensions of its design space etc. in Haskell. 2009/2/25 Thomas DuBuisson thomas.dubuis...@gmail.com: Vasili, What do you mean? Googles MapReduce is already a published / well understood concept so no reverse engineering is needed. If you are asking about pre-existing implementations, there is at least one [1] but only for reference, not speed. If you are asking about community interest, great and you might want to say something on the haskell proposals reddit [2]. [1] http://www.cs.vu.nl/~ralf/MapReduce/ [2] http://www.reddit.com/r/haskell_proposals 2009/2/24 Galchin, Vasili vigalc...@gmail.com: Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/ Kind regards, Vasili ___ 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 -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts: Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only allows linking, as far as I understand. I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
On Wed, 2009-02-25 at 10:23 +, John Lato wrote: 4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that? Sorry, wtf? I have a *responsibility* to design software for a miserably poorly-designed God-awful platform I'd have to pay *extra* for, and even then couldn't get source to or *fix* if I found a bug? No. You don't control me, to the best of my knowledge you haven't done squat for me, and by trying to force me to develop to *that* platform you are actively attempting to harm me. *plonk* jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Colin Paul Adams] Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
Wolfgang == Wolfgang Jeltsch g9ks1...@acme.softbase.org writes: Wolfgang Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Wolfgang Coutts: Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. Wolfgang I’m not sure whether this would be enough. .a and .o Wolfgang files are not compatible among GHC versions, as far as I Wolfgang know. Relinking against newer Gtk2Hs versions might not Wolfgang work. And a program using Gtk2Hs contains code from the Wolfgang .hi files of Gtk2Hs through inlining. So it’s not pure Wolfgang linking. However, the LGPL only allows linking, as far Wolfgang as I understand. Wolfgang I want to repeat what I’ve said earlier on this list: Wolfgang For Haskell, there is no real difference between LGPL Wolfgang and GPL, as far as I understand it. If you don’t want to Wolfgang force the users of your library to use an open source Wolfgang license for their work then use BSD3 or a similar Wolfgang license for your library. But IF there is no difference between LGPL and GPL for Haskell programs, then the licensing of gtk2hs as LGPL is just a smokescreen - it is effectively GPL, so you have to license your program as GPL. Which I'm all in favour of :-) -- Colin Adams Preston Lancashire ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] subscription problems for projects.haskell.org mailing list
Hello, I created a mailing list for Grapefruit on the Haskell Community Server (grapefr...@projects.haskell.org). If I try to subscribe to it, I receive a confirmation e-mail but my answers to this e-mail seem to get ignored. Does anyone have an idea what’s wrong here? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list
Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch: Hello, I created a mailing list for Grapefruit on the Haskell Community Server (grapefr...@projects.haskell.org). If I try to subscribe to it, I receive a confirmation e-mail but my answers to this e-mail seem to get ignored. Does anyone have an idea what’s wrong here? Confirmation via the weblink inside the confirmation e-mail works, by the way. Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Hoogle and Network.Socket
Jonathan Cast wrote: On Wed, 2009-02-25 at 10:23 +, John Lato wrote: 4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that? Sorry, wtf? I have a *responsibility* to design software for a miserably poorly-designed God-awful platform I'd have to pay *extra* for, and even then couldn't get source to or *fix* if I found a bug? I think there's a distinction between actively trying to support a specific platform, and simply trying to work in a cross-platform way, i.e. using the appropriate cross-platform APIs and packages where possible. Other people will already have done the work of making those things work on a specific platform, and if they don't work the issue can be raised with those people rather than you. No. You don't control me, to the best of my knowledge you haven't done squat for me, and by trying to force me to develop to *that* platform you are actively attempting to harm me. *plonk* Please could you moderate your tone? The original post wasn't aimed at you personally, it just expressed a general opinion about development practices, and certainly made no mention of forcing you or anyone else to do anything. By making it personal and expressing your response in rather intemperate language, you are adding more heat than light. In addition, the original subject of this thread is Hoogle, and if we take your comments in that context (and I do realise that your comments may have been generic rather than specific to Hoogle), then you have the choice of not using it at all, in which case you are not affected at all by its design choices; but if you do use it then the author certainly has done something for you, and his feeling that people should be encouraged to use cross-platform APIs where possible should certainly be accorded some respect. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MapReduce reverse engineered
Galchin, Maybe you are asking not only about remote execution, but also mobility of code. This is a problem that is previous to mapReduce, since mapReduce assumes that all the code (and the data) is in place in the respective nodes. In fact, the distribution of resources in order to efficiently use mapReduce is a design problem that the google people has done by hand. But my intuition says that there are a general algorithm for distribution of code, data, bandwidth and resources in general that moves around at execution time to achieve better and better performance for a given grid of nodes and for any task, for example, a mapReduce task. I would be very interesting to read something about this. I know that some efforts have been carried out the past , for example mobile haskell http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf which is a first step for this goal but I this has been discontinued and the source code is not available. 2009/2/25 Galchin, Vasili vigalc...@gmail.com Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/ Kind regards, Vasili ___ 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] Re: Hoogle and Network.Socket
On 2009 Feb 25, at 5:23, John Lato wrote: Brandon Allbery wrote: I have to second this; I'm a Unix sysadmin, 98% of the time if I'm writing a program it's for Unix *and* requires POSIX APIxs, and even if it could apply to Windows the program needed there would be very significantly different. And we have a Windows group for that. 2. As of now, the Windows Group seems to be mostly Duncan. And Wrong Windows group: Duncan doesn't work for us. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
Colin Paul Adams wrote: But IF there is no difference between LGPL and GPL for Haskell programs, then the licensing of gtk2hs as LGPL is just a smokescreen - it is effectively GPL, so you have to license your program as GPL. Which I'm all in favour of :-) I actually don't think this is 100% true. With the LGPL, you can distribute your program with under a non-GPL license, as long as you provide *some mechanism* for replacing the library and recreating the program. Normally this means dynamic linking. But it also allows you (I think) to distribute your program with a GPL-incompatible-but-nevertheless-open-source license, because that provides a mechanism for replacing the library (because you can rebuild the program from source). If you license the library under GPL, you cannot even do that. At least this is my understanding... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MapReduce reverse engineered
I agree. A distributed database could be made as usable as a standard RDBMS by offering an interface by which you supply a map/reduce pair of functions and a list (range?) of keys. This could be easily implemented with a database such as Scalaris, in which the Chord algorithm is responsible for placing and finding the data among nodes. The user would interface with any node in the distributed database, supplying a map and reduce function. It would distribute the map function to nodes of its choosing (weighted by some metrics such as idle cpu), retrieve the intermediate sets and run reduce if supplied. 2009/2/25 Alberto G. Corona agocor...@gmail.com: Galchin, Maybe you are asking not only about remote execution, but also mobility of code. This is a problem that is previous to mapReduce, since mapReduce assumes that all the code (and the data) is in place in the respective nodes. In fact, the distribution of resources in order to efficiently use mapReduce is a design problem that the google people has done by hand. But my intuition says that there are a general algorithm for distribution of code, data, bandwidth and resources in general that moves around at execution time to achieve better and better performance for a given grid of nodes and for any task, for example, a mapReduce task. I would be very interesting to read something about this. I know that some efforts have been carried out the past , for example mobile haskell http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf which is a first step for this goal but I this has been discontinued and the source code is not available. 2009/2/25 Galchin, Vasili vigalc...@gmail.com Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/ Kind regards, Vasili ___ 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 -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Binary, strict reading
Hi, I want to read a file using Data.Binary, and I want to read the file strictly - i.e. when I leave the read file I want to guarantee the handle is closed. The reason is that (possibly immediately after) I need to write to the file. The following is the magic I need to use - is it all necessary, is it guaranteed correct, should I use something else? src - decodeFile _make/_make Map.size mp `seq` performGC Thanks for all the helpful replies to the last post, I think I've nearly come up with a minimal test case I can give you, or at least characterise where the issue might lie. But I'll post to that thread when I've got the details. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] package code duplication
There was a question recently about being allowed to get into package internals, and I had a question. I want to use uvector's stream internals in ways that the exposed methods don't permit, but I don't especially want to use another package (e.g. vector, which does expose its internals) or reimplement my own stream fusion. Would it make sense to duplicate uvector's internals, copying licensing information and other stuff of course, inside my package? It's a suboptimal solution, but it seems better than the alternative... Louis Wasserman wasserman.lo...@gmail.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: package code duplication
wasserman.louis: There was a question recently about being allowed to get into package internals, and I had a question. I want to use uvector's stream internals in ways that the exposed methods don't permit, but I don't especially want to use another package (e.g. vector, which does expose its internals) or reimplement my own stream fusion. Would it make sense to duplicate uvector's internals, copying licensing information and other stuff of course, inside my package? It's a suboptimal solution, but it seems better than the alternative... I think just exposing them as a .Internal makes more sense, and is my preferred route (a la Data.ByteString.Internal) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary, strict reading
On Wed, Feb 25, 2009 at 2:15 PM, Neil Mitchell ndmitch...@gmail.com wrote: src - decodeFile _make/_make Map.size mp `seq` performGC Shouldn't you use rnf[1]? Also, there seems to be binary-strict on Hackage, but I don't know if it is being maintained anymore. HTH, [1] http://www.haskell.org/ghc/docs/latest/html/libraries/parallel/Control-Parallel-Strategies.html#v%3Arnf -- Felipe. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Memoization local to a function
Dear all, I have a function a computation of which is quite expensive, it is recursively dependent on itself with respect to some other function values - we can roughly model its behaviour with fib function (returns n-th number of Fibonacci's sequence). Unfortunately, it is not fib, it is far more complicated. Nevertheless, for demonstration of my question/problem I will use fib, it's quite good. I want to store results in a list (array, with its strong size limit that I do not know prior to computation, is not suitable) and then pick them up using (!!) operator. Well, if the list is global function/constant then it works quite well. Unfortunately, this is not, what I would like to have. Nevertheless, local version does not work. Could someone point me to some text that explains it? Memoization text on wiki does not seem to be helpful. Time/operation consumption is deduced from number of reductions reported by hugs and winhugs (tested both on Linux and Windows). Thank you for hints, Dusan P.S. Code I used for testing. module Testmemo ( fibW , fibL , fibM ) where fibW m = allfib !! m where allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] fibL m = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] in allfib !! m fibM n = myallfib !! n myallfib = 0:1:[myallfib!!n + myallfib!!(n+1) | n - [0..]] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Memoization local to a function
Dusan Kolar wrote: Nevertheless, local version does not work. Restructure your code like this: fibL m = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] in allfib !! m fibL = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] in \m - allfib !! m i.e. move the definition of the memo table outside the scope of the specific parameter you want to memoise over. Cheers, Ganesh === Please access the attached hyperlink for an important electronic communications disclaimer: http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html === ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] subscription problems for projects.haskell.org mailing list
Am Mittwoch, 25. Februar 2009 17:15 schrieb Wolfgang Jeltsch: Am Mittwoch, 25. Februar 2009 17:05 schrieb Wolfgang Jeltsch: Hello, I created a mailing list for Grapefruit on the Haskell Community Server (grapefr...@projects.haskell.org). If I try to subscribe to it, I receive a confirmation e-mail but my answers to this e-mail seem to get ignored. Does anyone have an idea what’s wrong here? Confirmation via the weblink inside the confirmation e-mail works, by the way. Meanwhile, I received automatic answers to my two unsuccesful confirmation e-mails. They both claim that the confirmation string is invalid. However, the confirmation string worked when confirming via the website. The only problem I can imagine at the moment is that the URLs with the confirmation string were broken into two lines in my confirmation e-mails. However, Mailman should take the string from the subject line, shouldn’t it? The error notifications told me that for each of my confirmation e-mails, the last paragraph was “ignored” while everything before it was “unprocessed”. What does that mean? Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary, strict reading
On Wed, Feb 25, 2009 at 12:15 PM, Neil Mitchell ndmitch...@gmail.com wrote: Hi, I want to read a file using Data.Binary, and I want to read the file strictly - i.e. when I leave the read file I want to guarantee the handle is closed. The reason is that (possibly immediately after) I need to write to the file. The following is the magic I need to use - is it all necessary, is it guaranteed correct, should I use something else? src - decodeFile _make/_make Map.size mp `seq` performGC Thanks for all the helpful replies to the last post, I think I've nearly come up with a minimal test case I can give you, or at least characterise where the issue might lie. But I'll post to that thread when I've got the details. Thanks Neil Funnily enough, I was just grappling with this issue in Yi. My solution was to make the read strict, so my function looked like this: readDB ∷ YiM ArticleDB readDB = io $ (dbLocation = r) `catch` (λ_ → return empty) where r x = fmap (decode · BL.fromChunks · return) $ B.readFile x -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] cabal install profiling and documentation
i've gone and cabal installed a lot of packages, but now i want to go back and install their profiling libraries and documentation. is there an easy way of doing this, short of reinstalling all of them (in the proper dependency order)? ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MapReduce reverse engineered
2009/2/25 Alberto G. Corona agocor...@gmail.com And it would solve a lot of problem: scalability, system re-configuraition and installation: just by adding or removing nodes at runtime.. heavy numerical computations are also good candidates. 2009/2/25 Rick R rick.richard...@gmail.com I agree. A distributed database could be made as usable as a standard RDBMS by offering an interface by which you supply a map/reduce pair of functions and a list (range?) of keys. This could be easily implemented with a database such as Scalaris, in which the Chord algorithm is responsible for placing and finding the data among nodes. The user would interface with any node in the distributed database, supplying a map and reduce function. It would distribute the map function to nodes of its choosing (weighted by some metrics such as idle cpu), retrieve the intermediate sets and run reduce if supplied. 2009/2/25 Alberto G. Corona agocor...@gmail.com: Galchin, Maybe you are asking not only about remote execution, but also mobility of code. This is a problem that is previous to mapReduce, since mapReduce assumes that all the code (and the data) is in place in the respective nodes. In fact, the distribution of resources in order to efficiently use mapReduce is a design problem that the google people has done by hand. But my intuition says that there are a general algorithm for distribution of code, data, bandwidth and resources in general that moves around at execution time to achieve better and better performance for a given grid of nodes and for any task, for example, a mapReduce task. I would be very interesting to read something about this. I know that some efforts have been carried out the past , for example mobile haskell http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf which is a first step for this goal but I this has been discontinued and the source code is not available. 2009/2/25 Galchin, Vasili vigalc...@gmail.com Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/ Kind regards, Vasili ___ 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 -- We can't solve problems by using the same kind of thinking we used when we created them. - A. Einstein ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
Heinrich Apfelmus wrote: Now, (forall a. T[a]) - S is clearly true while exists a. (T[a] - S) should be nonsense: having one example of a marble that is either red or blue does in no way imply that all of them are, at least constructively. (It is true classically, but I forgot the name of the corresponding theorem.) For the record, allow me to redress my earlier erroneous assertion by furnishing the proof for the classical case: (forall a. T(a)) - S = not (forall a. T(a)) or S, by defn of implication = not $ (forall a. T(a)) and (not S), by de Morgan's = not $ forall a. T(a) and (not S), product rule??? = exists a. not (T(a)) or S, de Morgan's again = exists a. T(a) - S, by defn of implication The only wrinkle is obviously in the logical and of (not S) distributing under the universal quantifier. -- View this message in context: http://www.nabble.com/forall---ST-monad-tp22024677p22208626.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] forall ST monad
On Wed, 2009-02-25 at 10:18 -0800, Kim-Ee Yeoh wrote: Heinrich Apfelmus wrote: Now, (forall a. T[a]) - S is clearly true while exists a. (T[a] - S) should be nonsense: having one example of a marble that is either red or blue does in no way imply that all of them are, at least constructively. (It is true classically, but I forgot the name of the corresponding theorem.) For the record, allow me to redress my earlier erroneous assertion by furnishing the proof for the classical case: (forall a. T(a)) - S = not (forall a. T(a)) or S, by defn of implication [For the record: this is the first point at which you confine yourself to classical logic.] = not $ (forall a. T(a)) and (not S), by de Morgan's = not $ forall a. T(a) and (not S), product rule??? This step depends on the domain of quantification for the variable a being non-empty; if the domain is empty, then the RHS is vacuously true, while the LHS is equal to (not S). = exists a. not (T(a)) or S, de Morgan's again = exists a. T(a) - S, by defn of implication The only wrinkle is obviously in the logical and of (not S) distributing under the universal quantifier. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] MapReduce reverse engineered
since mapReduce assumes that all the code (and the data) is in place in the respective nodes. As far as I can tell, the Hadoop, the open source implementation of map reduce, doesn't require your map reduce code to be in all nodes. It copies the jar files of the your application to the nodes that would execute the code. http://hadoop.apache.org/core/docs/current/mapred_tutorial.html#Job+Submission+and+Monitoring Data is also generally available via a network protocol such as http. I am wondering if distribution tools (such as Cabal) would be preferable to hadoop model. Instead of having the framework copy the code why not use the existing tools to install the code prior to running the map-reduce? daryoush 2009/2/25 Alberto G. Corona agocor...@gmail.com Galchin, Maybe you are asking not only about remote execution, but also mobility of code. This is a problem that is previous to mapReduce, since mapReduce assumes that all the code (and the data) is in place in the respective nodes. In fact, the distribution of resources in order to efficiently use mapReduce is a design problem that the google people has done by hand. But my intuition says that there are a general algorithm for distribution of code, data, bandwidth and resources in general that moves around at execution time to achieve better and better performance for a given grid of nodes and for any task, for example, a mapReduce task. I would be very interesting to read something about this. I know that some efforts have been carried out the past , for example mobile haskell http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf%C2%A0 http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf http://homepages.inf.ed.ac.uk/stg/workshops/TFP/book/DuBois/duboismhaskell/cameraready.pdf%C2%A0 which is a first step for this goal but I this has been discontinued and the source code is not available. 2009/2/25 Galchin, Vasili vigalc...@gmail.com Hello, Here is an interesting paper of Google's MapReduce reverse engineered into Haskell. I apologize if already posted . http://www.cs.vu.nl/~ralf/MapReduce/http://www.cs.vu.nl/%7Eralf/MapReduce/ Kind regards, Vasili ___ 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 http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
On Wednesday 25 February 2009 07:47:16 am Wolfgang Jeltsch wrote: Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts: Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only allows linking, as far as I understand. I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library. Best wishes, Wolfgang Alternatively Haskell could add shared library support, like every other language. Regards, -- Conrad Meyer kon...@tylerc.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
Conrad Meyer wrote: On Wednesday 25 February 2009 07:47:16 am Wolfgang Jeltsch wrote: Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts: Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. However, the LGPL only allows linking, as far as I understand. I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library. Best wishes, Wolfgang Alternatively Haskell could add shared library support, like every other language. As has already been discussed on this list, shared library support to obtain substitutability of libraries is problematic in a language like Haskell too, at least AFAIU. Just consider cross .o inlining... (Using shared libraries in order to decrease system-wide memory footprint of Haskell binaries is however a bit easier.) /M -- Magnus Therning(OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe Haskell is an even 'redder' pill than Lisp or Scheme. -- PaulPotts signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Status of Haskell under OsX
Hi, I'm planning to purchase a MacBookPro so I'm wondering how well Haskell is supported under this platform. Thanks, Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of Haskell under OsX
I use Haskell under OSX only. I find it very well supported. -Ross On Feb 25, 2009, at 2:37 PM, Cristiano Paris wrote: Hi, I'm planning to purchase a MacBookPro so I'm wondering how well Haskell is supported under this platform. Thanks, Cristiano ___ 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] Status of Haskell under OsX
I've got an iMac; ghc from MacPorts seems to work fine. On 25 Feb 2009, at 22:37, Cristiano Paris wrote: Hi, I'm planning to purchase a MacBookPro so I'm wondering how well Haskell is supported under this platform. Thanks, Cristiano ___ 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] Status of Haskell under OsX
On Wednesday 25 February 2009 11:37:15 am Cristiano Paris wrote: Hi, I'm planning to purchase a MacBookPro so I'm wondering how well Haskell is supported under this platform. Thanks, Cristiano GHC on linux/ppc is not very well supported, but since all new macbooks are intel that shouldn't be an issue. And you're probably going to run OS X anyways. Regards, -- Conrad Meyer kon...@tylerc.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Memoization local to a function
On Wed, Feb 25, 2009 at 10:38 AM, Dusan Kolar ko...@fit.vutbr.cz wrote: I have a function a computation of which is quite expensive, it is recursively dependent on itself with respect to some other function values - we can roughly model its behaviour with fib function (returns n-th number of Fibonacci's sequence). Unfortunately, it is not fib, it is far more complicated. Nevertheless, for demonstration of my question/problem I will use fib, it's quite good. I suggest using data-memocombinatorshttp://hackage.haskell.org/cgi-bin/hackage-scripts/package/data-memocombinatorsfor this rather than rolling your own. It accomplishes the same thing, but makes the choice of memo structure independent of the code that uses it (and Memo.integral has asymptotically better performance than a list). Luke I want to store results in a list (array, with its strong size limit that I do not know prior to computation, is not suitable) and then pick them up using (!!) operator. Well, if the list is global function/constant then it works quite well. Unfortunately, this is not, what I would like to have. Nevertheless, local version does not work. Could someone point me to some text that explains it? Memoization text on wiki does not seem to be helpful. Time/operation consumption is deduced from number of reductions reported by hugs and winhugs (tested both on Linux and Windows). Thank you for hints, Dusan P.S. Code I used for testing. module Testmemo ( fibW , fibL , fibM ) where fibW m = allfib !! m where allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] fibL m = let allfib = 0:1:[allfib!!n + allfib!!(n+1) | n - [0..]] in allfib !! m fibM n = myallfib !! n myallfib = 0:1:[myallfib!!n + myallfib!!(n+1) | n - [0..]] ___ 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] Status of Haskell under OsX
The one thing that isn't supported in GHC on Mac OS is the generation of 64-bit code (better if you have lots of RAM you want to take advantage of, and also has a lot more independent registers for tight loops), but with any luck that will change soon (I've been trying to get it to work). Cheers, Dan On Wed, Feb 25, 2009 at 2:52 PM, Conrad Meyer kon...@tylerc.org wrote: On Wednesday 25 February 2009 11:37:15 am Cristiano Paris wrote: Hi, I'm planning to purchase a MacBookPro so I'm wondering how well Haskell is supported under this platform. Thanks, Cristiano GHC on linux/ppc is not very well supported, but since all new macbooks are intel that shouldn't be an issue. And you're probably going to run OS X anyways. Regards, -- Conrad Meyer kon...@tylerc.org ___ 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] Memoization local to a function
On Wed, 25 Feb 2009, Luke Palmer wrote: On Wed, Feb 25, 2009 at 10:38 AM, Dusan Kolar ko...@fit.vutbr.cz wrote: I have a function a computation of which is quite expensive, it is recursively dependent on itself with respect to some other function values - we can roughly model its behaviour with fib function (returns n-th number of Fibonacci's sequence). Unfortunately, it is not fib, it is far more complicated. Nevertheless, for demonstration of my question/problem I will use fib, it's quite good. I suggest using data-memocombinators for this rather than rolling your own. It accomplishes the same thing, but makes the choice of memo structure independent of the code that uses it (and Memo.integral has asymptotically better performance than a list). Nice to know that there is a package for this purpose. See also http://haskell.org/haskellwiki/Memoization___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Wolfgang Jeltsch wrote: I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library Of course there is a difference and a *significant* one. * A GPL library will force commercial users of the library to release their code under GPL. * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. The users of the commercial program maybe be forbidden to redistribute the application source code as well as modifying the application source code e.g. to avoid licensing restrictions imposed on them by the application seller (the LGPL library user). The commercial program owner does not even need to distribute the source code with the application by default. It just needs to provide an easy way to obtain the source code for all licensed customers (those who bought it) and let them prominently know (maybe in the about box of the application) where to get the source for the purpose of recompilation with a newer version of the LGPL libs. Providing source code without any other rights than to recompile with a newer version of a LGPL lib should not be such a big deal ... that is if the commercial application author's business model does not depend on some super secret process in the code or does not have something fishy stuff to hide :) The above does not represent a difference only when you assume that all your users are crooks which will redistribute everything without a bit of hesitation. Then it is up to you whether you wan to sue them :) Am I missing something? Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek pher...@gmail.com wrote: * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On 2009 Feb 25, at 5:23, John Lato wrote: Brandon Allbery wrote: I have to second this; I'm a Unix sysadmin, 98% of the time if I'm writing a program it's for Unix *and* requires POSIX APIxs, and even if it could apply to Windows the program needed there would be very significantly different. And we have a Windows group for that. 2. As of now, the Windows Group seems to be mostly Duncan. And Wrong Windows group: Duncan doesn't work for us. Sorry, I misunderstood you. I thought you meant a Windows group within the Haskell community, not within your company. Honestly, what I wrote wasn't directed at you. As I mentioned before, writing code as a Unix sysadmin has very different priorities than writing for many other problem domains. Most of your code wouldn't make sense outside a Unix context, whereas bytestrings, tries, or graph libraries would. Cheers, John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
* Peter Verswyvelen bugf...@gmail.com [2009-02-25 23:15:24 +0100]: On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek pher...@gmail.com wrote: * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine... Google doesn't distribute code or binaries for google.com, though (although there is the appliance stuff..) -- mithrandi, i Ainil en-Balandor, a faer Ambar signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Peter Verswyvelen wrote: On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek pher...@gmail.com wrote: * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine... I think so. If you acknowledge them as legitimate users and you distribute the free program then you must allow them to upgrade the LGPL library. With Haskell this may mean releasing the source code. I'm vary about this part though. *.o and *.hi may be enough since: * GHC is not LGPL but some kind of BSD * only the gmp and gtk2hs are LGPL * so you do not need to make sure ghc can be upgraded * you need to make sure gmp can be upgraded and gtk2hs can be upgraded but forcing users on the same version of ghc * requirement to allow upgrade is there only while the LGPL library does not change interface The above should allow to distribute only *.o and *.hi files. If user wants to to upgrade GMP or GTK2HS they can do it and recompile with the old version of GHC (the one for which you provided *.o and *.hi files. So my opinion (IAMNAL): 1) source code under very limiting commercial license (just to allow recompile with a newer LGPL lib and nothing else) is OK 2) it is probable that only the *.o, *.hi files and a linking script are OK too As for as Google: That is a different case. The GPL/LGPL limitations kick in *only* when you redistribute your program. Goolge is not redistributing their search engine! They only provide you a service over internet! That is very different. Peter. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
So that is interesting. If you don't distribute a program that makes use of LPGL libs (e.g. a downloadable EXE), but you provide a remote view (in this case a web) on a server that runs that program, then the license does not apply... Oh well I should just let the lawyers look into all these licenses, it's not my domain. 2009/2/25 Tristan Seligmann mithra...@mithrandi.net * Peter Verswyvelen bugf...@gmail.com [2009-02-25 23:15:24 +0100]: On Wed, Feb 25, 2009 at 11:02 PM, Peter Hercek pher...@gmail.com wrote: * An LGPL library will force commercial users to release their source code only to the users of their program (which already bought it) and only for the purpose of recompiling with a newer version of the LGPL library. Does this also mean one can't make closed source but *free* software that uses LGPL libs? Since all users can then potentially request the source code? E.g. suppose Google would have used LGPL libraries to implement parts of their search engine... Google doesn't distribute code or binaries for google.com, though (although there is the appliance stuff..) -- mithrandi, i Ainil en-Balandor, a faer Ambar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmlx4YACgkQpNuXDQIV94rO6gCeLp5pkzXQkXIfFmwwCSWHQX3o QscAn1ipd1Sft/K5QKiYtT9y15ssdnrk =sZXJ -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] differences between Data.Array and Data.Vector
Hi. In Hackage there are some packages named *array*, and others named *vector*. What are the differences? Is available a guide to the various data structures available in Haskell? Thanks Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
John Lato jwl...@gmail.com wrote: On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On 2009 Feb 25, at 5:23, John Lato wrote: Brandon Allbery wrote: I have to second this; I'm a Unix sysadmin, 98% of the time if I'm writing a program it's for Unix *and* requires POSIX APIxs, and even if it could apply to Windows the program needed there would be very significantly different. __And we have a Windows group for that. 2. __As of now, the Windows Group seems to be mostly Duncan. __And Wrong Windows group: __Duncan doesn't work for us. Sorry, I misunderstood you. I thought you meant a Windows group within the Haskell community, not within your company. Honestly, what I wrote wasn't directed at you. As I mentioned before, writing code as a Unix sysadmin has very different priorities than writing for many other problem domains. Most of your code wouldn't make sense outside a Unix context, whereas bytestrings, tries, or graph libraries would. I don't think it makes sense to talk about missing support on any platform: In a strict sense, how well a platform is supported is a function of how many people care to use it. While there seems to be a disparity between people developing programs on/for Windoze and people working on Windoze's cross-platform capabilities wrt. Haskell, this does not mean that you can rightfully expect people who chose not to use your favourite platform to give a damn about it. Search for allies amidst your pals. I honestly doubt that iff a viable[1] way to support multiple platforms exists any developer aware of it would choose a platform-locked in alternative. This is the only thing you can hope for, and the only thing you need to provide to other developers to get platform support for free. There's a free lunch, after all, but you gotta bring your own dishes. Or pay someone to spoon-feed you, but that's another issue. [1] Which mostly means negligible additional work for the developer -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: base-4 + gtk2hs-0.10.0 licensing
Peter Verswyvelen bugf...@gmail.com wrote: So that is interesting. If you don't distribute a program that makes use of LPGL libs (e.g. a downloadable EXE), but you provide a remote view (in this case a web) on a server that runs that program, then the license does not apply... Oh well I should just let the lawyers look into all these licenses, it's not my domain. That's what the Affero GPL is designed for: You have to provide source to everyone who's able to use the program, not just to those that are able to run it. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] popularity context with Cabal
Hi. Debian some time ago introduced the popularity context, to find the most installed/used packages: http://popcon.debian.org/ Is it possible to do something similar with Cabal? From popularity-context FAQ: For each package, popularity-contest looks at the most recently used (based on atime) files, and reports the filename, its last access time (atime) and last change time (ctime). However, some files are not considered, because they have unreliable atime. A computer 'vote' for a package if according to the data provided in the report, a program provided or depending on the package was used less than thirty days ago. This computation is performed by the popcon server. Manlio Perillo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
On Wed, Feb 25, 2009 at 3:49 PM, Jonathan Cast jonathancc...@fastmail.fm wrote: On Wed, 2009-02-25 at 10:23 +, John Lato wrote: 4. Cross-platform concerns are something that responsible developers need to consider, just like localization and i18n. I.e., why *shouldn't* you think of that? Sorry, wtf? I have a *responsibility* to design software for a miserably poorly-designed God-awful platform I'd have to pay *extra* for, and even then couldn't get source to or *fix* if I found a bug? No. You don't control me, to the best of my knowledge you haven't done squat for me, and by trying to force me to develop to *that* platform you are actively attempting to harm me. I'm not trying to force you (or anyone else) to do anything. All I'm saying is that, as a developer, you should consider that your unix-dependent software will never reach over 80% of the computer users available. Now, I don't know anything about what sort of software you write, maybe your market segment is big iron so you've already made a decision to ignore Windows. Maybe you hate Windows so much you want to deprive its users of your code. I honestly don't care. As a former ASP.Net developer, I can assure you I have no love for MS. By responsible developer, I meant accountable for decisions made during development. It's fine to say you don't know if your code doesn't run on Windows because you've made a decision to not support it (or actively work against it, as the case may be). It's not fine to say you don't know because you never thought about it. Cheers, John Lato ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] base-4 + gtk2hs-0.10.0 licensing
On Wed, 2009-02-25 at 16:47 +0100, Wolfgang Jeltsch wrote: Am Mittwoch, 25. Februar 2009 14:33 schrieb Duncan Coutts: Note that some people will tell you that by a strict interpretation of the LGPL that statically linked Haskell libs under that license are a pain in the backside. When we decided on that license for gtk2hs that was not our intention. In other words nobody is going to sue you if you statically link gtk2hs libs. Of course if you need a cast iron legal guarantee then that's not good enough and you'd have to ship .a and .o files to let users relink if they wanted to. I’m not sure whether this would be enough. .a and .o files are not compatible among GHC versions, as far as I know. I recall from a FSF FAQ on this issue that it doesn't need to be easy, just technically possible. There does not need to be a well designed stable ABI. Relinking against newer Gtk2Hs versions might not work. And a program using Gtk2Hs contains code from the .hi files of Gtk2Hs through inlining. So it’s not pure linking. It is pure linking. It's just not easily achievable from the source level using standard compilers and tools. Yes if you change the sources you change the ABI (even when you did not change the API). That's not a problem as far as the license is concerned (I think). However, the LGPL only allows linking, as far as I understand. I want to repeat what I’ve said earlier on this list: For Haskell, there is no real difference between LGPL and GPL, as far as I understand it. If you don’t want to force the users of your library to use an open source license for their work then use BSD3 or a similar license for your library. But of course that is not the only difference. Assuming we can work around the linking issue the main point for someone to choose LGPL is guaranteeing that changes are contributed back. We should not tell people who want to use LGPL that they should just use BSD. That's changing the spirit of the license for the sake of a mere technicality. If they want to use the LGPL then we should encourage them to use a linking exception. It's also worth looking at what the LGPL-3 has done about this issue. Duncan (who takes no position on BSD vs LGPL and has used both) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary, strict reading
On Wed, 2009-02-25 at 17:15 +, Neil Mitchell wrote: Hi, I want to read a file using Data.Binary, and I want to read the file strictly - i.e. when I leave the read file I want to guarantee the handle is closed. The reason is that (possibly immediately after) I need to write to the file. The following is the magic I need to use - is it all necessary, is it guaranteed correct, should I use something else? src - decodeFile _make/_make Map.size mp `seq` performGC I suggest you use withFile instead and decode from the Handle that gives you (via hGetContents) rather than decodeFile from the file name. That makes it much clearer. Of course you have to avoid doing lazy stuff, but that should be ok, Binary is strict in reading by default. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
John Lato jwl...@gmail.com wrote: you should consider that your unix-dependent software will never reach over 80% of the computer users available. Now it's me... wtf? Why should I care? If those users are not even willing to bend their little finger to safe me from breaking my back attempting to support their wretched pile of junk that is being deliberately trying to boycott cross-platform compability, may they rot away, together with any notion of software quality or sense of responsibility to care about stuff you deem important that _might_ be left in the camp of microslaves. And Microsoft itself, while I'm at it. Being helpful and contributing to a gift society is all Good and Great, but there's a line that has to be drawn to prevent it from collapsing: Never, ever, let your actions be dictated by parasitary leeches. If you want it done, do it. Let your actions tell others that you are standing on the right side of that line, and you _will_ benefit from society. If not, STFU or GTFO. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
Achim Schneider wrote: John Lato jwl...@gmail.com wrote: On Wed, Feb 25, 2009 at 4:45 PM, Brandon S. Allbery KF8NH allb...@ece.cmu.edu wrote: On 2009 Feb 25, at 5:23, John Lato wrote: Brandon Allbery wrote: I have to second this; I'm a Unix sysadmin, 98% of the time if I'm writing a program it's for Unix *and* requires POSIX APIxs, and even if it could apply to Windows the program needed there would be very significantly different. __And we have a Windows group for that. 2. __As of now, the Windows Group seems to be mostly Duncan. __And Wrong Windows group: __Duncan doesn't work for us. Sorry, I misunderstood you. I thought you meant a Windows group within the Haskell community, not within your company. Honestly, what I wrote wasn't directed at you. As I mentioned before, writing code as a Unix sysadmin has very different priorities than writing for many other problem domains. Most of your code wouldn't make sense outside a Unix context, whereas bytestrings, tries, or graph libraries would. I don't think it makes sense to talk about missing support on any platform: In a strict sense, how well a platform is supported is a function of how many people care to use it. While there seems to be a disparity between people developing programs on/for Windoze and people working on Windoze's cross-platform capabilities wrt. Haskell, this does not mean that you can rightfully expect people who chose not to use your favourite platform to give a damn about it. Search for allies amidst your pals. Somehow I really gave off the wrong impression. Windows is most definitely not my favorite platform. My primary development computer is currently a MacBook, and my secondary system runs Linux. I'm advocating for Windows for two reasons: 1. There are a non-trivial number of Windows Haskellers, and they frequently post about problems on this list. I would like to make their lives a little better.. 2. A substantial portion of computer users are on Windows. If I want them to use my software, or even expose them to the glory of Haskell, I need to speak their language. A possible third reason is that I have used some number of gnu-toolchain-developed programs on Windows (using mingw), and the experience is frequently miserable. Graphics libraries lag, all sorts of configuration errors, missing packages, etc. Compared to that, the GHC compiler chain and libraries are fantastic. It pretty much works, and I think it can be better. I would like to see a wider adoption of Haskell in general, and improving Haskell support for windows is would definitely help. I honestly doubt that iff a viable[1] way to support multiple platforms exists any developer aware of it would choose a platform-locked in alternative. This is the only thing you can hope for, and the only thing you need to provide to other developers to get platform support for free. There's a free lunch, after all, but you gotta bring your own dishes. Or pay someone to spoon-feed you, but that's another issue. I think Haskell is a lot closer to this than many other languages. Generally, Haskell packages that don't work on Windows fall into one of three categories: 1. Packages that link to a C library, in which case it depends on the underlying library. 2. Packages that are closely tied to Unix/Posix. 3. Packages that depend on one of the above (or another in this category). It's the third category that's mostly under discussion here. If Package A is posix-dependent, but a cross-platform alternative is available, then by using the cross-platform alternative Package B really can get Windows compatibility for free (assuming equivalent functionality between alternatives). I really don't see anything wrong with using Hoogle to increase awareness (although I would appreciate it if platform-specific packages were searched as an option). Cheers, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
John Lato jwl...@gmail.com wrote: I really don't see anything wrong with using Hoogle to increase awareness (although I would appreciate it if platform-specific packages were searched as an option). You won't hear me argue against it, in fact, I argued in favour of it. Increasing awareness of cross-platform solutions, as well as providing them, is a very different thing than demanding cross-platform support. If 80% of all computer users use Windows, there shouldn't be any problems recruiting a decent number of volunteers to care about Haskell's Windoze support, should there? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
It's a chicken-egg thing. A Linux or OS X developer tries Haskell and finds he can write useful programs right away, with a minimum of fuss. But a Windows user tries Haskell and finds he has access to very few of the really good libraries, and even the cross-platform libraries won't build without substantial effort. As a result, I bet it's easier for a Linux or OS X developer to like Haskell than a Windows developer. I use OS X exclusively myself, but I'll ensure my first published Haskell library is cross-platform compatible, because I think it's good for the community. The more people using Haskell, the more libraries that will be written, the more bugs that will be fixed, the more creativity that will be poured into development of libraries and the language itself. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 25, 2009, at 5:29 PM, Achim Schneider wrote: John Lato jwl...@gmail.com wrote: I really don't see anything wrong with using Hoogle to increase awareness (although I would appreciate it if platform-specific packages were searched as an option). You won't hear me argue against it, in fact, I argued in favour of it. Increasing awareness of cross-platform solutions, as well as providing them, is a very different thing than demanding cross-platform support. If 80% of all computer users use Windows, there shouldn't be any problems recruiting a decent number of volunteers to care about Haskell's Windoze support, should there? -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] Re: Hoogle and Network.Socket
On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote: It's a chicken-egg thing. A Linux or OS X developer tries Haskell and finds he can write useful programs right away, with a minimum of fuss. But a Windows user tries Haskell and finds he has access to very few of the really good libraries, and even the cross-platform libraries won't build without substantial effort. As a result, I bet it's easier for a Linux or OS X developer to like Haskell than a Windows developer. I use OS X exclusively myself, but I'll ensure my first published Haskell library is cross-platform compatible, because I think it's good for the community. The more people using Haskell, the more libraries that will be written, the more bugs that will be fixed, the more creativity that will be poured into development of libraries and the language itself. I don't think this is founded in experience. The experience of the last 5 years is that the more people use Haskell, the more important backward-compatibility concerns become, and the harder it becomes for Haskell to continue evolving. Creativity being poured into a language doesn't do much good if the result is the language moving sideways, still less the language growing sideways. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
I don't think it's that black and white. At the lower end, when the language is controlled by a few, there's not much innovation poured into the language or libraries, and there are no tools to support development. As the community grows, you see much more innovation in language and libraries, and maybe a few primitive tools. With much greater, the community demands backward compatibility, so the language itself may only evolve in highly constrained ways (ways that are usually detrimental to consistency), but the library space explodes with innovation, and the tools become extremely powerful. Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 25, 2009, at 5:52 PM, Jonathan Cast wrote: On Wed, 2009-02-25 at 17:54 -0700, John A. De Goes wrote: It's a chicken-egg thing. A Linux or OS X developer tries Haskell and finds he can write useful programs right away, with a minimum of fuss. But a Windows user tries Haskell and finds he has access to very few of the really good libraries, and even the cross-platform libraries won't build without substantial effort. As a result, I bet it's easier for a Linux or OS X developer to like Haskell than a Windows developer. I use OS X exclusively myself, but I'll ensure my first published Haskell library is cross-platform compatible, because I think it's good for the community. The more people using Haskell, the more libraries that will be written, the more bugs that will be fixed, the more creativity that will be poured into development of libraries and the language itself. I don't think this is founded in experience. The experience of the last 5 years is that the more people use Haskell, the more important backward-compatibility concerns become, and the harder it becomes for Haskell to continue evolving. Creativity being poured into a language doesn't do much good if the result is the language moving sideways, still less the language growing sideways. jcc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
John A. De Goes j...@n-brain.net wrote: Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied. And this is why we must avoid success: It would mean instant failure. There are already enough hype-languages around, there's not too much of a point to add one to them. Haskell won't stop evolving and (conservatively) keeping up with PL research until that's done, or Dependent Typing is well-understood, whatever comes first. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
Achim Schneider bars...@web.de wrote: whatever comes first. uhhh, make that whatever comes last -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
2009/2/22 Luke Palmer lrpal...@gmail.com: On Sun, Feb 22, 2009 at 8:15 AM, John Meacham j...@repetae.net wrote: On Sun, Feb 22, 2009 at 03:36:34PM +0100, Peter Verswyvelen wrote: Would it be possible to separate the frontend (Haskell to Core) and backend (Core to machine code) from the Haskell compilers (requiring a standard Core language?) I'm not sure how many extensions required a change to the Core language. Well, it depends on what you mean by 'core'. If you mean a desugared version of haskell, I think such a front end could be quite useful. By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) The ghc-api exposes a type for annotated source: http://haskell.org/ghc/docs/latest/html/libraries/ghc/GHC.html#t%3ATypecheckedSource Not that i know how to use it. Luke in particular, I'd like to see a standalone implementation of template haskell. If you mean something lower level, as in the ghc core intermediate language the compiler uses internally, or jhc's core or grin representation, things get a bit more tricky. Although many core languages are somewhat similar, based on a typed lambda calculus of some sort, the details will differ, and translating between them can be lossy. For instance, looking at jhc core: http://repetae.net/computer/jhc/manual.html#jhc-core-type-system you can see it has a very rich language for dealing with strictness and boxedness. For instances, a boxed value known to be in WHNF actually has a different _type_ than one that is possibly unevaluated. Such distinctions are quite useful for jhc's back end but not so much for ghc's, hence ghc core doesn't make that distinction and any translation between the two would 'lose' that useful information. In other cases things are even worse, for instance ghc has a powerful type equality concept in its core language which jhc has no counterpart for, so that information will be lost on translation. But losing that information will actually cause the core to not type check, since ghc core can type some things jhc core cannot (and vice versa) so coercions or other mechanisms to bypass the type system will have to be introduced. So, it is certainly possible to translate between the two, in fact, I made a jhc core - ghc core translator, but the code it produced was necessarily riddled with unsafeCoerce#'s for everywhere the type systems didn't quite match up. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ 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 http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Hoogle and Network.Socket
The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting from the research that's already gone into it. That means some tradeoffs. Haskell is already behind state-of-the art in PL research and it seems unlikely to catch up (witness the slow evolution of Haskell' and the non-existent progress on Haskell2). Of course, I could be wrong. Regards, John A. De Goes N-BRAIN, Inc. The Evolution of Collaboration http://www.n-brain.net|877-376-2724 x 101 On Feb 25, 2009, at 6:19 PM, Achim Schneider wrote: John A. De Goes j...@n-brain.net wrote: Personally, I'd be happy to see that explosion of innovation in the library and tool spaces, even if it means the language itself stops evolving (for the most part). It will make it a lot easier do use Haskell commercially, and the innovators in the language space will find or invent a new target to keep themselves occupied. And this is why we must avoid success: It would mean instant failure. There are already enough hype-languages around, there's not too much of a point to add one to them. Haskell won't stop evolving and (conservatively) keeping up with PL research until that's done, or Dependent Typing is well-understood, whatever comes first. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ 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] jhc speed
On 23/02/2009, at 2:22 AM, Luke Palmer wrote: By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) Luke Hi Luke, Any progress on that front? How much desugaring do you want? What kind of annotations do you want? Can you get what you need from the GHC API? Cheers, Bernie. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Hoogle and Network.Socket
John A. De Goes j...@n-brain.net wrote: The problem is that PL research is probably not going to stop evolving in our lifetimes. Yes, that research needs a venue, but why should it be Haskell? Haskell is a good language and it's time to start benefiting from the research that's already gone into it. That means some tradeoffs. Why shouldn't it be Haskell? So then, build an enterprise-style language using it, noone is going to stop you. Noone is going to stop you benefiting from it, either. You might have to have to pay the price of a moving target, though, as people just won't stop innovating. Tradeoffs, everywhere... Haskell is already behind state-of-the art in PL research and it seems unlikely to catch up (witness the slow evolution of Haskell' and the non-existent progress on Haskell2). Of course, I could be wrong. Not really, look at e.g. type families, which give you much of the power dependently typed languages give you while saying nah, not yet to the question of how to deal with non-terminating typechecking. Haskell walks the line between well-understood and bleeding edge, leaning a bit towards well-understood, for sanity's and stability's sake. About the H' progress... It's hard to tell how many drops are needed to make a bucket overflow, especially if you've got no idea what the bucket looks like. What certainly isn't happening is people taking a house, trying to overflow a badly leaking bucket. -- (c) this sig last receiving data processing entity. Inspect headers for copyright history. All rights reserved. Copying, hiring, renting, performance and/or quoting of this signature prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] jhc speed
On Wed, Feb 25, 2009 at 7:43 PM, Bernie Pope bj...@csse.unimelb.edu.auwrote: On 23/02/2009, at 2:22 AM, Luke Palmer wrote: By the way, coming up pretty soon, I will need a desugared annotated Haskell for Dana. If anybody has something like this in the works, I'd love to help with it. If it does not exist by the time I need it, I will make it, so if anyone is interested in working on it with me, let me know :-) Luke Hi Luke, Any progress on that front? Not yet. It's still a few items down in the queue. How much desugaring do you want? What kind of annotations do you want? Enough desugaring to make Haskell simple (yes, I know that's subjective). Probably somewhere around System-F (Fw perhaps, once I learn what that is). The main things I can think of are getting rid of special notation (do, list comp., where clauses, infix operators) and expanding typeclasses to dictionary passing. Can you get what you need from the GHC API? I haven't looked into it, but my guess is not. The main requirement is that it (and its desugared target) needs to be really pure (no IO, FFI, or polymorphic seq), and that it must be able to desugar itself. It might provide a good launching point though. Luke ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] popularity context with Cabal
On 2009 Feb 25, at 18:06, Manlio Perillo wrote: Debian some time ago introduced the popularity context, to find the most installed/used packages: http://popcon.debian.org/ Is it possible to do something similar with Cabal? I believe that's a planned feature for Hackage. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon universityKF8NH PGP.sig Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary, strict reading
Neil Mitchell wrote: Hi, I want to read a file using Data.Binary, and I want to read the file strictly - i.e. when I leave the read file I want to guarantee the handle is closed. The reason is that (possibly immediately after) I need to write to the file. The following is the magic I need to use - is it all necessary, is it guaranteed correct, should I use something else? src - decodeFile _make/_make Map.size mp `seq` performGC With binary 0.5, src - decodeFile _make/_make return $! src should close the file, assuming that all the data is read from the file, thanks to this patch: Mon Aug 25 23:01:09 CEST 2008 Don Stewart d...@galois.com * WHNF the tail of a bytestring on decodeFile, will close the resource For older versions, import qualified Data.Binary.Get as Get data EOF = EOF instance Binary EOF where get = do eof - Get.isEmpty return (if eof then EOF else error EOF expected) put EOF = return () ... (src, EOF) - decodeFile _make/_make accomplishes the same effect. Btw, contrary to what Duncan said, Get is a lazy monad (lazy in its actions, that is): instance Binary EOF where get = do eof - Get.isEmpty when (not eof) error EOF expected return EOF put EOF = return () does not help, because the result (EOF) does not depend on the value returned by isEmpty. The idea of using isEmpty for closing the file is not perfect though; due to the lazy nature of Get, there's a stack overflow lurking below: main = do encodeFile w.bin [0..100 :: Int] m - decodeFile w.bin print $ foldl' (+) 0 (m :: [Int]) One idea to fix this is to force the read data before checking for EOF, as follows: data BinaryRNF a = BinaryRNF a instance (NFData a, Binary a) = Binary (BinaryRNF a) where get = (\a - rnf a `seq` BinaryRNF a) `fmap` get put (BinaryRNF a) = put a main = do encodeFile w.bin [0..100 :: Int] (BinaryRNF m, EOF) - decode `fmap` L.readFile w.bin print $ foldl' (+) 0 (m :: [Int]) HTH, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Binary, strict reading
I wrote: With binary 0.5, Or binary 0.4.3 and later. Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
