Re: [Haskell-cafe] Fundeps and overlapping instances
Hello, There is no problem if an instances uses a type family in it's assumption---the instances should be accepted only if GHC can see enough of the definition of the type family to ensure that the functional dependency holds. This is exactly the same as what it would do to check that a super class constraint holds. -Iavor On Wed, May 30, 2012 at 11:14 PM, Etienne Laurin etie...@atnnn.com wrote: 2012/5/31 Iavor Diatchki iavor.diatc...@gmail.com: Hello, the notion of a functional dependency is well established, and it was used well before it was introduced to Haskell (for example, take a look at http://en.wikipedia.org/wiki/Functional_dependency). So I'd be weary to redefine it lightly. Indeed, GHC's functional dependencies are not the same. I see you have already talked about this on the GHC bug tracker. http://hackage.haskell.org/trac/ghc/ticket/1241 1. Check that an instance is consistent with itself. For example, this should be rejected: instance C a b because it allows C Int Bool and C Int Char which violate the functional dependency. This check may not always be as straightforward. When would this be a valid instance? instance K a b ⇒ C a b With a few extra extensions, K could be a type family. C currently has the kind (a - b - Constraint), with no mention of functional dependencies. Perhaps the kind of C should include the functional dependencies of C? Etienne Laurin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Tests by properties: origin?
Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (see http://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. (This question pop up when arguing with a Java user about what Haskell brings to the field of development, he pretends it would be astonishing that QuickCheck is the first one using this testing paradigm). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tests by properties: origin?
Am 01.06.2012 12:00, schrieb Yves: Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (seehttp://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. How about reading the original paper introducing QuickCheck? If the authors drew inspiration from elsewhere, the paper is for sure where they would tell you, first hand. :-) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most Important GHC extensions to learn/use?
On Fri, Jun 1, 2012 at 6:29 AM, wren ng thornton w...@freegeek.org wrote: TypeFamilies (aka TFs) These are really nifty and they're all the rage these days. In a formal sense they're equivalent to fundeps, but in practice they're weaker than fundeps. Is that still true? The reason used to be that we didn't have superclass equalities, but we do have them now since 7.2. The only drawbacks I know of relative to FDs are that it's sometimes more typing, not supported by GeneralizedNewtypeDeriving, and doesn't allow OverlappingInstances (ick). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Tests by properties: origin?
Yes ^^ but I can't find this paper, Koen Claessen website doesn't mention it and the link on the page http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck is dead. 2012/6/1 Janis Voigtländer j...@informatik.uni-bonn.de Am 01.06.2012 12:00, schrieb Yves: Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (seehttp://en.wikipedia.org/**wiki/Quickcheckhttp://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. How about reading the original paper introducing QuickCheck? If the authors drew inspiration from elsewhere, the paper is for sure where they would tell you, first hand. :-) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~**jv/ http://www.iai.uni-bonn.de/%7Ejv/ __**_ 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] Tests by properties: origin?
See the Further Reading section on the wikipedia page you provided (http://en.wikipedia.org/wiki/Quickcheck), not all links are dead. 2012/6/1 Yves Parès yves.pa...@gmail.com: Yes ^^ but I can't find this paper, Koen Claessen website doesn't mention it and the link on the page http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck is dead. 2012/6/1 Janis Voigtländer j...@informatik.uni-bonn.de Am 01.06.2012 12:00, schrieb Yves: Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (seehttp://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. How about reading the original paper introducing QuickCheck? If the authors drew inspiration from elsewhere, the paper is for sure where they would tell you, first hand. :-) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ 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] Tests by properties: origin?
Is this the paper you are looking for: http://www.eecs.northwestern.edu/~robby/courses/395-495-2009-fall/quick.pdf ? On 1 June 2012 11:20, Yves Parès yves.pa...@gmail.com wrote: Yes ^^ but I can't find this paper, Koen Claessen website doesn't mention it and the link on the page http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck is dead. 2012/6/1 Janis Voigtländer j...@informatik.uni-bonn.de Am 01.06.2012 12:00, schrieb Yves: Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (seehttp://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. How about reading the original paper introducing QuickCheck? If the authors drew inspiration from elsewhere, the paper is for sure where they would tell you, first hand. :-) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ 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] Tests by properties: origin?
Yes, it's that one, the first Quickcheck paper, thanks. The link on the wikipedia page is also dead. 2012/6/1 Ivan Perez ivanperezdoming...@gmail.com Is this the paper you are looking for: http://www.eecs.northwestern.edu/~robby/courses/395-495-2009-fall/quick.pdf ? On 1 June 2012 11:20, Yves Parès yves.pa...@gmail.com wrote: Yes ^^ but I can't find this paper, Koen Claessen website doesn't mention it and the link on the page http://www.haskell.org/haskellwiki/Introduction_to_QuickCheck is dead. 2012/6/1 Janis Voigtländer j...@informatik.uni-bonn.de Am 01.06.2012 12:00, schrieb Yves: Out of curiosity, does someone know if QuickCheck was the first test framework working through test by properties associated with random generation or if it drew the idea from something else? Because the idea has be retaken by a lot of frameworks in several languages (seehttp://en.wikipedia.org/wiki/Quickcheck), but I can't find what was QuickCheck inspiration. How about reading the original paper introducing QuickCheck? If the authors drew inspiration from elsewhere, the paper is for sure where they would tell you, first hand. :-) Best, Janis. -- Jun.-Prof. Dr. Janis Voigtländer http://www.iai.uni-bonn.de/~jv/ ___ 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] Fundeps and overlapping instances
Hello, 2012/6/1 Iavor Diatchki iavor.diatc...@gmail.com: There is no problem if an instances uses a type family in it's assumption---the instances should be accepted only if GHC can see enough of the definition of the type family to ensure that the functional dependency holds. This is exactly the same as what it would do to check that a super class constraint holds. GHC cannot see enough of the definition because type families are open. The type instances are not guaranteed to all be in scope when the class instance is defined. 2012/6/1 AntC anthony_clay...@clear.net.nz: Some of Oleg's instances are awesome (and almost impenetrable -- the TTypeable code is a tour de force). It's all so *dys-functional* (IMO). It's like a typed Prolog with a different order of evaluation. My take is that we should abandon Fundeps, and concentrate on introducing overlaps into type functions in a controlled way (what I've called 'dis- overlapped overlaps'.) Abandoning fundeps would be a sad day for type-level programming. There are many things other than overlaps that you can do with fundeps and constraint kinds that you cannot currently do with type families, such as: - Partial application or higher-order programming. - Short-circuit evaluation, lazy evaluation or type-level case. To study the differences, I have been porting parts of the Prelude to both type classes and type families. http://code.atnnn.com/projects/type-prelude/repository/entry/Prelude/Type.hs http://code.atnnn.com/projects/type-prelude/repository/entry/Prelude/Type/Families.hs Etienne Laurin On Wed, May 30, 2012 at 11:14 PM, Etienne Laurin etie...@atnnn.com wrote: 1. Check that an instance is consistent with itself. For example, this should be rejected: instance C a b because it allows C Int Bool and C Int Char which violate the functional dependency. This check may not always be as straightforward. When would this be a valid instance? instance K a b ⇒ C a b With a few extra extensions, K could be a type family. C currently has the kind (a - b - Constraint), with no mention of functional dependencies. Perhaps the kind of C should include the functional dependencies of C? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Requesting Feedback: I Love Haskell, but can't find a place to use it
I love Haskell. It is my absolute favorite language. But I have a very hard time finding places where I can actually use it! have you considered your head as such a place that should be easy to find. An excellent reason. Haskell shines unusually brightly on applications that have an algebraic structure. Laziness relieves a plethora of sequencing concerns. I particularly treasure one experience: I asked a guru about the complexity of converting regular expressions to finite-state automata without epsilon transitions (state transitions that don't produce output). The best he knew was O(n^3), which is the cost of removing epsilon transitions from arbitrary automata. Then I wrote about a dozen lines of Haskell to do the job--and running time turned out to be O(n^2). Once I'd written the code, it became clear how to do it in other languages, but I never would have found the theorem without the help of Haskell. (This without even bringing in the heavy artillery of higher-order functions and monads.) Doug McIlroy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Requesting Feedback: I Love Haskell, but can't find a place to use it
Then I wrote about a dozen lines of Haskell to do the job--and running time turned out to be O(n^2). Do you still have the code? 2012/6/1 Doug McIlroy d...@cs.dartmouth.edu I love Haskell. It is my absolute favorite language. But I have a very hard time finding places where I can actually use it! have you considered your head as such a place that should be easy to find. An excellent reason. Haskell shines unusually brightly on applications that have an algebraic structure. Laziness relieves a plethora of sequencing concerns. I particularly treasure one experience: I asked a guru about the complexity of converting regular expressions to finite-state automata without epsilon transitions (state transitions that don't produce output). The best he knew was O(n^3), which is the cost of removing epsilon transitions from arbitrary automata. Then I wrote about a dozen lines of Haskell to do the job--and running time turned out to be O(n^2). Once I'd written the code, it became clear how to do it in other languages, but I never would have found the theorem without the help of Haskell. (This without even bringing in the heavy artillery of higher-order functions and monads.) Doug McIlroy ___ 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] Requesting Feedback: I Love Haskell, but can't find a place to use it
I love Haskell. It is my absolute favorite language. But I have a very hard time finding places where I can actually use it! have you considered your head as such a place that should be easy to find. Excellent advice. Haskell shines unusually brightly on applications that have an algebraic structure. And laziness relieves a plethora of sequencing concerns. I particularly treasure one experience: I asked a guru about the complexity of converting regular expressions to finite-state automata without epsilon transitions (state transitions that don't produce output). The best he knew was O(n^3), which is the cost of removing epsilon transitions from arbitrary automata. Then I wrote about a dozen lines of Haskell to do the job--and running time turned out to be O(n^2). Once I'd written the code, it became clear how to do it in other languages, but I never would have found the theorem without the help of Haskell. (This without even bringing in the heavy artillery of higher-order functions and monads.) Doug McIlroy ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most Important GHC extensions to learn/use?
On Jun 1, 2012, at 6:11 AM, Gábor Lehel wrote: On Fri, Jun 1, 2012 at 6:29 AM, wren ng thornton w...@freegeek.org wrote: TypeFamilies (aka TFs) These are really nifty and they're all the rage these days. In a formal sense they're equivalent to fundeps, but in practice they're weaker than fundeps. Is that still true? The reason used to be that we didn't have superclass equalities, but we do have them now since 7.2. The only drawbacks I know of relative to FDs are that it's sometimes more typing, not supported by GeneralizedNewtypeDeriving, and doesn't allow OverlappingInstances (ick). In addition to other things mentioned today in the Fundeps and overlapping instances thread, type families have no way of defining injective type functions where the range includes already-existing types. For example, if you define: type family Succ a there is no way (that I've found) to define it in such a way that the compiler can see that Succ a ~ Succ b = a ~ b. The equivalent in MPTCs+FDs would be: class Succ a b | a - b, b - a There is more discussion of this particular weakness at http://hackage.haskell.org/trac/ghc/ticket/6018 . Also, there are less-common usages of fundeps that may be translatable to type families but not easily, when there are complex interrelationships between type variables. For example, type-level binary operations will sometimes have fundeps such as a b - c, a c - b, b c - a - that is to say, any two determines the third. -- James ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] GHCi Loop Detection
Hi Cafe, Is there a reason that the GHCi interpreter doesn't detect and report infinite loops in statements like this (like compiled programs do) even though no CPU time appears to be used? My (admittedly weak) searching for an answer didn't turn much up. let s | not $ null s = [] in s GHCi v7.0.4 on OSX Thanks, John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need inputs for a Haskell awareness presentation
C K Kashyap ckkash...@gmail.com writes: c) Where's my inheritance? I was of the impression that OO has crawled our way, for instance frowing upon (implementation) inheritance and mutable data structures. Maybe you could find appropriate references? Lots of language development these days seems to be looking to functional languages for inspiration. e) Static types - in this day and age - come on - productivity in X is so much more - and that's because they got rid of type mess. Don't mention static types until later - show code without annotations. Then later explain that things are statically typed even without annotations, and that static types helps correctness, e.g. when refactoring code, or building complex compositions of higher order functions. Could you reasonalby do arrows or monads etc. in a dynamically typed language? Moreover, I don't think STM is going to work without types separating TVars from other data, and this shows our types are more powerful than your grandfather's C-style type systems. g) Oh FP, as in Lisp, oh, that's AI stuff right ... we don't really do AI. ...and Java, that's imperative...like Fortran, isn't it? Nah, we don't calculate artillery tables, so... Btw, maybe there could be a wiki section or something with stuff like this - I think it would be useful to collect introductory resources for settings like this - I know I'm often being asked about this Haskell stuff from colleagues and friends. -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most Important GHC extensions to learn/use?
wren ng thornton w...@freegeek.org writes: There are a bunch which are mostly just syntax changes. The important ones are: Also, if you have new GHC, it will often tell you if/when you need to enable extensions. E.g.: Line 8: 1 error(s), 0 warning(s) `Pos' has no constructors (-XEmptyDataDecls permits this) In the data type declaration for `Pos' -k -- If I haven't seen further, it is by standing in the footprints of giants ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Requesting Feedback: I Love Haskell, but can't find a place to use it
So anyway I'd like to request feedback: where can I use Haskell besides simple CLI utilities, dull server code, or project Euler problems? Even if it's just to contribute to getting Haskell in the environments mentioned above, any feedback is welcome! Well I have used it for some not-so-typical Haskell tasks: - An installer (command line) for some other software in C++ (unpacking, installing COTS libraries, installing and setting up MySQL on different machines including replication, setting up and installing the software and also apply updates to it) - A satellite simulator for testing mission control systems. It's very basic but it can handle telecommands and arbitrary telemetry (definable with a DSL which is loaded and interpreted at runtime), as well as basic ground station routing messages, on-board queue simulation, on-board software upload/download simulation and also some statistics about sent telecommands. I actually used it for some telecommand performance measurements for a real mission control system for an existing satellite (which it simulated) as well as on debugging actions on the MCS. For me the main point was to see if I could implement this functionality in Haskell (there are other test-sims in C++ but with less functionality and still a lot bigger in LOC). Due to the imperative nature and my (ahem) limited abilities in Haskell the code is in parts very ugly, but it grows and is refactored if I need new features. Currently if I have time I am working on a GUI for it (otherwise it's just command line). - Various test programs to stimulate servers with input. Especially encoding/decoding of various (binary) protocols is far much easier and faster to write in Haskell. - Various conversion tools. E.g. currently I have a tool in the pipe (just in the beginning stage) to convert something like CSV output into a OpenOffice Calc spreadsheet for further processing/graphing/whatever. Also I'd like to have a kind of OpenDocument library to be able to generate reports, so this is the next step then. Due to my very limited time in the moment this is currently stalled. For me it would also be quite interesting to have a working CORBA implementation with Haskell (as we have some applications at work which use it), but I seem to be the only one. lg, Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need inputs for a Haskell awareness presentation
We have recently delivered a two-day hands-on Haskell training at Qualcomm. As Chris points out, parsing and concurrency/parallelism are the undisputed strengths of Haskell, so we used them extensively. The first day was dedicated to writing a parser of arithmetic expressions with symbolic variables, from scratch. We started very close to imperative style, so we had a tokenizer, parser, and evaluator. They all contained a lot of boilerplate code: error testing and state passing (input string in the tokenizer, token list in the parser, and symbol table in the evaluator). So it was very natural to abstract all this boilerplate into monads. There was actually a big aha! when we abstracted all these nasty control structures into bind and return and then showed the do notation. The second day was dedicated to concurrency and parallelism, starting with forkIO and MVars, then going through the par monad (with some hands-on exercises) and Repa, and finally showing Accelerate on GPUs. The course was a great success. We didn't have to deal with any nasty questions. We explained some of the evaluation strategies (strict, head-normal, bang) and memory issue workarounds (foldl vs foldr, etc.). We also showed an example of inductive proof of a simple property to show how Haskell can help with correctness. FP Complete and Well-Typed are planning on releasing some of our training materials to the public soon (depending on how much time I have to organize them). [:Bartosz:] On 5/31/2012 18:12, Chris Wong wrote: On Fri, Jun 1, 2012 at 6:23 AM, C K Kashyapckkash...@gmail.com wrote: Hi folks, I have the opportunity to make a presentation to folks (developers and managers) in my organization about Haskell - and why it's important - and why it's the only way forward. I request you to share your experiences/suggestions for the following - 1. Any thoughts around the outline of the presentation - target audience being seasoned imperative programmers who love and live at the pinnacle of object oriented bliss. Rustom nailed it. Take something imperative languages are really, really bad at and *show* how it's done in Haskell. * Parsing Haskell parser combinators make yacc look old school. By leveraging Haskell's DSL features, parsers often end up looking like the grammar they're implementing. Different parser combinator libraries let you do incremental input (Attoparsec), show clang-style diagnostics (Trifecta), or perform crazy optimizations automatically (uu-parsinglib). * Iteratee I/O encodeFile from to =apOutput encode (sourceFile from) $$ sinkFile to It may not look like it, but the above function (using the conduit package) sets up a I/O pipeline that uses constant memory. There are HTTP, FTP, text encoding and parser libraries that can hook into the pipeline the same way. All the resources (sockets, file handles) tied up in the pipeline are finalized automatically when it finishes or when an exception is thrown. * Epic concurrency GHC comes with preemptive scheduling, STM and async I/O built in. Maybe you could demonstrate these with a ping-pong-style application. 2. Handling questions/comments like these in witty/interesting ways - a) It looks good and mathematical but practically, what can we do with it, all our stuff is in C++ Anything you can do in another Turing-complete language ;) Quite a few folks have helped push Haskell into the practical world, with useful things like web frameworks, ByteStrings, GUI bindings... It's suitable for practical applications already. b) Wow, what do you mean you cannot reason about its space complexity? That's not a bug, it's a feature! C++ gives you lots of control over how your program runs. Unfortunately, most people don't need that or don't know how to use it effectively. So most of the time, these low-level features just add a bunch of cruft with no real benefit to the programmer. Haskell goes the opposite way. The Haskell standard goes out of its way *not* to say how programs actually run -- only what the result should be. This lets the compiler optimize much more than in other languages. This philosophy is reflected in a common technique called stream fusion. I can't be bothered writing an example for this, but Google it and you'll find a few. c) Where's my inheritance? Right behind you ;) d) Debugging looks like a nightmare - we cannot even put a print in the function? Traditional debugging -- stepping through the program line by line -- fails miserably in Haskell, mostly due to (b). Haskell programmers tend to use more mathematical techniques: * Property-based testing, e.g. reverse (reverse xs) =xs. Used extensively in Xmonad. * Algebraic proofs (this works especially well for framework stuff like the MTL). * Sexy types: encoding invariants in the type so the compiler checks it for you. The fb (Facebook API) package does this with the NoAuth and Auth phantom types. For
[Haskell-cafe] Program for displaying graph state in lambda interpreter?
Hi, I have written an interpreter that operates on the lambda calculus augmented with letrec, constructors, case, primitive objects, and builtin operations. I'd like to display the internal state of the intepreter at various points so that I can, um, debug the programs that I've written. Currently I've got about 3500 nodes, and I'm dumping a graph that I format using the 'dot' program in graphviz. I might have let x = 1+2 in x*x represented as. x/1: 2+3 2: 1.0 3: 2.0 4: 1*1 where 1, 2, 3, represent various memory locations. I can display this in graphviz, where each node is a rectangle containing text like 1*1 and there are arrows from the rectangle to 1. This works as long as the number of nodes isn't very large. However, it would be nice to know of any programs that are better suited for this. For example, if I could write * and draw arrows from the placeholders to the memory location being referenced, that would be easier to read. This is done here http://en.wikibooks.org/wiki/Haskell/Graph_reduction to illustrate that 'square (1+2)' doesn't evaluate 1+2 twice. Any ideas? thanks, -BenRI P.S. If this is too off-topic, please let me know. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Program for displaying graph state in lambda interpreter?
Hi Benjamin, On Fri, Jun 1, 2012 at 9:54 PM, Benjamin Redelings wrote: I have written an interpreter that operates on the lambda calculus augmented with letrec, constructors, case, primitive objects, and builtin operations. I'd like to display the internal state of the intepreter at various points so that I can, um, debug the programs that I've written. Currently I've got about 3500 nodes, and I'm dumping a graph that I format using the 'dot' program in graphviz. [...] However, it would be nice to know of any programs that are better suited for this. For example, if I could write * and draw arrows from the placeholders to the memory location being referenced, that would be easier to read. This is done here http://en.wikibooks.org/wiki/** Haskell/Graph_reductionhttp://en.wikibooks.org/wiki/Haskell/Graph_reductionto illustrate that 'square (1+2)' doesn't evaluate 1+2 twice. Any ideas? This may not answer your question, but it might be related and/or helpful: http://rochel.info/#graph-rewriting Regards, Sean ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most Important GHC extensions to learn/use?
On 6/1/12 12:45 AM, Jonathan Geddes wrote: Thanks, Wren, I really appreciate the detailed response! Though I am surprised that Template Haskell isn't on your list. From the little I know of TH it seems like all of the interesting generic/generative stuff is done with TH. Do the other extensions subsume the need for TH, or is it just not terribly interesting? TH is plenty interesting, but it's a very different sort of direction to head. The extensions I mentioned are the ones I think everyone assumes a seasoned Haskeller will know. With the exception of TFs and GADTs, those extensions have all been around since the days of GHC 6.6 and Hugs. Thus, most people consider them normal parts of Haskell even if they're not in in the Report. Consequently, understanding them is necessary to understand most of the non-H98 code on Hackage. TH, on the other hand, is very much GHC-only and that's unlikely to change. Also, there's a lot of unnecessary(?) grunge there. The basic theory of staged computation which led to TH was laid out in the MetaML/MetaOCaml papers. The version in MetaML is a lot nicer in terms of the theory, so I'd suggest people start there before diving into TH. One of the nice things in MetaML is that there's no limit on the levels of meta-ness. This was removed from TH because it would require having the compiler present in every executable; a sensible limitation, though it complicates the theory. Another major difference is that MetaML only did staging at the term level, whereas TH also allows splices in type signatures, splices which generate type class instances, etc. These extensions make TH *much* more powerful than MetaML, but also make it *much* harder to understand and reason about. IMO the formal theory of these non-term splices hasn't been worked out very well, which is part of the reason why TH is so grungy to work with. I'm a big fan of staged computation, and I'd definitely suggest any sophisticated functional programmer should read the MetaML papers (and the TH papers if so inclined, and the Flask papers to get a different perspective on the theme). But very few packages require understanding TH in order to understand them, and even fewer require understanding TH in order to use them. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Most Important GHC extensions to learn/use?
On 6/1/12 6:11 AM, Gábor Lehel wrote: On Fri, Jun 1, 2012 at 6:29 AM, wren ng thorntonw...@freegeek.org wrote: TypeFamilies (aka TFs) These are really nifty and they're all the rage these days. In a formal sense they're equivalent to fundeps, but in practice they're weaker than fundeps. Is that still true? The reason used to be that we didn't have superclass equalities, but we do have them now since 7.2. The only drawbacks I know of relative to FDs are that it's sometimes more typing, not supported by GeneralizedNewtypeDeriving, and doesn't allow OverlappingInstances (ick). The superclass equalities was a big thing, but the disparity remains even still. The main problem is that type inference with fundeps remains more powerful than type inference for TFs. There are still patterns of use which infer/check easily with fundeps but which don't have an equivalent TF implementation. I haven't messed with TFs enough to know the details here, but there are other folks on the list who do. In addition there's the issue of overlapping instances, which is currently being discussed elsewhere. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need inputs for a Haskell awareness presentation
I have the opportunity to make a presentation to folks (developers and managers) in my organization about Haskell - and why it's important - and why it's the only way forward. Haskell is important, but not the only way forward. Also, there have been other great languages, with limited impact - incorporating great ideas is no guarantee for takeup. If you want to be convincing, you need to be honest. 1. Any thoughts around the outline of the presentation - target audience being seasoned imperative programmers who love and live at the pinnacle of object oriented bliss. If you approach this from the Haskell side (what is Haskell good at), you might get some people curious, but you won't connect their interest to their daily work. You don't want to give them a show, you want to inspire them to want to try coding in that language. If you really want to understand what is good about Haskell, stop using it for a while, and work in something like Javascript (or whatever your audience is comfortable with, but for me Javascript was an eye opener). You won't believe how basic the issues are that conventional coders are struggling with until you realize that you do not have them in Haskell. If you have felt that pain, have understood that you can't make those issues go away by saying that wouldn't be an issue in Haskell, then you can understand that their struggles and issues are real. If you respect that, you can take one of their problems/source bases, and translate it to Haskell. That step tells them (and you!) that Haskell is adequate for their problem domains (which won't always be the case - no point showing them a wonderful language that they won't be able to apply). The next step is to go through some of those pain points in that code and show how to get rid of them in the Haskell version. Instead of presenting ready-made solutions, show them how to work with code they understand, much more confidently than they would be used to. Go slowly, and focus on their daily pain points (which they probably have stopped feeling because they can't do anything against them). Explain why you are confident in your modifications, compare against the obstacles that their current language would throw up against such modifications. Some examples: - types can replace basic documentation and documentation lookup - no need to test things that the type system can check, not in test suites and not in the prelude of every function definition; you still need tests, but those can focus on interesting aspects; you don't need to run 10 minutes of tests to verify that a refactoring in a large code base hasn't broken scoping by misspelling a variable name, or that function calls have the proper number and type of parameters - thanks to decades of development, Haskell's static type system does not (usually) prevent you from writing the code you mean (this is where the proof comes in - you've rewritten their code in Haskell), nor does it clutter the code with type annotations; types of functions can be inferred and checked, unlike missing or outdated documentation; (careful here: language weaknesses are often compensated for through extensive tool usage; some IDEs may check type annotations within comments, or try to cover other gaps in dynamic languages) - part of the trick is to work with the type system instead of against it: document intentions in code, not comments - separation of expressions and statements - instead of every expression being a statement (side effects everywhere), every statement is an expression (functional abstraction works everywhere) - since functional abstraction works everywhere, once you see repeated code, you know you can factor it out - you can build libraries of useful abstractions - building abstraction libraries in the language is so easy that you can build domain-specific abstraction libraries - domain-specific abstraction libraries become embedded DSLs; no need to write parsers, no risk to useful program properties from overuse of introspection - .. I better stop here - I hope you can see the direction:-) Many of these do not even touch on the advanced language features, but all of them rely on the simplicity and careful design of the core language. All of these advantages carry over to concurrent and parallel programming, without having to switch to another language. Also, both functions and threads are so cheap (and controllable in terms of side-effects) that you do not have to break your head to avoid using them. And instead of noisy syntax, Haskell's syntax tends not to get in the way of writing in domain-specific abstractions. The main advantages of Haskell (as I see them at this moment;-): - fewer problems to keep track of: can focus on higher-level issues - great support for abstraction: you can scratch that itch and don't have to live with feeling bad about your code; over time, that means
Re: [Haskell-cafe] Safe Haskell at the export symbol granularity?
So this is a good question, sorry for the late reply. It's tricky as the way typeclasses are imported and exported in Haskell is confusing. Basically, instances are hard to control access to as they aren't part of import or export statements. Importing a module that defines an instances gives you those instances. This works transitively so you have access to all instances defined below you in the dependency graph. Controlling access to a typeclass function is easy though, it works just like a normal function. So in your example, the Safe module wouldn't necessarily become unsafe but there is some unsatisfactory trickiness. - untrusted code still couldn't access the type class as the functions for it aren't exported. - the derived functions may or may not be safe anymore depending on polymorphism: - If the derived functions don't have any polymorphism that would allow consumers of the functions to choose what underlying typeclass is used, then the module is still safe. - If they do, then yes untrusted code could choose what types to use to cause the unsafe instance to be used, thus making the derived functions unsafe. (This assumes the untrusted code has access to the unsafe instance but as I said, this is hard to reason about since instances are somewhat global). there are solutions to this problem but its a tricky situation with the solutions really being to be careful... I don't know how we could do better. Tracking safety at the symbol level doesn't seem like it would change this situation. Basically you want closed type classes or a way to control what instances can be used (maybe by simply making instances part of import/export lists) both of which are big changes to Haskell. I wrote some example code and a note about this stuff: https://github.com/dterei/SafeHaskellExamples/tree/master/typeclasses Cheers, David On 18 May 2012 06:58, Gábor Lehel illiss...@gmail.com wrote: I have a related-seeming question: Say I have a type class with methods, and some functions implemented on top of it. The class methods are inherently unsafe. Instances of the class are supposed to satisfy some conditions, and if those conditions are met, the functions built on top are safe. So say I put the class in an Unsafe module, and re-export the class without its methods along with the derived functions in a Safe module. For anything unsafe to happen, the Unsafe module has to be imported somewhere. But if someone imports it and implements a bad instance, the Safe module *also* becomes potentially unsafe! What's the recommended practice here? (I can't really tell if this is the same question as originally posed by Ryan, but I think it's not.) On Thu, May 17, 2012 at 4:53 PM, Ryan Newton rrnew...@gmail.com wrote: Good point, Antoine! I think that does the trick. On Thu, May 17, 2012 at 10:48 AM, Antoine Latter aslat...@gmail.com wrote: On Thu, May 17, 2012 at 8:50 AM, Ryan Newton rrnew...@gmail.com wrote: Thanks David. I'm glad to see it was discussed in the wiki. (Btw, my 2 cents is that I like the comment pragmas more than new keywords.) The issue that I think doesn't make it into the wiki is of splitting, not modules, but type-classes. That's where I think it becomes a more serious issue. Do you think a symbol-level Safe Haskell would be able to distinguish one method of a type class as unsafe, while the others are safe? You can still do this at the module level, with the down-side of potentially not being able to implement a class with the safe version: module Unsafe where class MyClass a where safeOp :: a - Int - IO () unsafeOp :: a - Int - IO () instance MyClass A where ... module Safe (MyClass(safeOp)) where import Unsafe I think this works. Antoine ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries -- Work is punishment for failing to procrastinate effectively. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
