Re: [Haskell-cafe] Mystery of an Eq instance
On 2013-09-21, at 4:46 AM, Stijn van Drongelen rhym...@gmail.com wrote: I do have to agree with Damodar Kulkarni that different laws imply different classes. However, this will break **a lot** of existing software. You could argue that the existing software is already broken. If we would do this, only Eq and Ord need to be duplicated, as they cause most of the problems. Qualified imports should suffice to differentiate between the two. import qualified Data.Eq.Approximate as A import qualified Data.Ord.Approximate as A main = print $ 3.16227766016837956 A.== 3.16227766016837955 As soon as you start doing computations with fp numbers things get much worse. Something like Edward Kmett's Numeric.Interval package would likely be helpful, a start at least (and the comments in the Numeric.Interval documentation are amusing) In the distant past when I was worried about maintaining accuracy in a solids modeller we went with an interval arithmetic library that we *carefully* implemented. It worked. Unpleasant in C, but it worked. And this link might be interesting: http://lambda-the-ultimate.org/node/1301 Cheers, Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a bug of 32bit ghc on mac ?
I compiled and ran it a few hundred times in a script with no failures. I've got the same version of GHC on OS X 10.8.3. BTW, it's not just Yesod that has that bug you mentioned in the 64-bit version. Cheers, Bob On 2013-04-30, at 11:37 PM, Sray s...@live.com wrote: hi all it seems i have met some bug on a MAC 32bit GHC version 7.4.2 to make long stroy short, my code is about parse a json file using aeson here is my code http://pastebin.com/0VcVhdvX and here is test data http://pastebin.com/PvtSvst5 and test steps save the code , and name it a.hs (or what you want) save the test data ,name it a.json (do not change its name) $ ghc a.hs -o a $ ./a what i get from the output is fail and when i run the command below for a few times $ runghc a.hs i even got some ok and some fail mixed together but i copy the code and compile it on my linux, everything goes fine, the output is OK i have run uninstall-hs and install a 64bit ghc, also goes fine i delete one line randomly chosen from my test data , got an ok roll back ,delete another line, also an ok... I just want to make sure is this my bug or a bug of ghc p.s. the reason using 32bit ghc is yesod, which has met another bug on 64bit mac ghc :( thanks sray ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type classes, collections, sum types, closures, and a massive headache
Thanks everyone, I very much appreciate your help, and I think it did help. I've spent the last few days implementing a substantial chunk of my system using each of two different techniques. I've ended up going with and ADT containing functions closed over the 'thing'. This seems to be the consensus advice. For the record there was a perfectly viable alternative approach based on existential types (http://www.haskell.org/haskellwiki/Heterogenous_collections#Existential_types, thank Taylor, I'd read that and it didn't register… sigh). From what I could tell from trying them there's not a lot to choose between the two techniques, some small advantages for each. The existential types technique (despite criticism as an anti-patternhttps://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/, thanks Petr) is surprisingly to my taste… what can I say? I ended up going with the ADT because I can shove some additional stuff in it, and since there's still a large exploratory aspect to the project this might matter. Thanks again, Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Type classes, collections, sum types, closures, and a massive headache
for your convenience, the correct link: https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Type classes, collections, sum types, closures, and a massive headache
Hi, I'm relatively new to Haskell, and consider myself to be towards the beginner side of the scale. Nevertheless, I've got this Haskell program I've been working on that's sitting around 11k lines right now. The pattern has been to let it grow to then knock it back by 'refactoring' or whatever you want to call it… doing it right the second time maybe… or the third time. All I want to get across is that though I consider myself a Haskell beginner I've still managed to produce something that is actually quite complex and of reasonable size in about three months. I'm still getting caught by stuff that I should not be caught by. So. Today I thought it was about time to simplify how new 'things' of a certain kind are added to the system. These things are some a cross between an event and an assertion of a fact in a rule based system. There are many different kinds of these things. I already have more than a dozen commonplace ones, and I expect there's a much larger number of more specialized ones that a user will want to add on their own. While they start out quite differently, they end up satisfying a common interface and follow the identical three or four state lifecycle. This sounded like a type class to me, and in fact, easily implemented as such. Now, this is how I got caught: it seems to be impossible to have collections of things with a common type class if they have different types. How is it that I've written that many lines of code in Haskell and I'm just noticing this now? (If I wasn't so annoyed, I'd look for something clever to reflect how loc count obviously doesn't mean much… but clever seems to be beyond me today). Is this true? Are there any GHC extensions that will let me around this? The immediate problem is mapping an input to the system, some json message containing a reference to the 'thing' (like a key of some kind). I have to take that reference and find the thing and operate on it. All operations are easily accommodated by a type class. However, since I can't have a collection with mixed types even if the types satisfy a type class, I can't quite see how to actually store the things so I can find them. So there are a couple of obvious ways to handle this. I could use an ADT and a sum type of all the known kinds of thing, but I already know that this has to be extended and that's going to be problematic with users doing this on their own. And the type signatures look ugly. So I think that's not the best. I could use an ADT that contains functions that correspond to the functions of the type class, and that close over the 'thing' in question. I think this could be made to work, but I'm concerned with walking into more nasty surprises… If anyone is able to make sense of what I wrote and has any suggestions I'd really appreciate hearing them. Thanks, Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Haskell and Pandoc Let's Code-Style Video
Hi Chris, Thanks for that video, I'm looking forward to any more that you might do. Seeing your workflow is a very important aspect to your video, especially for newcomers trying to learn Haskell on their own. A brief overview of your tooling would be nice. Unfortunately, I shaved a yak very well, possibly more than once, while improving my PS1 prompt. Starting with duplicating your $? display but not stopping there… oh no, couldn't stop at just that :-) Cheers, Bob On 2013-01-07, at 6:50 PM, Chris Forno je...@jekor.com wrote: I've just uploaded a video walking through some of the source code for Pandoc. I plan to create more videos like it (on Pandoc and other open source/free software projects), and I'd appreciate your feedback. https://www.youtube.com/watch? v=FEFETKhhq8wfeature=youtube_gdata_play er I think Haskell is particularly well-suited for this type of study: - The code tends to be concise, and parts can usually be analyzed in isolation thanks to explicit state. - Even after 10 years of exposure to Haskell I feel like I still have much to learn about idiomatic style from the writings of others. - I've run across the same misconceptions about Haskell in the professional world (and had some myself in the beginning), and would like more people to see what Haskell really is like outside of papers and blog posts. Please let me know if there are other projects you'd like to see me cover. Thanks. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-02, at 4:41 AM, MigMit miguelim...@yandex.ru wrote: On Jan 2, 2013, at 2:26 AM, Bob Hutchison hutch-li...@recursive.ca wrote: On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote: Well, probably one of the reasons is that I've learned Eiffel later than Haskell. But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not the same thing. Well, we were talking about Eiffel. OOSC2 deserves a few unkind words as well, but I won't go there. And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory. I don't know about DbC in general, but it's implementation in Eiffel seems to be nothing more than a few ASSERT macros, for some weird reason embedded into the language. Hmm. I must disagree with you here. I've used three Eiffel systems, ISE, Small/SmartEiffel, and Tower. They all implemented DbC pretty thoroughly. In my opinion, every other implementation of DbC pale in comparison, to the point where they're hardly DbC at all. Are we talking about the same thing? There are three major components (in my opinion) to DbC: pre and post conditions, and class invariants. Pre and post conditions and invariants cannot be implemented simply as asserts. I'll have to refer you to OOSC2 for the (many) details, but a few of the more interesting aspects of these constructs are: 1) error reporting. If a precondition is violated the caller is flagged as the source of the error and error messages, stack traces, etc all reflect the caller. If a post condition is violated it's the callee who is responsible. And the error reports generated are rather good. 2) prepost conditions and class invariants have defined behaviour in cases of inheritance, even/especially multiple inheritance. They are combined non-trivially in subclasses. Without this I don't think you have DbC. 3) invariants are not checked for calls within a class (self.method does not have them checked, other.method does) 4) You have access to all the parameters for prepost conditions, and results for post conditions. Access to the initial state of the object is supposed to be there but I don't think all implementations support that. That's only a brief summary, it goes further than that, again I refer you to OOSC2 (and any of the Eiffel implementations I mentioned, and I don't know of any other implementations). This is nothing like a few assert macros. So, I think, you're saying take away the contracts and the outcome of compilation won't be any different. Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but types not a 'hack'? I wasn't clear enough, sorry. I'm sure it's due to sleep deprivation. Or coffee deprivation. See, there are two parts of Eiffel, as I see it. First one is the contracts part. Second is… well, everything else. Second part seems to be doing all the real job, while the first one is doing something invisible, something that leaves no trace in the final result. Which doesn't mean it's unimportant, of course. The contracts part is designed to help the other part do it's job, but not to do the job by itself. Now, there are two problems with that: 1) The real job part needs helping. And a lot of it, actually, one doesn't need to look very closely to see that Eiffel type system is extremely unsafe (for the statically type language). Feel free to enlighten me about these obvious and extremely unsafe aspects of Eiffel's type system. Personally, I can't say I ever noticed. 2) The contracts part does a very poor job. Instead of really improving the inherent unsafety, it resorts to testing. And… What constitutes a 'good' job? 'Resorts' to testing. I have to admit to resorting to testing on occasion myself. Frequent occasion. Routinely even. :-) 2') ...not even the real, thorough testing — contracts system would be quite happy if the program works on the developer's machine. Which is the works for me approach certain languages gets rightfully blamed for. Really? You believe that automated testing and contracts are why software bugs *are not* found? Seems to me you're ignoring everything that happens between an empty directory and a working program. Contracts help in that process (I say but can't prove). I agree. They do help — but there are lots of things that help in this transition. Versioning systems. Collaboration tools. Bug tracking software. Text editors. Even debuggers. You should read OOSC2. You'll find that this is completely consistent with it. Don't forget that the 'C' in OOSC2 is 'contraction'. Cheers, Bob Pre and post
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-02, at 7:56 AM, Bob Hutchison hutch-li...@recursive.ca wrote: You should read OOSC2. You'll find that this is completely consistent with it. Don't forget that the 'C' in OOSC2 is 'contraction'. 'Construction' of course… the automated spell checker is not my friend :-( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-02, at 1:52 AM, Mike Meyer m...@mired.org wrote: [Context destroyed by top posting.] MigMit miguelim...@yandex.ru wrote: But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. You just stated (briefly, and not very rigorously) the theory: DbC is a useful approach to programing. Note that it's a theory about *programming*, not the resulting program. And by hack I meant not the presence of pre/postconditions, but the fact that they don't affect anything else. Strip all of them away, and you'll have the program which is, essentially, the same (and, in fact, pre/postconditions are supposed to be removed in the final version of the program). Compare this to Haskell types, for example: an untyped version of Haskell won't be able to choose between two class instances, so, that would be an entirely different language. Type classes are the wrong feature to look at. Type signatures are closer to what DbC is. Are type signatures a hack to get around deficiencies in the type inferencing engine? After all, you can strip all of them away and have essentially the same program. Eiffel programmers certainly consider the prepost conditions and invariants to be part of the signature. DbC is closely related to the management of state, and so to the object as a whole not just the parameters to a method. Now, I'm no expert in Haskell so treat the next part of this paragraph accordingly... putting invariants and conditions on monads, in particular to the entry and exit from do notation might be interesting. No particular ideas as to how you'd do that, or even if it'd be useful, but it seems to me to be a bit closer to the level of abstraction where DbC is at in Eiffel. Personally, I think the answer is no, and for the same reason. We add type signatures to top level functions because it helps document the function, and to help isolate type errors during compilation. They makes *programming* easier, even if they don't change the program at all. Pre and Post conditions (and class invariants - they're also part of DbC!) serve pretty much the same function. They help document the classes and methods, and tools that generate class/method documentation from source always include them. They're as important as the type signature. They also help isolate bugs, in that you get told explicitly that routine foo passed in an invalid parameter to bar rather than an exception somewhere deep in the guts of bar that you have to work back from to find foo. As I said before, I'm not sure I agree that the latter is worth the cost of using them for anything complex. The bugs they uncover are as likely to be in the pre/post conditions as in the code proper. The documentation benefit is unquestionable, though. And if some condition is worth documenting, then having it as executable documentation means it gets tested with the rest of the code, so you know the documentation is correct. Which means that just adding conditions to a language misses most of the benefit of DbC. You need to fix the documentation system as well. I can only speak from personal experience here. I used Eiffel as my primary programming language in the 1990's for about 10 years. I wrote a lot of code in Eiffel, and I used prepost conditions and class invariants extensively (and loop invariants surprisingly often). Some of that code would certainly be described as 'complex'. Yes, documentation is a huge part of what DbC gives you, but a peculiarly aggressive kind of documentation that tells you when you're doing it wrong. The biggest problem I had with writing prepost conditions and class invariants was missing part of what should be specified and so letting things pass that shouldn't have. The next biggest problem was being overly specific (I sometimes do the same thing with type signatures in Haskell I'm afraid). Bugs in the code of the conditions and invariants was not much of a problem I found (I can't recall any). It does take a while to learn how to write the conditions and how to accommodate DbC concepts when you write a class or class hierarchy. And, occasionally, the balancing act between DbC and unit tests is tricky. This is the kind of theory that you'll find in OOSC: why the features that are there help make programming easier. Not theories about how they make the resulting program better. Those two have a lot in common, though. Anything that makes witing correct code easier generally results in a better program. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2012-12-31, at 4:26 PM, Rico Moorman rico.moor...@gmail.com wrote: Hello Bob and Mike, Reading a little within the suggested book I came across the following statement. We should first examine the merits and limitations of the traditional approach: using functions as a basis for the architecture of software systems. This will not only lead us to appreciate why we need something else — object technology — but also help us avoid, when we do move into the object world, certain methodological pitfalls such as premature operation ordering, which have been known to fool even experienced O-O developers. Because you both have more experience with this piece of literature, how would you interpret it? With a grain of salt or would function really mean procedure from the viewpoint of the author? He is talking about functions/procedures as in C, Pascal, Algol… structured programming basically. The first edition was written in 1988, the second about 10 years later. However, today, I *think* he might include functions as found in modern functional languages in this, and as you read on in the book you'll see why I say this. I've been considering re-reading OOSC2 for a while now (it is, believe it or not, a fun book… well, maybe that's just me) and keep Haskell and ML in mind while reading it. Meyer is trying to thoroughly explain the reasoning behind OO in this book, it isn't really a critique of anything especially (except indirectly other OO languages). Meyer can be scathing but you'll have to look elsewhere for the best/worst/most fun of that. Haskell, as it matures, is going to have to have an answer for everything in this book (answers may include 'pass' as Meyer does with Eiffel on a few issues–there's no shame in admitting Haskell, or anything else, doesn't have all the answers)… he's talking about issues that are independent of programming language. Cheers, Bob Thank you very much in advance. Best regards, Rico Moorman On Mon, Dec 31, 2012 at 6:13 PM, Bob Hutchison hutch-li...@recursive.ca wrote: On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life. So my questions for you all are: * Is it really worthwhile for me to learn OO-programming? Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big. As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages. I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice. C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn KR C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-) Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes. * If so, where should I start? There are plenty of functional programming for OO programmers but I have never seen OO programming for functional programmers. * Is it true that learning other programming languages leads to a better use of your favorite programming language? That's been my experience. And it'll be harder to name your favourite language too. * Will I learn new programming strategies that I can use back in the Haskell world? Probably. Cheers
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
On 2013-01-01, at 3:47 PM, MigMit miguelim...@yandex.ru wrote: Well, probably one of the reasons is that I've learned Eiffel later than Haskell. But really, Design by Contract — a theory? It certainly is a useful approach, but it doesn't seem to be a theory, not until we can actually prove something about it, and Eiffel doesn't seem to offer anything in this direction. Don't confuse OOSC2 and Eiffel. Eiffel implements the ideas in OOSC2 as best as Meyer can, but they are not the same thing. And, personally, I think I would be willing to call DbC a theory, or a close precursor to a theory. And by hack I meant not the presence of pre/postconditions, but the fact that they don't affect anything else. Strip all of them away, and you'll have the program which is, essentially, the same (and, in fact, pre/postconditions are supposed to be removed in the final version of the program). Compare this to Haskell types, for example: an untyped version of Haskell won't be able to choose between two class instances, so, that would be an entirely different language. So, I think, you're saying take away the contracts and the outcome of compilation won't be any different. Whereas take away the types and Haskell is stopped cold. And that difference makes contracts a 'hack' but types not a 'hack'? Seems to me you're ignoring everything that happens between an empty directory and a working program. Contracts help in that process (I say but can't prove). Call that a 'hack' if you want, but I'll take as many of those kinds of hacks as I can get if they're anywhere near as good as contracts. Pre and post conditions with class invariants are neither types nor unit test, something in between. With the wonderful properties of 'useful' and 'executable'. Sometimes you just have to settle for the hacks. Cheers, Bob On Jan 1, 2013, at 11:41 PM, Mike Meyer m...@mired.org wrote: MigMit miguelim...@yandex.ru wrote: On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ru wrote: Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. Really? Because when I studied it I had a very different impression: that behind this language there was no theory at all. And it's only feature I remember that is not present in mainstream languages is it's pre/postconditions system, which looked like an ugly hack for me. I agree with Leon. Of course, I learned it out of OOSC2, which provides the theory. When compared to mainstream OO languages like C++, Java or Python, it's on a much solider theoretical basis. Compared to something like Scheme, Haskell or even Clojure, maybe not so much. On the other hand, one persons theory is another persons hack. The theory behind the pre/post conditions is Design by Contract. The contracts are as important as the type signature, and show up in the auto-generated docs in eiffel systems. I found at least one attempt to add DbC features to Haskell. I'm not sold on it as a programming technique - the bugs it uncovers are as likely to be in the pre/post conditions as in the code. -- Sent from my Android tablet with K-9 Mail. Please excuse my swyping. ___ 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] Object Oriented programming for Functional Programmers
On 2012-12-30, at 2:58 PM, Daniel Díaz Casanueva dhelta.d...@gmail.com wrote: Well, my curiosity is bringing me to learn a new general purpose programming language. Haskellers are frequently comparing Object-Oriented languages with Haskell itself, but I have never programmed in any OO-language! (perhaps this is an uncommon case) I thought it could be good to me (as a programmer) to learn C/C++. Many interesting courses (most of them) use these languages and I feel like limited for being a Haskell programmer. It looks like I have to learn imperative programming (with side effects all over around) in some point of my programming life. So my questions for you all are: * Is it really worthwhile for me to learn OO-programming? Yes. And you should learn OO *very* well. And remember, OO doesn't really get interesting until the program gets big. As for languages I'd suggest Smalltalk or Eiffel, perhaps both. The big advantage to Eiffel is that you have Object Oriented Software Construction (second edition (not first)) to work from. Every OO language has to answer to the issues brought up in OOSC2 (and they don't/can't). Eiffel's inheritance mechanism is also one of the few that let you use inheritance to do useful things (OOSC2 names 16 or 18 different uses for inheritance… it's not just for 'is-a' relationships). Eiffel also has a contract system that's powerful enough to be useful. Smalltalk's advantage is that it will also introduce you to the idea of a programming 'system', for lack of better words. Smalltalk works in a live system, as you are writing code you are modifying live and already executing code. Once you realize that the 'best' editor in Smalltalk is the debugger (and what 'a good debugger' actually means) you'll understand test-driven-development's origins. This is very different from Haskell. Actually, you should probably learn both languages. I don't think C++ will help you learn OO, or much of anything else either. Vigorously avoid is my advice. C you're probably going to have to learn sooner or later but wait until you have to. And it's not OO at all. Though, if you learn KR C (pre-ansi C) you'll get a better understanding of why people liked OO so much :-) Ruby might be an easy route to OO too. I like the language quite a lot, but I'm not sure I'd recommend it for your purposes. * If so, where should I start? There are plenty of functional programming for OO programmers but I have never seen OO programming for functional programmers. * Is it true that learning other programming languages leads to a better use of your favorite programming language? That's been my experience. And it'll be harder to name your favourite language too. * Will I learn new programming strategies that I can use back in the Haskell world? Probably. Cheers, Bob Thanks in advance for your kind responses, Daniel Díaz. ___ 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] JavaScript (SpiderMonkey, V8, etc) embedded in GHC?
On 2012-11-10, at 2:39 PM, Simon Hengel s...@typeful.net wrote: Hi, I've looked around with no success… this surprises me actually. Has anyone embedded SpiderMonkey, V8, or any other relatively decent JavaScript interpreters in GHC (using the FFI)? I just started something [1]. Cheers, Simon [1] https://github.com/sol/v8 Nice! Thanks! I'll have a go with it today or tomorrow. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 64-bit vs 32-bit haskell platform on Mac: misleading notice on Platform website?
On 2012-09-26, at 1:44 AM, Carter Schonwald carter.schonw...@gmail.com wrote: what can we (the community ) do to address the fact that the haskell platform installer suggestions for os x are sadly completely backwards? (or am I completely wrong in my personal stance on this matter) I'd much prefer the 64 bit myself, unfortunately http://hackage.haskell.org/trac/ghc/ticket/7040 affects the current version of the Haskell Platform. It's fixed in 7.6.x. This bug prevents me from using Yesod with the 64 bit version of 7.4.2, and it's not just Yesod affected… Cheers, Bob___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] JavaScript (SpiderMonkey, V8, etc) embedded in GHC?
Thanks Greg, interesting thought. It would work the other way around, but it'd be easy enough to set up a node server to run the javascript. There's no IO allowed or any other blocking operations so I can make this all automatic. Still, that's another moving part I'd just as soon not have. Strange there's no JavaScript embedding in GHC, or there doesn't seem to be. Cheers, Bob On 2012-09-09, at 6:24 PM, Greg Fitzgerald gari...@gmail.com wrote: Hi Bob, All I really need is to allow users to write some JavaScript that accepts a single JSON 'file/string' from my Haskell program and produces another JSON 'file/string' that my Haskell program will accept. One option is to make your Haskell program an HTTP server, and then use Node.js to send and receive JSON files. http://www.happstack.com/docs/happstack-lite-7.2.0/doc/html/happstack-lite/index.html http://nodejs.org/ -Greg On Sat, Sep 8, 2012 at 12:08 PM, Bob Hutchison hutch-li...@recursive.ca wrote: Hi, I've looked around with no success… this surprises me actually. Has anyone embedded SpiderMonkey, V8, or any other relatively decent JavaScript interpreters in GHC (using the FFI)? I did find http://justinethier.github.com/husk-scheme/ which is a scheme R5RS implementation (I could make this work). There's also some work done embedding Lua. I also found a number of packages that compile javascript to Haskell, or the other way around, but I don't need that kind of thing. All I really need is to allow users to write some JavaScript that accepts a single JSON 'file/string' from my Haskell program and produces another JSON 'file/string' that my Haskell program will accept. Thanks, Bob ___ 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] JavaScript (SpiderMonkey, V8, etc) embedded in GHC?
Hi, I've looked around with no success… this surprises me actually. Has anyone embedded SpiderMonkey, V8, or any other relatively decent JavaScript interpreters in GHC (using the FFI)? I did find http://justinethier.github.com/husk-scheme/ which is a scheme R5RS implementation (I could make this work). There's also some work done embedding Lua. I also found a number of packages that compile javascript to Haskell, or the other way around, but I don't need that kind of thing. All I really need is to allow users to write some JavaScript that accepts a single JSON 'file/string' from my Haskell program and produces another JSON 'file/string' that my Haskell program will accept. Thanks, Bob ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC licence
On Wed, 22 Jul 1998 08:51:47 GMT, you wrote: CC: Simon L Peyton Jones [EMAIL PROTECTED] I do think that the GNU license would be a mistake -- as I understand, it would prevent the use of GHC in commercial projects, and I'm pretty sure that's something Simon wants to *encourage*. There are *two* GNU licenses. The GPL is meant for tools, like GHC, and would prevent certain uses of GHC. There is a second GNU license for libraries, called LGPL, and this is important. The runtime components of GHC should be licensed using the library license (just like the GNU runtimes are). Using both licenses appropriately would allow for the use of GHC in commercial software (as long as GHC itself was not included). Any improvements GHC or its runtime would still have to be made public by the commercial entity. For example, Tower Eiffel has use GNU compilers for some time. The runtime libraries of GNU compilers are protected by the library license. Yet Tower Eiffel is certainly used for commercial products. Cheers, Bob --- Bob Hutchison, [EMAIL PROTECTED], (416) 760-0565 ([EMAIL PROTECTED] until INTERNIC fixes problems) RedRock, Toronto, Canada
