Re: [Haskell-cafe] Why Not Haskell?
Brian Hulley [EMAIL PROTECTED] writes: I meant even a non-programmer in the sense of even someone who is not a C hacker to show that the threat of people being able to steal code from a program is not the only source of problems that GPL could impose on a commercial application. No derogatory implication towards people who choose not to learn computer programming was intended. The GPL itself refers to a cost of distribution, since it recognizes such things are not free-in-price. This is in reference to offering a copy of the source code. The price of a binary copy can be as large as desired. Likewise for the cost of support. Well I understand the free as in free speech not free beer motto, but suppose person A is talented at writing software but prefers a peaceful existence and lacks the contacts/refs/desire/energy etc to be a consultant or contractor, and has had the bad experience of being forced to work extremely long hours with low pay while in an employed position, and person B is outgoing, ebullient, and talented at marketing and advertising. Now person A spends some years quietly writing some code, which uses a GPL library and is therefore GPL'd, and sells it, as is his/her right under the GPL to person B. Then person B is free, as in free speech to do whatever he/she likes with the software, and so in particular could use his/her marketing skills to completely undermine person A's one and only hope of earning a living, so from person A's point of view the *amortized* effect of the GPL is to make his/her software free as in free beer as well. Then someone discovers a bug in the program of person A. Person B is being so busy being outgoing, ebullient and effervescent that he does not easily find the cause of the bug. Moreover the code needs to be ported to a the new Warthog MacOSX release. Person A being not only talented but also shrewd now uses the contractual obligations of person B as leverage to screw him out of most of his previously made profit for delivering said work. He lived peacefully ever after. What is this, Economic Analysis by Parable? Immanuel -- *** I can, I can't. Tubbs Tattsyrup -- Immanuel Litzroth Software Development Engineer Enfocus Software Antwerpsesteenweg 41-45 9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: [EMAIL PROTECTED] web : www.enfocus.be *** ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Variants of a recursive data structure
Christian Maeder schrieb:
How about the following simple parameterization?
data Exp label = LNum Int label
| LAdd (Exp label) (Exp label) label
It seems I've forgotten some icing. Usually I provide the following
datatype and function for folding in order to avoid many explicit
recursive calls.
data FoldExp label c = FoldExp
{ foldLNum :: Exp label - Int - label - c
, foldLAdd :: Exp label - c - c - label - c }
foldExp :: FoldExp label c - Exp label - c
foldExp f e = case e of
LNum i l - foldLNum f e i l
LAdd e1 e2 l - foldLAdd f e (foldExp f e1) (foldExp f e2) l
Your mapping can be defined than as:
mapLabel :: Exp label - Exp ()
mapLabel = foldExp FoldExp
{ foldLNum = \ _ i _ - LNum i ()
, foldLAdd = \ _ e1 e2 _ - LAdd e1 e2 () }
This still requires to list all variants in this case but saves the
recursive calls. (The lambda-terms could be shorter if the labels were
the first argument of every constructor.)
The first argument of each fold-field is not necessary here but may come
in handy if you want to process the expressions not only bottom up but
also top-down. (The original expression are also available i.e. in a
lambda-term foldLAdd = \ (LAdd o1 o2 _) e1 e2 _ - ...)
The above record datatype and the corresponding fold function(s) could
be derived somehow (with TH-haskell) -- even for mutual recursive data
types.
Cheers Christian
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Type inference problem
2006/8/6, Joel Björnson [EMAIL PROTECTED]: So far, so good... However, problems arises trying to define the function : test = toElem myElemYielding the error message : 'No instance for (Show Elem) arising use of `toElem` at ...' For some reason it seems like the type checker picks the *wrong* 'toElem', and that the type of 'myElem' can't be properly determined (without adding explicit type signatures). It seems strange though the the type of myElem really can be determined and that the instance (IsElem Elem) is more specific then the instance for Show types. I've received some information pointing me to that the problem arises due to the -fallow-incoherent-instances flag, which I´ve been using. Without this flag the function 'test' above works as expected... /Joel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
On Sun, Aug 06, 2006 at 10:46:16AM +0100, Chris Kuklewicz wrote: [...] The GPL only gets in the way if you put it there by choosing to derive work from GPL code. Note that most commercial programs do not allow you the choice of deriving your work from theirs at all. The GPL adds to your free-as-in-freedom: you can derive work from others' GPL work and you can GPL also brings about restrictions to freedom-in-speech that are rarely mentioned: Say you develop the code for a client to run her production facilities. This code contains sensitive information about the way the facilities work and must not fall into the hands of the client's competitors. But if GPL is stuck to any part of the code and manages to infect the rest, the client can make you sign as many NDAs as there can be. The GPL still entitles you to sell it. I'm sure there are other scenarios in which the restritions that GPL places on the developer are equally prohibitive. GPL/LGPL is interesting, LGPL v3 may turn into something cool or not. (I heard they have problems sorting out the above scenario, too, or something more tricky, I forgot.) But placing restrictions on how the code may be used has lead to surprising problems. BSD on the other hand is a safe bet. cheers, matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Variants of a recursive data structure
Klaus Ostermann wrote: [...] data Exp e = Num Int | Add e e data Labelled a = L String a newtype Mu f = Mu (f (Mu f)) type SimpleExp = Mu Exp type LabelledExp = Mu Labelled Exp The SimpleExp definition works fine, but the LabeledExp definition doesn't because I would need something like Mu (\a - Labeled (Exp a)) where \ is a type-level lambda. However, I don't know how to do this in Haskell. I'd need something like the . operator on the type-level. One way, that I haven't spotted in any of the replies so far, is to declare a composition type data BComp m n a = BC (m (n a)) as seen in http://web.cecs.pdx.edu/~mpj/pubs/springschool.html , so that type LabelledExp = Mu (BComp Labelled Exp) See http://haskell.cs.yale.edu/pipermail/haskell/2001-May/003942.html for more crafty tricks, including making Eq instances for such Mu-based recursive structures. Regards, Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
There is a false statement that must be corrected, about NDA's. Matthias Fischmann wrote: On Sun, Aug 06, 2006 at 10:46:16AM +0100, Chris Kuklewicz wrote: [...] The GPL only gets in the way if you put it there by choosing to derive work from GPL code. Note that most commercial programs do not allow you the choice of deriving your work from theirs at all. The GPL adds to your free-as-in-freedom: you can derive work from others' GPL work and you can GPL also brings about restrictions to freedom-in-speech that are rarely mentioned: Say you develop the code for a client to run her production facilities. This code contains sensitive information about the way the facilities work and must not fall into the hands of the client's competitors. But if GPL is stuck to any part of the code and manages to infect the rest, the client can make you sign as many NDAs as there can be. The GPL is not a disease that infects. That is a metaphor made by people who hate such licenses. The GPL does not blow in the window or from someone's sneeze and get stuck to code. To introduce GPL derived code is a choice made be the programmer. You can always choose not to derive from GPL code, and you can always change your mind later and rewrite the derived code so you can remove it. Talking about biological metaphors is deliberately misleading. ...the client can make you sign as many NDAs as there can be. The GPL still entitles you to sell it. I'm sure there are other scenarios in which the restritions that GPL places on the developer are equally prohibitive. No. You are wrong. Google for GPL and NDA gives http://www.gnu.org/licenses/gpl-faq.html : Does the GPL allow me to distribute a modified or beta version under a nondisclosure agreement? No. The GPL says that anyone who receives a copy of your version from you has the right to redistribute copies (modified or not) of that version. It does not give you permission to distribute the work on any more restrictive basis. Does the GPL allow me to develop a modified version under a nondisclosure agreement? Yes. For instance, you can accept a contract to develop changes and agree not to release your changes until the client says ok. This is permitted because in this case no GPL-covered code is being distributed under an NDA. You can also release your changes to the client under the GPL, but agree not to release them to anyone else unless the client says ok. In this case, too, no GPL-covered code is being distributed under an NDA, or under any additional restrictions. The GPL would give the client the right to redistribute your version. In this scenario, the client will probably choose not to exercise that right, but does have the right. As the developer you can sign an NDA and it will bind you. But it will not bind the client. GPL/LGPL is interesting, LGPL v3 may turn into something cool or not. (I heard they have problems sorting out the above scenario, too, or something more tricky, I forgot.) But placing restrictions on how the code may be used has lead to surprising problems. BSD on the other hand is a safe bet. Note that there are many people who will not do work on a BSD project since a company can just come along and take it. People are free to choose GPL or BSD for their work and then other people are free to choose whether to derive work from them. But if there was no GPL and the only choice was BSD then much of the current GPL'd work would not exist. -- Chris ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
Matthias Fischmann wrote: But if GPL is stuck to any part of the code and manages to infect the rest, the client can make you sign as many NDAs as there can be. The GPL still entitles you to sell it. Nonsense. The GPL says, *if* you distribute a binary, *then* you also have to distribute the complete, machine readable source. It also specifically says that if that is impossible (because of an NDA or whatever), you must not distribute the software at all. Have you ever read the damn thing?! Udo. -- Wo die Macht geistlos ist, ist der Geist machtlos. -- aus einem Gipfelbuch signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why Haskell?
Hello All, Thanks for the many helpful replies to my question about the suitability of Haskell for industrial/commercial application. From those I gather there are no licensing problems regarding the use of the standard functions and modules. Use of proprietary modules may or not be restricted by the authors, but of course this is to be expected and fair. Performance and size of Haskell programs don't seem to be problematic either, at least for small and medium size applications. Tool support, however, is less than for the more established languages. But maybe the Eclipse support which is under development will be a boost. Also, there are good interfaces with open source gui widgets etc. So, the summary conclusion would be that Haskell can be used (and is being used) provided the developers are aware that unexpected problems may arise in practice. Advantages of Haskell seem to be short size of code (and all the advantages that implies) and the high abstraction level and mathematical rigour (which makes for less programming errors). As for the 'popularity' of Haskell, someone made the very common sense remark that all successful languages have been promoted by some large corporation. (Please note 'successful' stands for 'spread of use', not 'quality' here.) If fp is to reach the mainstream, it will probably be because of some centralized support from outside the academic world. Maybe something like a 'Haskell Consortium' or 'Haskell Initiative' to promote Haskell should be set up. An example could be the promotion of SystemC for hardware and software co-design by the Open SystemC Initiative www.systemc.org . Availability of an IEEE standard for Haskell would also be a good thing for its acceptance, I think. That is, assuming 'mainstream' is the goal, of course. Regards, Hans van Thiel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
Note that there are many people who will not do work on a BSD project since a company can just come along and take it. People are free to choose GPL or BSD for their work and then other people are free to choose whether to derive work from them. But this is just the thing, isn't it? The GPL has its purpose, and is a great license for applications like Apache or RedHat, where you don't want companies to just come along and take the code. But for library code, which is what this discussion was all about from the beginning, why ever would you *not* want anyone, anywhere, to take and use your code? And in particular so for Haskell, where we are striving hard to make industry catch on. /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
On Mon, Aug 07, 2006 at 12:57:47PM +0100, Chris Kuklewicz wrote: To: Matthias Fischmann [EMAIL PROTECTED] CC: haskell-cafe@haskell.org From: Chris Kuklewicz [EMAIL PROTECTED] Date: Mon, 07 Aug 2006 12:57:47 +0100 Subject: Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing) There is a false statement that must be corrected, about NDA's. Sorry. Just learned something, thanks! Matthias Fischmann wrote: On Sun, Aug 06, 2006 at 10:46:16AM +0100, Chris Kuklewicz wrote: [...] The GPL only gets in the way if you put it there by choosing to derive work from GPL code. Note that most commercial programs do not allow you the choice of deriving your work from theirs at all. The GPL adds to your free-as-in-freedom: you can derive work from others' GPL work and you can GPL also brings about restrictions to freedom-in-speech that are rarely mentioned: Say you develop the code for a client to run her production facilities. This code contains sensitive information about the way the facilities work and must not fall into the hands of the client's competitors. But if GPL is stuck to any part of the code and manages to infect the rest, the client can make you sign as many NDAs as there can be. The GPL is not a disease that infects. That is a metaphor made by people who hate such licenses. The GPL does not blow in the window or from someone's sneeze and get stuck to code. To introduce GPL derived code is a choice made be the programmer. You can always choose not to derive from GPL code, and you can always change your mind later and rewrite the derived code so you can remove it. Talking about biological metaphors is deliberately misleading. Sorry, I didn't mean to offend anybody, or be misleading. I like GPL, but I also like the disease metaphor (although is not as much being sneezed at as having sex with somebody :-). And it's really not as easy to control as you suggest: If you ever take in a single patch under the GPL, or even implement a new feature in an obvious way that has been implemented by somebody else under the GPL, you are in trouble. AFAIR this happened to SSH.com with the bigint code in ssh-v1.3, but if you contradict me now I have to take your word for it. (So please do! :) http://www.gnu.org/licenses/gpl-faq.html : Does the GPL allow me to distribute a modified or beta version under a nondisclosure agreement? No. The GPL says that anyone who receives a copy of your version from you has the right to redistribute copies (modified or not) of that version. It does not give you permission to distribute the work on any more restrictive basis. (In my example I was worried about *less* restrictive, but the subsequent points seem to cover that, too.) GPL/LGPL is interesting, LGPL v3 may turn into something cool or not. (I heard they have problems sorting out the above scenario, too, or something more tricky, I forgot.) But placing restrictions on how the code may be used has lead to surprising problems. BSD on the other hand is a safe bet. Note that there are many people who will not do work on a BSD project since a company can just come along and take it. People are free to choose GPL or BSD for their work and then other people are free to choose whether to derive work from them. But if there was no GPL and the only choice was BSD then much of the current GPL'd work would not exist. I tend to agree. Would be fun to have some empirical data to boost the accuracy of the 'much' part of this. cheers, Matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Haskell?
For me library support, for networking in particular, has been the major hurdle. It gets problematic when too many libraries are still marked as experimental and only partially implements the specification (e.g. protocol) that they are supposed to handle. Also after a quick look at the source for some common (networking) libraries I found a few too many calls to error to feel comfortable. It's not okay for a library to bring down my application behind my back, error should be reported even if this uglifies the code and interfaces. Furthermore I think that Haskell would benefit from moving some commonly used functionality such as HTTP, SQL and XML support into the standard libraries. I haven't seen any news about the progress of HaskellNet but I guess it could solve my problems. I really don't have much problems with tool support, speed and the like. I'm convinced it's a library (and library documentation!) thing. As for the 'popularity' of Haskell, someone made the very common sense remark that all successful languages have been promoted by some large corporation. (Please note 'successful' stands for 'spread of use', not 'quality' here.) If fp is to reach the mainstream, it will probably be because of some centralized support from outside the academic world. Maybe something like a 'Haskell Consortium' or 'Haskell Initiative' to promote Haskell should be set up. An example could be the promotion of SystemC for hardware and software co-design by the Open SystemC Initiative www.systemc.org . Availability of an IEEE standard for Haskell would also be a good thing for its acceptance, I think. Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there... Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Haskell?
On 07/08/06, Johan Tibell [EMAIL PROTECTED] wrote: Having someone pay a group of people to hack on Haskellimplementations would indeed be desirable. Without knowing the detailsUbuntu looks like a promising model. If we could just find a willingbillionaire out there... If I were a billionaire I'd love to sponsor haskell development. Hmm, I'll add it to my goal list ;)Regards,-- Intelligence is like a river: the deeper it is, the less noise it makes ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Why Haskell?
Hello Piotr, Monday, August 7, 2006, 5:29:10 PM, you wrote: Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there... If I were a billionaire I'd love to sponsor haskell development. Hmm, I'll add it to my goal list ;) too late - GHC is many years funded by MS Research -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re[2]: [Haskell-cafe] Re: Why Haskell?
Hello Johan, Monday, August 7, 2006, 5:25:34 PM, you wrote: think that Haskell would benefit from moving some commonly used functionality such as HTTP, SQL and XML support into the standard libraries. http, smtp and other networking protocols - yes. xml/sql is too large things. actually, haxml package is already included in GHC sources distribution and i think that it should be excluded from there because it's too large, far more than any other package bundled with GHC -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Why Haskell?
If I were a billionaire I'd love to sponsor haskell development. Hmm, I'll add it to my goal list ;) too late - GHC is many years funded by MS Research I'm aware of that, I was just making a call for more money to deal with organizational stuff (running haskell.org, creating and maintaining a Cabal package database etc) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Re: Why Haskell?
http, smtp and other networking protocols - yes. xml/sql is too large things. actually, haxml package is already included in GHC sources distribution and i think that it should be excluded from there because it's too large, far more than any other package bundled with GHC The problem I'm having with SQL right now is that there are a number of not complete and splintered implementation efforts. Having one library outside GHCs libraries but still promoted as the default implementation (and hosted under haskell.org) would be enough. Same for XML. I think most of my problems would be solved if cabal-get turned out to something like Ruby Gems so I could easily pull the packages I need to the machines I need (and also get dependencies and a way to remove the packages without leaving files scattered on my file system). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re:Re: Why Haskell
From: Hans van Thiel [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Johan Tibell [EMAIL PROTECTED] Subject: Re: [Haskell-cafe] Re: Why Haskell? Date: Mon, 07 Aug 2006 17:21:17 +0200 On Mon, 2006-08-07 at 15:23 +0200, Johan Tibell wrote: For me library support, for networking in particular, has been the major hurdle. It gets problematic when too many libraries are still marked as experimental and only partially implements the specification (e.g. protocol) that they are supposed to handle. Also after a quick look at the source for some common (networking) libraries I found a few too many calls to error to feel comfortable. It's not okay for a library to bring down my application behind my back, error should be reported even if this uglifies the code and interfaces. Furthermore I think that Haskell would benefit from moving some commonly used functionality such as HTTP, SQL and XML support into the standard libraries. I haven't seen any news about the progress of HaskellNet but I guess it could solve my problems. That's good to know, thanks! I really don't have much problems with tool support, speed and the like. I'm convinced it's a library (and library documentation!) thing. Likewise. Having someone pay a group of people to hack on Haskell implementations would indeed be desirable. Without knowing the details Ubuntu looks like a promising model. If we could just find a willing billionaire out there.. Candidates would be companies that have an interest in promoting Haskell and/or fp, large and small. Ericsson comes to mind, if they are still active in fp. Or maybe one of the rising Indian, Chinese or or other 'globalization' firms could be the principal here? Personally, I'd love to see a Brazilian company like, for example, PetroBras pick this up. And just from a PR point of view, Haskell does project a cutting edge image. Anyway... Regards, Hans Cheers, Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
Matthias Fischmann wrote: And it's really not as easy to control as you suggest: If you ever take in a single patch under the GPL, This kind of thing doesn't happen by accident. Patches don't magically creep into your code, you have to apply them deliberately and you should always know whether you are allowed to do so. Applying a BSD-licensed patch and neglecting to mention the author may get you into exactly as much trouble. or even implement a new feature in an obvious way that has been implemented by somebody else under the GPL, you are in trouble. Bullshit again, for the GPL applies to code, not to ideas. Unless you believe that copyright law does indeed apply to ideas, *and* that a GPL-developer will come after you for reimplementing (not copying) his work, you have nothing to fear unless you outright steal code. May I humbly suggest some reading, like the text of the GPL itself and then something basic about copyright law? AFAIR this happened to SSH.com with the bigint code in ssh-v1.3 SSH included GMP, which was licensed under the GPL. Nothing happened there, only the OpenSSH folks disliked the license and reimplemented GMP. Udo. -- The imagination of nature is far, far greater than the imagination of man. -- Richard Feynman signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why Not Haskell? (sidenote on licensing)
Udo, us: mf: AFAIR this happened to SSH.com with the bigint code in ssh-v1.3 SSH included GMP, which was licensed under the GPL. Nothing happened there, only the OpenSSH folks disliked the license and reimplemented GMP. ... and had to fight an ugly battle over the question whether the reimplementation was legitimate reuse of ideas or code theft. I don't understand why you have to be so insulting. I was making a false claim because I didn't know better, but I don't consider that a good reason to claim everything I am saying is bullshit and start a bar fight. Anyway this is not only getting ugly but also way off topic. I'm out. cheers, Matthias signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why Not Haskell?
Well I understand the free as in free speech not free beer motto, but suppose person A is talented at writing software but prefers a peaceful existence and lacks the contacts/refs/desire/energy etc to be a consultant or contractor, and has had the bad experience of being forced to work extremely long hours with low pay while in an employed position, and person B is outgoing, ebullient, and talented at marketing and advertising. Now person A spends some years quietly writing some code, which uses a GPL library and is therefore GPL'd, and sells it, as is his/her right under the GPL to person B. If person A really worked for years using a GPL'd library and hoping to make money selling the resulting program (rather than services around that program), he's a complete and total idiot. In any case, making a living by selling a program (as opposed to services around that program) is a difficult business. Except when it's a program written on-demand for a customer who pays you directly to write it (in which case the GPL probably won't get in way, BTW). I can't entirely dismiss GNU/FSF/GPL but it poses a fundamental conflict with the only way I can see of earning a living so it's like a continuous background problem which drains some of my energy and enthusiasm hence the length of my rambling post where I made another attempt to understand my relation to it. Maybe you should thank the FSF for making you doubt: you should really think very hard about how you're going to make a living off of selling a program, even if that program hasn't been anywhere near any GPL'd code. In all likelihood it'll be much easier to earn your money by selling services around your program than just the program itself. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why Not Haskell? (sidenote on licensing)
Sorry, I didn't mean to offend anybody, or be misleading. I like GPL, but I also like the disease metaphor (although is not as much being sneezed at as having sex with somebody :-). Then you should think twice before using such metaphors: you end up propagating hate for something which you like. And it's really not as easy to control as you suggest: If you ever take in a single patch under the GPL, Any patch or outside piece of code you choose to include in your code should be checked to see if its licence allows you to use it like you intend. That's true for any license, not just for the GPL. And don't forget: the default license is no licence at all (i.e. basically just what the copyright's fair use says, which seems to be asymptotically moving towards the empty set as time goes). or even implement a new feature in an obvious way that has been implemented by somebody else under the GPL, you are in trouble. Doesn't sound credible. You're free to write and sell a program whose source code is exactly the same as Emacs's (or PowerPoint for that matter) as long as you can show it was pure accident (or if you like a more classic example url:http://en.wikipedia.org/wiki/Pierre_Menard_(fictional_character)) AFAIK The problem you talk about only comes with patents and is unrelated to copyright/licenses/GPL. Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Why Not Haskell?
Stefan Monnier [EMAIL PROTECTED] writes: I can't entirely dismiss GNU/FSF/GPL but it poses a fundamental conflict with the only way I can see of earning a living so it's like a continuous background problem which drains some of my energy and enthusiasm hence the length of my rambling post where I made another attempt to understand my relation to it. Maybe you should thank the FSF for making you doubt: you should really think very hard about how you're going to make a living off of selling a program, even if that program hasn't been anywhere near any GPL'd code. In all likelihood it'll be much easier to earn your money by selling services around your program than just the program itself. To add to that from the point of view of a potential user: if there some programme that I'm going to rely on and its source is not free, I'll look elsewhere rather than rely on a single vendor that might disappear without a trace and leave me with no support. Conversely, if it has free source, but doesn't quite do what I'm relying on it to do, I'll happily pay someone to sort it out for me (assuming that I can't/don't want to/am to busy to do it myself and that I have any money). I know of several good ideas that started out as attempts at commercial projects but weren't taken up. The best that happened to them is that someone recoded the idea (or it was re-released) as free software. If that didn't happen, they disappeared without trace. Remember, keeping the code secret is no protection against someone rewriting the whole thing from scratch. If it's a big enough idea, you can be sure that some large commercial concern (and conceivably teams of amateurs) will do that unless you've patented something crucial... and keeping patents alive is an expensive business -- especially if there's a large concern on your case (we want to use your patented idea. Oh, it looks like your code uses one of our patented ideas; you'll be hearing from our lawyers). -- Jón Fairbairn [EMAIL PROTECTED] http://www.chaos.org.uk/~jf/Stuff-I-dont-want.html (updated 2006-07-14) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Need a good book on Haskell
I've read Haskell: The Craft of Functional Programming on a course on functional programming at Chalmers (I also took the advanced course) and now I'm looking for some more reading material. Are there any other good Haskell books? Is there a Pick Axe, Camel or Dragon Book for Haskell? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Not Haskell? (sidenote on licensing)
Stefan Monnier [EMAIL PROTECTED] writes: (snip) Doesn't sound credible. You're free to write and sell a program whose source code is exactly the same as Emacs's (or PowerPoint for that matter) as long as you can show it was pure accident (snip) It's kind of hard to be sure that you'll be able to show that, though, especially if the other code was available to you. -- Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need a good book on Haskell
A good follow-up is The Haskell School of Expression by Paul Hudak. Eventually, though, you're going to have to start reading research papers, which is where most of the cutting-edge stuff is. Phil Wadler's papers (available from his web site, just google it) are a good place to start, as are Simon Peyton-Jones' papers. Mike Johan Tibell wrote: I've read Haskell: The Craft of Functional Programming on a course on functional programming at Chalmers (I also took the advanced course) and now I'm looking for some more reading material. Are there any other good Haskell books? Is there a Pick Axe, Camel or Dragon Book for Haskell? ___ 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: Why Not Haskell?
Jón Fairbairn wrote: Stefan Monnier [EMAIL PROTECTED] writes: I can't entirely dismiss GNU/FSF/GPL but it poses a fundamental conflict with the only way I can see of earning a living so it's like a continuous background problem which drains some of my energy and enthusiasm hence the length of my rambling post where I made another attempt to understand my relation to it. Maybe you should thank the FSF for making you doubt: you should really think very hard about how you're going to make a living off of selling a program, even if that program hasn't been anywhere near any GPL'd code. In all likelihood it'll be much easier to earn your money by selling services around your program than just the program itself. To add to that from the point of view of a potential user: if there some programme that I'm going to rely on and its source is not free, I'll look elsewhere rather than rely on a single vendor that might disappear without a trace and leave me with no support. Conversely, if it has free source, but doesn't quite do what I'm relying on it to do, I'll happily pay someone to sort it out for me (assuming that I can't/don't want to/am to busy to do it myself and that I have any money). I know of several good ideas that started out as attempts at commercial projects but weren't taken up. The best that happened to them is that someone recoded the idea (or it was re-released) as free software. If that didn't happen, they disappeared without trace. Remember, keeping the code secret is no protection against someone rewriting the whole thing from scratch. If it's a big enough idea, you can be sure that some large commercial concern (and conceivably teams of amateurs) will do that unless you've patented something crucial... and keeping patents alive is an expensive business -- especially if there's a large concern on your case (we want to use your patented idea. Oh, it looks like your code uses one of our patented ideas; you'll be hearing from our lawyers). Thanks Jón and Stefan for these points. I'm coming round to the idea that possibly a combination of BSD (for libs) and a metamorphosing licence for the program (from proprietary up to a certain date then GPL thereafter) would solve these problems by removing incentives for anyone else to try and reverse engineer code before I'd had time to get an established user base, while keeping users happy (6 months is not that long to wait to get full control), and preventing anyone else getting a similar advantage after the 6 months had elapsed (if they used any of the non-BSD parts of the app (now available to them under GPL) they'd have to release their version as GPL). After the 6 months had elapsed, other companies could develop the code further, but they wouldn't be able to impose a similar metamorphosing license because the code they used (apart from the BSD components of course) would be covered by GPL. However *I* would still have the right to modify my code and repeat the metamorphic process because I wouldn't be bound by the metamorphic GPL license I sold to others (please correct me if I've got this wrong), so people could choose to pay a modest sum to me for the improved version, (which I'd have had a head start of the last 6 months to develop) or wait 6 months to get it from some other company, or spend several months hacking themselves starting from the original version... It gets even better because as long as I make sure that I only use BSD libs + my own code, I could always choose to release future versions with a proprietary license therefore the amortized consequence of the previous metamorphic GPL releases would be risk-free (those versions now being so far behind that they would be irrelevant) yet any other companies which had made improvements (as long as they were based on a version they received + all their own code (or BSD code)) could be a useful source of ideas (to reimplement) or collaboration. Anyway no doubt this is all getting a bit off topic but it's interesting that the different concepts provided by BSD and GPL can suggest possible models like the above. Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The dark side of lazyness - memory leak
I'm facing the dark side of lazyness recently. Typical pattern is like this. My code was working fine and I was happy. I just wanted to inspect some properties of my code so I made a slight chane go the code such as adding counter argument or attaching axulary data filed to original data for tracing how the data has been constructed. All of a sudden the program runs out of memory or overflows the stack. One problem is that it comes up unexptectedly. Another even worse problem is that sometimes I get no idea for the exact loation causing the leak! It really panics facing such darkness of lazy evaluation. Just a small innocent looking fix for inspection or tracing blow things up, sometime with no clue for its reason. When I put a debugging or tracing operating in my software that can be toggled, how could I be sure that turning on those features won't crash my software written in Haskell? Are there appraoches to detect and fix these kind of problem? Haskell may be type safe but not safe at all from unexpteded diversion, not because of the programmers' mistake but just because of the lazyness. I have posted an wiki article including one example of this dark side of lazyness I encountered when I tried to count the number of basic operations in sorting algorithm. This was a rather simple situation and we figured out how to cure this by self equality check ( x==x ) forcing evaluation. There are wose cases not being able to figure out the cure. I wrote a fucntion for analyzing some property of a graph, which worked fine. fixOnBy t p f x = if t x' `p` t x then x else fixOnBy t p f x' where x' = f x fixSize f x = fixOnBy Set.size (==) f x sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [(x,y,cs) | To _ x y cs-Set.toList gs] cgs = [z | z@(x,y,cs)-Set.toList gs', x==y] dcs = [ [c| c@(a,D,b)-Set.toList cs , a==b] | (_,_,cs)-cgs] compose gs = trace (## ++show (Set.size gs)) $ foldr Set.insert gs $ do (x1,y1,cs1) - Set.toList gs (_,y2,cs2) - takeWhileFst y1 $ Set.toList $ setGT (y1,Al(-1),Set.empty) gs return (x1,y2,cs1 `comp` cs2) takeWhileFst y = takeWhile (\(y',_,_) - y==y') This fucntion makes a transitive closure of the given set of relations by fixpoint iteration on the size of the set of weighted edegs. Sample output is like this. *Main main ## 170 ## 400 ## 1167 ## 2249 ## 2314 False When I add an extra data field for tracing how the new item was made (e.g. tag [a,b,c] on a-c if it was generated by a-b and b-c) It suddenly overflows the stack even before printing out the trace. The following is the code that leaks memory. sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [TT (x,y,cs) [] | To _ x y cs-Set.toList gs] cgs = [z | z@(TT (x,y,cs) _)-Set.toList gs', x==y] dcs = [[c| c@(a,D,b)-Set.toList cs , a==b] | TT (_,_,cs) _-cgs] compose gs = trace (## ++show (Set.size gs)) $ foldr checkInsert gs $ do TT (x1,y1,cs1) l1 - Set.toList gs TT (_,y2,cs2) l2 - takeWhileTTfrom y1 . Set.toList $ setGT (TT (y1,Al(-1),Set.empty) []) gs return $ TT (x1,y2,cs1 `comp` cs2) (l1++y1:l2) takeWhileTTfrom y = takeWhile (\(TT (y',_,_) _) - y==y') checkInsert x s | Set.member x s = s | otherwise = Set.insert x s data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) = Eq (TT a b) where (TT x lx) == (TT y ly) = lx==lx ly==ly x == y instance (Ord a, Ord b) = Ord (TT a b) where (TT x lx) (TT y ly) = lx==lx ly==ly x y The really intersting thing happens when I just make the Ord derived the stack does not overflow and starts to print out the trace. (It is not the result that I want though. My intention is to ignore the tags in the set operation) data TT a b = TT a b deriving (Show,Eq,Ord) I believe my Eq and Ord instances are even more stricter than the derived ones. Is there some magic in deriving that prevents memory leak? I've even followed the instance declaration that would be the same as deriving but the that leaks memory. data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) = Eq (TT a b) where (TT x lx) == (TT y ly) = x == y lx == ly instance (Ord a, Ord b) = Ord (TT a b) where (TT x lx) (TT y ly) = x y || x == y lx ly This is really a panic. -- Ahn, Ki Yung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Not Haskell?
On Aug 7, 2006, at 10:00 AM, Stefan Monnier wrote:In any case, making a living by selling a program (as opposed to servicesaround that program) is a difficult business. Making a living writing and selling programs for use by a wide audience is one thing. But there is a lot of money to be made by developers who really understand a complex niche market (assuming the niche is actually populated by customers who need and can pay for the product). And the GPL absolutely gets in the way of that. Because what you're really selling in that kind of market is software as an instantiation of business expertise. Maybe you should thank the FSF for making you doubt: you should really thinkvery hard about how you're going to make a living off of selling a program,even if that program hasn't been anywhere near any GPL'd code. In alllikelihood it'll be much easier to earn your money by selling servicesaround your program than just the program itself.Selling services is much easier if you can tie the services to IP that you own exclusively. It can also double your firm's daily rate on related services. And the economics of selling product (the program) can be MUCH better, assuming people want to use the program. If they don't, then you don't have a service business either.I'm not making (or getting involved in) the moral argument about free or open software. I will point out that the current good health of Haskell owes a great deal to Microsoft through the computer scientists they employ. I'm sure Haskell has benefitted from the largesse of other companies as well. Reilly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Why Not Haskell?
Brian Hulley wrote: Jón Fairbairn wrote: Stefan Monnier [EMAIL PROTECTED] writes: I can't entirely dismiss GNU/FSF/GPL... Maybe you should thank the FSF for making you doubt: I know of several good ideas that started out as attempts at commercial projects but weren't taken up. [...snip] Thanks Jón and Stefan for these points. I'm coming round to the idea that possibly a combination of BSD (for libs) and a metamorphosing licence for the program (from proprietary up to a certain date then GPL thereafter) would solve... Actually I've reconsidered that model and can't recommend it any more so please ignore it or treat it with some caution. (Making the end product open doesn't help (in terms of me making money) if most of the target user base isn't at all interested in hacking, and the cyclic metamorphic model doesn't admit the same advantages of collaboration that a purely open source model would and might just degenerate into a heavily forked mess...) Apologies for posting before I'd considered these implications - I'm out of this thread now (everyone will be very pleased to hear!) Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Variants of a recursive data structure
Klaus Ostermann schrieb: data SimpleExp = Num Int | Add SimpleExp SimpleExp data LabelledExp = LNum Int String | LAdd LabelledExp LabelledExp String I wonder what would be the best way to model this situation without repeating the structure of the AST. How about the following simple parameterization? data Exp label = LNum Int label | LAdd (Exp label) (Exp label) label type SimpleExp = Exp () mkNum i = LNum i () type LabelledExp = Exp String Cheers Christian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] How can we detect and fix memory leak due to lazyness?
Recently, I'm facing the dark side of laziness -- the memory leak because of laziness. Typical pattern that I encounter the problem is like this. My code was working fine and I was happy. I just wanted to inspect some properties of my code so I made a slight chage go the code such as adding counter argument or attaching auxiliary data filed to original data for tracing how the data has been constructed. All of a sudden the program runs out of memory or overflows the stack. One problem is that it comes up unexpectedly. Another even worse problem is that sometimes I get no idea for the exact location causing the leak! It really panics facing such darkness of lazy evaluation. Just a small innocent looking fix for inspection or tracing blow things up, sometime with no clue for its reason. When we implement a debugging or tracing option in the software and let the user toggle those features, how could we be sure that turning on those features won't crash the software written in Haskell? Are there standardized approaches for detecting and fixing these kind of problems? Haskell may be type safe but not safe at all from unexpanded diversion, which is not because of the programmers' mistake but just because of the laziness. I have posted an wiki article including one example of adding a counter to count the number of basic operations in sorting algorithm. http://www.haskell.org/haskellwiki/Physical_equality This was a rather simple situation and we figured out how to cure this by self equality check ( x==x ) forcing evaluation. There are worse cases not being able to figure out the cure. I wrote a function for analyzing some property of a graph, which worked fine. fixOnBy t p f x = if t x' `p` t x then x else fixOnBy t p f x' where x' = f x fixSize f x = fixOnBy Set.size (==) f x sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [(x,y,cs) | To _ x y cs-Set.toList gs] cgs = [z | z@(x,y,cs)-Set.toList gs', x==y] dcs = [ [c| c@(a,D,b)-Set.toList cs , a==b] | (_,_,cs)-cgs] compose gs = trace (## ++show (Set.size gs)) $ foldr Set.insert gs $ do (x1,y1,cs1) - Set.toList gs (_,y2,cs2) - takeWhileFst y1 $ Set.toList $ setGT (y1,Al(-1),Set.empty) gs return (x1,y2,cs1 `comp` cs2) takeWhileFst y = takeWhile (\(y',_,_) - y==y') This function makes a transitive closure of the given set of relations by fixpoint iteration on the size of the set of weighted edges. Sample output is like this. *Main main ## 170 ## 400 ## 1167 ## 2249 ## 2314 False When I add an extra data field for tracing how the new relation was constructed, (e.g. tag [a,b,c] on a-c if it came from a-b and b-c) it suddenly overflows the stack even before printing out the trace. The following is the code that leaks memory. sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [TT (x,y,cs) [] | To _ x y cs-Set.toList gs] cgs = [z | z@(TT (x,y,cs) _)-Set.toList gs', x==y] dcs = [[c| c@(a,D,b)-Set.toList cs , a==b] | TT (_,_,cs) _-cgs] compose gs = trace (## ++show (Set.size gs)) $ foldr checkInsert gs $ do TT (x1,y1,cs1) l1 - Set.toList gs TT (_,y2,cs2) l2 - takeWhileTTfrom y1 . Set.toList $ setGT (TT (y1,Al(-1),Set.empty) []) gs return $ TT (x1,y2,cs1 `comp` cs2) (l1++y1:l2) takeWhileTTfrom y = takeWhile (\(TT (y',_,_) _) - y==y') checkInsert x s | Set.member x s = s | otherwise = Set.insert x s data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) = Eq (TT a b) where (TT x lx) == (TT y ly) = lx==lx ly==ly x == y instance (Ord a, Ord b) = Ord (TT a b) where (TT x lx) (TT y ly) = lx==lx ly==ly x y The really intersting thing happens when I just make the Ord derived the stack does not overflow and starts to print out the trace. (It is not the result that I want though. My intention is to ignore the tags in the set operation) data TT a b = TT a b deriving (Show,Eq,Ord) I believe my Eq and Ord instances defined above are even more stricter than the derived ones. Is there some magic in deriving that prevents memory leak? I've even followed the instance declaration like the following that would be the same as deriving but still leaks memory. data TT a b = TT a b deriving (Show) instance (Eq a, Eq b) = Eq (TT a b) where (TT x lx) == (TT y ly) = x == y lx == ly instance (Ord a, Ord b) = Ord (TT a b) where (TT x lx) (TT y ly) = x y || x == y lx ly This is really a panic. -- Ahn, Ki Yung ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can we detect and fix memory leak due to lazyness?
On 8/7/06, Ahn, Ki Yung [EMAIL PROTECTED] wrote:
I have posted an wiki article including one example of adding
a counter to count the number of basic operations in sorting algorithm.
http://www.haskell.org/haskellwiki/Physical_equality
This was a rather simple situation and we figured out how to
cure this by self equality check ( x==x ) forcing evaluation.
Forcing evaluation using (==) is a bit of a hack. Luckily, we have a
better function to force evaluation: seq (which has type a - b - b).
seq x y evaluates x to weak head normal form before returning
y.
Let's try another feature of Haskell to force evaluation: strict data
fields. A ! in front of a field in a data declaration signifies
strictness. In the example below, whenever we construct a value with
TT, the second argument is evaluated.
\begin{code}
data TT a b = TT a !b
\end{code}
Perhaps your instances will work correctly with this data declaration?
Cheers,
Spencer Janssen
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can we detect and fix memory leak due tolazyness?
Ahn, Ki Yung wrote: Recently, I'm facing the dark side of laziness -- the memory leak because of laziness. The following is the code that leaks memory. sctAnal gs = null cgs || all (not . null) dcs where gs' = fixSize compose $ Set.fromList [TT (x,y,cs) [] | To _ x y cs-Set.toList gs] cgs = [z | z@(TT (x,y,cs) _)-Set.toList gs', x==y] dcs = [[c| c@(a,D,b)-Set.toList cs , a==b] | TT (_,_,cs) _-cgs] compose gs = trace (## ++show (Set.size gs)) $ foldr checkInsert One thing is that (foldr) is not recommended if you can at all avoid it. I think you may be able to use (foldl') here (if you also swap the arg order for checkInsert) which behaves as a strict fold operation so it doesn't waste space building up thunks. gs $ do TT (x1,y1,cs1) l1 - Set.toList gs TT (_,y2,cs2) l2 - takeWhileTTfrom y1 . Set.toList $ setGT (TT (y1,Al(-1),Set.empty) []) gs return $ TT (x1,y2,cs1 `comp` cs2) (l1++y1:l2) takeWhileTTfrom y = takeWhile (\(TT (y',_,_) _) - y==y') checkInsert x s -- checkInsert s x -- if you use foldl' | Set.member x s = s | otherwise = Set.insert x s Sorry I can't help more at the moment - Regards, Brian. -- Logic empowers us and Love gives us purpose. Yet still phantoms restless for eras long past, congealed in the present in unthought forms, strive mightily unseen to destroy us. http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can we detect and fix memory leak due to lazyness?
Perhaps your instances will work correctly with this data declaration? Perhaps it might. But that misses an important point. The biggest impediment to developing large robust applications with Haskell is the opacity of its performance model. Haskell is fantastic in very many ways, but this is a really serious difficulty. I can make a seemingly slight change to my program and the performance changes dramatically. What's worse, the connection between the cause of the blowup and place where it is observed can often be quite subtle[*]. There's a classic example of two one line haskell programs, one of which uses O(1) stack space and the other O(n) stack space, even though they compute the same result, and which are so similar, you have to stare at them for five minutes before you can spot the difference. Hughes' Why functional programming matters argues [rightly] that lazy FP provides a better glue, to allow greater abstraction at the semantic level. The flip side, which IIRC, he doesn't mention is the opacity of the performance model. Here's a question for the experts. What generalizations can I make about the performance of lazy functions under composition? In particular, if all my individual functions are well behaved, will the program as a whole be well behaved? cheers, Tom [*] Gosh, this is beginning to sound like a diatribe on the evils of pointers and manual memory management in C. Interesting ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need a good book on Haskell
Also, we have a large library of research papers here: http://www.haskell.org/haskellwiki/Research_papers mvanier: A good follow-up is The Haskell School of Expression by Paul Hudak. Eventually, though, you're going to have to start reading research papers, which is where most of the cutting-edge stuff is. Phil Wadler's papers (available from his web site, just google it) are a good place to start, as are Simon Peyton-Jones' papers. Mike Johan Tibell wrote: I've read Haskell: The Craft of Functional Programming on a course on functional programming at Chalmers (I also took the advanced course) and now I'm looking for some more reading material. Are there any other good Haskell books? Is there a Pick Axe, Camel or Dragon Book for Haskell? ___ 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] How can we detect and fix memory leak due to lazyness?
On 8/7/06, Spencer Janssen [EMAIL PROTECTED] wrote:
Forcing evaluation using (==) is a bit of a hack. Luckily, we have a
better function to force evaluation: seq (which has type a - b - b).
seq x y evaluates x to weak head normal form before returning
y.
Let's try another feature of Haskell to force evaluation: strict data
fields. A ! in front of a field in a data declaration signifies
strictness. In the example below, whenever we construct a value with
TT, the second argument is evaluated.
\begin{code}
data TT a b = TT a !b
\end{code}
Perhaps your instances will work correctly with this data declaration?
Surely I've tried that.
Unfortunately seq and the strict data declaration is not helpful in general.
They are only helpful on base values such as Int or Bool.
What they do is just making sure that it is not a thunk.
That is if it was a list it would just evaluate to see the cons cell
but no further.
Someone wrote a deepSeq module for forcing deep evaluation, which is
like doing self equality strictness hack like x==x.
However, we should be able to locate what is the source of the memory
leak to apply such strictness tricks.
I've tried plugging in x==x like hack almost everywhere I could but
still hard to find the right hack.
I think this is one of the most frustrating drawbacks developing
software in lazy languages like Haskell.
I am a fan of lazy langnauge; I like laziness and infinite data
structures and clean semantics.
But this is really painful. We have confidence that Haskell programs are robust.
It seems it is too easy to blow up the memory or overflow the stack
without intention.
--
Ahn, Ki Yung
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How can we detect and fix memory leak due to lazyness?
kyagrd:
On 8/7/06, Spencer Janssen [EMAIL PROTECTED] wrote:
Forcing evaluation using (==) is a bit of a hack. Luckily, we have a
better function to force evaluation: seq (which has type a - b - b).
seq x y evaluates x to weak head normal form before returning
y.
Let's try another feature of Haskell to force evaluation: strict data
fields. A ! in front of a field in a data declaration signifies
strictness. In the example below, whenever we construct a value with
TT, the second argument is evaluated.
\begin{code}
data TT a b = TT a !b
\end{code}
Perhaps your instances will work correctly with this data declaration?
Surely I've tried that.
Unfortunately seq and the strict data declaration is not helpful in general.
They are only helpful on base values such as Int or Bool.
What they do is just making sure that it is not a thunk.
That is if it was a list it would just evaluate to see the cons cell
but no further.
Someone wrote a deepSeq module for forcing deep evaluation, which is
like doing self equality strictness hack like x==x.
However, we should be able to locate what is the source of the memory
leak to apply such strictness tricks.
The key is to profile. Compile the code, with optimisations on, with
-prof -auto-all, then run the resulting program with +RTS -p -RTS.
This will identify costly and timely functions.
You can then refine the search further with {-# SCC line1 #-} pragmas,
next to expressoins you want to check the cost of.
-- Don
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re:Re: Why Haskell
hthiel.char: And just from a PR point of view, Haskell does project a cutting edge image. Anyway... Maybe this is our brand! Be on the cutting edge of programming language development -- use Haskell Bored of your language? Try something new. Try Haskell! Same old syntax? Same old bugs? Think different. Think Haskell -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
