Re: [Haskell-cafe] [Haskell-beginners] ghc and android
Nathan, David is right. Using the x86 Android image in a VM could be fast enough (if you computer has virtualization support) I haven't tried to compile GHC for android myself. At the present time, and taking into account that it would probably be slow to execute and lack all the interesting libraries that I would like to use, other FP languages may be better choices. Please, let us know if you manage to compile it. Cheers, Ivan On 31 December 2012 19:04, David Thomas davidleotho...@gmail.com wrote: Couldn't that simply be simulated? On Mon, Dec 31, 2012 at 2:36 PM, Nathan Hüsken nathan.hues...@posteo.de wrote: That seems almost impossible, I would need an android device with unusual capacity. ___ 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] Backtracking in HXT
Ah, zeroArrow looks exactly like what I need here!
Thanks, this helps.
Mateusz Kowalczyk
On 01/01/13 01:08, dag.odenh...@gmail.com wrote:
( is my GHCi prompt, might be a bit confusing for an arrow example.)
On Tue, Jan 1, 2013 at 2:05 AM, dag.odenh...@gmail.com
mailto:dag.odenh...@gmail.com dag.odenh...@gmail.com
mailto:dag.odenh...@gmail.com wrote:
Use arrow notation and zeroArrow, like so:
{-# LANGUAGE Arrows #-}
import Text.XML.HXT.Core
getA =
hasName a proc elem - do
text - getText getChildren - elem
if text == Hello Two!
then getAttrValue href - elem
else zeroArrow - ()
runX $ readString [] htmla
href='example.com/somelink.html
http://example.com/somelink.html'Hello One!/aa
href='example.com/anotherlink.html
http://example.com/anotherlink.html'Hello Two!/a/html
deep getA
[example.com/anotherlink.html http://example.com/anotherlink.html]
On Mon, Dec 31, 2012 at 3:36 PM, Mateusz Kowalczyk
fuuze...@fuuzetsu.co.uk mailto:fuuze...@fuuzetsu.co.uk wrote:
Hello,
I'm not sure if this is the right place to ask this but here goes.
I'm currently working with HXT and I quite like it. There's
one issue I
can't solve (at least now without some dirty, dirty hacking)
and I'm
sure it's fairly simple.
Consider the following mark-up
a href=example.com/somelink.html
http://example.com/somelink.htmlHello One!/a
a href=example.com/anotherlink.html
http://example.com/anotherlink.htmlHello Two!/a
Now, what I'm trying to achieve is to get the href based on
the text. I
can test for what the text is by traversing as, then using the
getChildren getText arrow. What I can't figure out is how
to check
the text and then get the href as by the time I get to the
text, I'll
further down the tree!
I imagine it would look something along the lines of
(getChildren getText ?* Hello Two) `guards` getAttrValue
href. ?* is just a random operator I made up for illustration
purposes that works as a predicate over arrows.
Is this the right approach? Is there a built-in that already
does what I want? It
seems like a common task...
Mateusz Kowalczyk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org mailto: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] [Haskell-beginners] ghc and android
On Tue, Jan 1, 2013 at 1:13 PM, Ivan Perez ivanperezdoming...@gmail.com wrote: Please, let us know if you manage to compile it. There are some comments regarding porting git-annex to android, in order to make it useable from shell (that is, not as android app). http://git-annex.branchable.com/design/assistant/android/ The main issue: The GHC runtime relies on glibc, which is not used on android. Also, glibc cannot be (fully) linked statically. Probably someone with more knowledge about GHC internals and glibc can came up with a clean solution to this problem. An additional issue: ghci (and Template Haskell because it uses the bytecode interpreter of ghci internally) currently(?) requires its own custom linker instead of being able to use the system linker. Said linker has no support for ARM. The correct fix for this is to redesign ghci so it doesn't need its own linker; there has been some work in this direction, but I don't know how complete it is, and it interacts with other issues such as building Haskell libraries as shared objects. http://www.haskell.org/pipermail/glasgow-haskell-users/2012-December/023163.html I don't know the situation on ARM though. I added ghc-users mailinglist to CC. Regards, Bernhard ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell-beginners] ghc and android
On Tue, Jan 1, 2013 at 9:13 AM, Bernhard Urban lew...@gmail.com wrote: The main issue: The GHC runtime relies on glibc I have to assume this is not meant literally, because ghc works on OS X and *BSD. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mancunian Haskellers out there?
Hi Alfredo, I live in Leeds, which is not far from Manchester. I'd be up for a user group nearby, so will +1 your user group :) Cheers, On 30 December 2012 15:15, Alfredo Di Napoli alfredo.dinap...@gmail.comwrote: Hey, thanks for the response :) Mine was more a small survey to see if we are enough to think about creating a small user group and see each other once a month or whenever :) Cheers, A. On 30 December 2012 15:58, Mateusz Kowalczyk fuuze...@fuuzetsu.co.ukwrote: Greetings, I'm currently residing in Bury, a metrolink ride away from Manchester. Unfortunately, I'm only here for Christmas holidays and am leaving tomorrow so a meeting is unlikely. I don't think that I'd be a good conversation partner anyway as my knowledge is still quite limited. I'd love to hear whether you find any other people though. It would be nice if some Haskell talks could be held in the area if there are enough people. Good luck on your search, Mateusz Kowalczyk On 30/12/12 14:38, Alfredo Di Napoli wrote: Morning Cafe, I've been living in Manchester for 1 month now and I'm wondering if some on you are from the Greater Manchester area, so that we could chat about out beloved language in front of a glass of ale / tea :P Happy new year to everyone! A. ___ Haskell-Cafe mailing listHaskell-Cafe@haskell.orghttp://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] 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] Mancunian Haskellers out there?
I'm in York and would love to meet up Arthur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mancunian Haskellers out there?
On 01/01/2013 16:19, Blake Rain wrote: Hi Alfredo, I live in Leeds, which is not far from Manchester. I'd be up for a user group nearby, so will +1 your user group :) Similarly for me - I'm Leeds based and would be interested in joining in. Please sign me up! Cheers, David T Cheers, On 30 December 2012 15:15, Alfredo Di Napoli alfredo.dinap...@gmail.com mailto:alfredo.dinap...@gmail.com wrote: Hey, thanks for the response :) Mine was more a small survey to see if we are enough to think about creating a small user group and see each other once a month or whenever :) Cheers, A. On 30 December 2012 15:58, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk mailto:fuuze...@fuuzetsu.co.uk wrote: Greetings, I'm currently residing in Bury, a metrolink ride away from Manchester. Unfortunately, I'm only here for Christmas holidays and am leaving tomorrow so a meeting is unlikely. I don't think that I'd be a good conversation partner anyway as my knowledge is still quite limited. I'd love to hear whether you find any other people though. It would be nice if some Haskell talks could be held in the area if there are enough people. Good luck on your search, Mateusz Kowalczyk On 30/12/12 14:38, Alfredo Di Napoli wrote: Morning Cafe, I've been living in Manchester for 1 month now and I'm wondering if some on you are from the Greater Manchester area, so that we could chat about out beloved language in front of a glass of ale / tea :P Happy new year to everyone! A. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto: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 -- David Turner Senior Consultant Tracsis PLC Tracsis PLC is a company registered in England and Wales with number 5019106. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Mancunian Haskellers out there?
Wow guys, that's a great news! I have no experience with User Groups or sites like Meetup (the only think I know is that a small contribution fee is required to create a Meetup), do you have any? Basically I think the trickiest part would be to find a place to keep the meetings: I could ask to my employer, but it's unlikely it would gives us permission to use company's premises outside working hours. Any idea? Happy new year! A. On 1 January 2013 18:55, David Turner d.tur...@tracsis.com wrote: On 01/01/2013 16:19, Blake Rain wrote: Hi Alfredo, I live in Leeds, which is not far from Manchester. I'd be up for a user group nearby, so will +1 your user group :) Similarly for me - I'm Leeds based and would be interested in joining in. Please sign me up! Cheers, David T Cheers, On 30 December 2012 15:15, Alfredo Di Napoli alfredo.dinap...@gmail.com mailto:alfredo.dinapoli@**gmail.com alfredo.dinap...@gmail.com wrote: Hey, thanks for the response :) Mine was more a small survey to see if we are enough to think about creating a small user group and see each other once a month or whenever :) Cheers, A. On 30 December 2012 15:58, Mateusz Kowalczyk fuuze...@fuuzetsu.co.uk mailto:fuuze...@fuuzetsu.co.**ukfuuze...@fuuzetsu.co.uk wrote: Greetings, I'm currently residing in Bury, a metrolink ride away from Manchester. Unfortunately, I'm only here for Christmas holidays and am leaving tomorrow so a meeting is unlikely. I don't think that I'd be a good conversation partner anyway as my knowledge is still quite limited. I'd love to hear whether you find any other people though. It would be nice if some Haskell talks could be held in the area if there are enough people. Good luck on your search, Mateusz Kowalczyk On 30/12/12 14:38, Alfredo Di Napoli wrote: Morning Cafe, I've been living in Manchester for 1 month now and I'm wondering if some on you are from the Greater Manchester area, so that we could chat about out beloved language in front of a glass of ale / tea :P Happy new year to everyone! A. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.**orgHaskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org mailto:Haskell-Cafe@haskell.**orgHaskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://www.haskell.org/mailman/listinfo/haskell-cafe -- David Turner Senior Consultant Tracsis PLC Tracsis PLC is a company registered in England and Wales with number 5019106. __**_ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/**mailman/listinfo/haskell-cafehttp://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
Eiffel, for my opinion, is a best OOP language. Meyer use a theoretical approach as it is possible in OOP. 01.01.2013, 23:56, "Bob Hutchison" hutch-li...@recursive.ca: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: usingfunctions as a basis for the architecture of software systems. This will not only lead us toappreciate 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 prematureoperation 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 MoormanOn 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,BobThanks in advance
Re: [Haskell-cafe] lambda case (was Re: A big hurray for lambda-case (and all the other good stuff))
Hi, Brandon Allbery wrote: [...] syntax extension [...] I think someone's already working on this (SugarHaskell?). Yes, we are working on it. See our paper [1] and Sebastian's talk [2] at the Haskell Symposium. Our current prototype can be installed as an Eclipse plugin [3] or as a command-line tool [4]. [1] http://sugarj.org/sugarhaskell.pdf [2] http://www.youtube.com/watch?v=Kjm7bOLnuy0 [3] http://update.sugarj.org/ [4] http://hackage.haskell.org/package/sugarhaskell One use case we have in mind for SugarHaskell is prototyping of language extensions like the one discussed in this thread. Tillmann ___ 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
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
Re: [Haskell-cafe] Object Oriented programming for Functional Programmers
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. 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. 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
Re: [Haskell-cafe] [Haskell] ANNOUNCE: graphviz-2999.15.0.0
On 1 January 2013 22:41, Henning Thielemann lemm...@henning-thielemann.de wrote: On Tue, 1 Jan 2013, Ivan Lazar Miljenovic wrote: After much prodding and poking by end-users for the past few months, I'm finally able to announce a GHC-7.6.1 compatible release of my Haskell bindings to the Graphviz graph visualisation toolkit: http://hackage.haskell.org/package/graphviz-2999.15.0.0 Did you receive my work-around for the busy-wait problem? Whoops, forgot about that; I'll have a look now. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] 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
[Haskell-cafe] Haskell Summers of Code retrospective (updated for 2012)
The Wheel turns, and months come and pass, leaving web links that fade into 403 Forbiddens; a wind rose in NYC, whispering of the coming Winter... As is now customary for me, I've looked into how the 2012 SoCs went - the better to feed my misanthropic heart by mocking the students who failed my whimsically arbitrary and subjective standards: http://www.gwern.net/Haskell%20Summer%20of%20Code#results-2 This was not a good year. 2 students simply dropped out period, and 3 other projects turned out badly, leaving just 2 clearly successful projects for the year. Hopefully 2013 will turn out better. /r/haskell: http://www.reddit.com/r/haskell/comments/15sjur/summer_of_code_2012_retrospective/ -- gwern ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Proving programs
I'm working through a video lecture describing how to prove programs correct, by first translating the program into a control flow representation and then using propositional logic. In the control flow section, the speaker described how the program should be understood in terms of an input vector (X, the inputs to the program), a program vector (Y, the storage variables), and an output vector (Z, the outputs of the program), with X mapping into Y, Y being affected by execution, and X and Y mapping into Z. However, only part way into the video, two practical questions come to mind: 1. Does this approach need to be adjusted for a functional language, in which computation is (at least idealistically) distinct from control flow? 2. How do we approach this for programs that have an input loop (or recursion)? E.g., I have an application that reads one line for stdin, modifies said line, outputs to stdout, and repeats this process until EOF? Should I be thinking of every iteration as a separate program? -- frigidcode.com signature.asc Description: OpenPGP digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hsc2hs and Storable (especially) unsafe
It so happens that on 64 bit OS X, haskell's Int is 64 bits, while C's int is 32 bits. hsc2hs's #poke does no typechecking at all, so if you have (#poke Struct, int_field) structp int -- where int :: Int Then you probably are going to corrupt memory, and in a particularly pernicious way (since chances are it won't segfault). Similarly, don't poke haskell Chars, it has to be CChar. And what's even worse, Foreign.withArrayLen gives you an Int, not a CInt! So doing the obvious thing and poking the pointer and length directly is wrong. And besides, shouldn't it be a CSize? Another trap: C++'s bool is probably one byte, haskell's Bool Storable says it's 4. It's probably not even correct to assume Double = CDouble and Float = CFloat, though it seems likely to be always true. I carefully vetted all my #pokes but I'm annoyed that hsc2hs and Foreign let me get away with this. If Storable is for marshalling types to and from C, then non-C types should not be Storable! If Storable is useful for other things (and it is!), then Foreign should define its own CStorable, that only includes C types, and hsc2hs should use that! While we're at it, fromIntegral is not a safe way to convert a haskell type to a C one. But it sure is a tempting one, because Foreign.C doesn't provide any conversion functions (except for Bool). We should have explicit conversion functions that give the choice of crashing with an error or clamping the number to the (smaller) C type's bounds. I'm not sure if anyone wants what fromIntegral does. Or maybe I shouldn't be using hsc2hs in the first place. I feel more and more that it gives haskell a bad name, being low level and error prone. I used bindings-dsl for a libgit2 binding, and at least it automates Storable instances, so it's less error-prone that way. I'd like to generate instances directly from .h files though, so I should probably check out c2hs. Back in the day when I was deciding to use hsc2hs I noticed how it lacks typechecking, but I thought that it's just a few fields, I can be careful when writing them. But one of the lessons from haskell (and static analysis in general) is that just be careful is going to fail you some day, probably sooner than you think. So anyway, I wrote a ForeignC module that defines CStorable that only includes C types. At first I thought I could make Storable a superclass and just re-export functions with more restritive signatures, but then it gets tricky because you wind up needing the Storable peek and poke to declare Storable instances. So I defined a completely new CStorable, and all you need to do is import ForeignC instead of Foreign, and change 'instance Storable ...' to 'instance CStorable ...'. Unfortunately that apparently means copy-pasting over the Storable-using utilities like 'with' and 'newArray'. On the plus side, I dropped it into my .hsc modules, and it found several *more* mistakes. I was thinking of putting it on hackage (along with the conversion functions), since other people might have made these same mistakes, but it's unpleasant because it duplicates so much from Foreign. Also, I only copied over the bits I'm using, so it's not complete either. Is there a better way to create safe Storable instances for C? I'd be happier with a solution that avoids the need to write Storable instances in the first place, but hsc2hs is here now, and used in a lot of places. ___ 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 12/31/12 4:26 PM, Rico Moorman 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? I'm not Bob nor Mike, and haven't read the text in question, but when you encounter function in most any imperative or OO setting, it almost certainly means a first-order procedure. No mathematical functions. No higher-order thingamabobs that you can pass to or return from other thingamabobs. Just an address in code with an expected stack frame configuration associated with it. As for learning object orientation, I'd second the suggestion of Smalltalk. I'll leave the religious wars aside, but OOP means very different things to very different people. Most people use the term whilst referring to C++ and Java, but most people recognize that the ideological framework is best attained by Smalltalk (and related languages like Ruby). So, if you're interested in learning the ideology, then Smalltalk is a great place to get it. Also, Smalltalk has the become method, which is amazing magic. -- Live well, ~wren ___ 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
I said "theoratical", but not "mathematical" or "a scientific" theory. Meyer have built a quite coherent construction in comparison with other OOP langs. BTW, when I started study haskell i had similar question: is it possible to add DbC to haskell? Does haskell need DbC?For example, class invariants may be expressed in DbC construction (fmap id = id for Functior, for example). 02.01.2013, 02:41, "Mike Meyer" m...@mired.org:MigMit miguelim...@yandex.ru wrote:On Jan 1, 2013, at 10:23 PM, Никитин Лев leon.v.niki...@pravmail.ruwrote: Eiffel, for my opinion, is a best OOP language. Meyer use atheoretical 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 onlyfeature I remember that is not present in mainstream languages is it'spre/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
Re: [Haskell-cafe] Makefile for a Haskell Project
Dear all, Thank you for your kind replies. I tried to used ghc --make as Mr. Scott suggested. It is fine if in the C stub I do not call to a non-standard library of C language. The problem is that if I call to a non-standard C library installed (omega) in my system, I cannot compile it. Here is my make file using ghc make: = BASEDIR=/usr/local INCS= -I$(BASEDIR)/include/omega -I. LIBS= -L$(BASEDIR)/lib LIB= -lcode_gen -lomega -lm GHC=ghc # CFILES=$(CURDIR)/cfile HSFILES=$(CURDIR)/hsfile COBJFILES=$(CFILES)/termops.o $(CFILES)/termops2.o ALLCFILES=$(CFILES)/termops.c $(CFILES)/termops2.c # GHC_FLAGS= -O2 -fglasgow-exts -fallow-overlapping-instances _ffi_ex: $(COBJFILES) ghc $(GHC_FLAGS) -lstdc++ --make -main-is FfiEx -o ffi_ex FfiEx.hs $(HSFILES)/*.hs $(LIBS) $(LIB) $(COBJFILES) = = * fatal error: omega.h: No such file or directory * Could you please give me suggestions to solve this? Thank you. Best Regards. Bach. On Fri, Dec 28, 2012 at 5:20 PM, j...@stuttard.org wrote: Quoting xuan bach pig28...@gmail.com: Hi everyone, I'm a newbie in Haskell. I'm wondering that if there is any tool support creating Makefile for Haskell project like Ocamlbuild for Ocaml project? I'v just started learning how to use Neil Mitchell's Shake described at: http://neilmitchell.blogspot.**co.uk/2012/02/shake-better-**make.htmlhttp://neilmitchell.blogspot.co.uk/2012/02/shake-better-make.html Its available on hackage. Hth Thank you, Regards. -- *Le Dinh Xuan Bach* *Tel: 01234711869 or +65 86967149 * *Email: pig28...@gmail.com School of Information and Communication, * *Hanoi University of Science and Technology --**--**- ?? ?01234711869 or +65 86967149 pig28...@gmail.com * -- *Le Dinh Xuan Bach* *Tel: 01234711869 or +65 86967149 * *Email: pig28...@gmail.com School of Information and Communication, * *Hanoi University of Science and Technology - レ。ディン。スアン。バイック 電話番号：01234711869 or +65 86967149 メール： pig28...@gmail.com * ___ 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
[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. 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. 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
