- Beginners - Haskell.org

Re: [Haskell-beginners] Functional programming principles at higher levels?
by Christopher Howard 26 Sep '11

26 Sep '11

On 09/24/2011 09:12 PM, Mike Meyer wrote: > > Actually, functional programming and the higher math are separate > things. Haskell (and I expect the similar languages) have a lot of > math in their documentation. But that's not true for other functional > languages, like Clojure or Scheme. With a background in those > languages, I didn't have much trouble with the functional nature of > haskell. But I'm still trying to recall the graduate math courses I > took long time ago in a state far, far different from today. > Really? I'll confess I'm a bit surprised to hear that perspective. I don't know anything about Clojure or Scheme. But I found in trying to understand Haskell that it really is all about higher math. Once I finally gave up on "learnyouahaskell" and other ridiculous tutorials, I found the real functional programming textbooks, and discovered that it all starts with lambda calculus; all the explanations are given in set theory notation, with occasionally comparisons to integral and differential calculus for illustration, with very specific rules regarding substitution and reduction and normal forms. I'm still trying to figure out what all those combinators are about! And it is all rested on mathematical proofs, usually inductive. And that is just the lambda calculus aspect. Then we move on to type theory (!!!) plus the various types of polymorphism, and then on to a number of other topics that I don't know enough about to even mention intelligibly. -- frigidcode.com theologia.indicium.us

5 6

Re: [Haskell-beginners] clarity and complexity of Haskell
by Gregory Guthrie 25 Sep '11

25 Sep '11

I agree that the paradigm shift is an issue, but I don't think it is the main element for the things that I am pointing out. And I do think that Functional languages with their declarative style, type inference, polymorphism, lack of state, all do make FP style clearer and simpler. I come from SML (fairly casual usage), and I think the bump in learning curve (and thus clarity in reading) at least for me in Haskell is the shift to Monads and Applicatives, with their unfamiliar syntax of new operators, and semantics on those. Most other things in FP are a fairly simple shift; the domains and operations, and expression & operator syntax, and recursion, etc. are fairly familiar, just a different style is needed. Of course the Lazy nature of Haskell does require some adjustment in the underlying model and understanding of evaluation. When shifting to Functors, Applicatives, Monads, Arrows, all of these elements change significantly and there is no corresponding familiar domain for reference. Yes, I certainly agree that once one gets familiar with this model and syntax, and new operators and usage, it is powerful and readable. Just as APL, Perl, ... I agree with the earlier response that the increasing number of unfamiliar operators in Haskell increases the learning curse, albeit for their associated power in usage. I think that APL had a similar characteristic. :) This was not a complaint, but just an observation; my interest is mainly in teaching Introductory FP as a part of various comparative programming languages. No language wars intended; I was just interested in calibration from the views and experiences of more expert and experienced Haskell'ers.

1 0

how to catch the error thrown by openFile?
by Ovidiu Deac 25 Sep '11

25 Sep '11

Thanks a lot! It took me a while to understand what you meant but eventually I got it. This is the final version and it looks much better: f :: MyMonad String f = do liftIO $ putStrLn "Please enter a file name: " name ← liftIO getLine hFile ← ErrorT $ (openFile name ReadMode ↠ return.Right) `catch` λ_ → return.Left $ KnownErr "open failed" content ← liftIO $ hGetContents hFile return content Somehow I understand but I don't have the feeling yet why I apply ErrorT to the whole catched expression instead of liftIO. Do you have a nice explanation for it? Ovidiu On Sat, Sep 24, 2011 at 10:21 PM, Daniel Fischer <daniel.is.fischer(a)googlemail.com> wrote: > On Saturday 24 September 2011, 19:52:24, Ovidiu Deac wrote: >> Given this function >> >> f :: MyMonad String >> f = do >> liftIO $ putStrLn "Please enter a file name: " >> name ← liftIO getLine >> hFile ← liftIO $ openFile name ReadMode >> content ← liftIO $ hGetContents hFile >> return $ content >> >> I would like to catch the error thrown by openFile and translate it to >> my own exception type. >> >> So first I tried this: >> hFile ← (liftIO $ openFile name ReadMode) `catch` λ_ → throwError >> (KnownErr "open failed") > > catch has type (IO a -> (e -> IO a) -> IO a) [where e = IOError if you're > using Prelude.catch, and e can be any instance of Exception if you're using > Control.Exception.catch (recommended)]. > > But (liftIO ioAction) has type (MyMonad a), so that can't be used as an > argument to catch. > Nor can (\_ -> throwError (KnownErr "...")). > >> >> ..but it fails because the error handler is returning a different type >> then the "try block". Right? > > No, it fails because both have the wrong type for catch. > It would typecheck with catchError instead of catch, but that wouldn't > catch the error :( > >> >> Then I tried this: >> f = do >> liftIO $ putStrLn "Please enter a file name: " >> name ← liftIO getLine >> hFile ← (liftIO $ openFile name ReadMode ↠ return.Right) >> `catch` λ_ → return (Left $ KnownErr "open failed") > > Close. If you replace liftIO with ErrorT in that line and move the first > open parenthesis past the $, then it works and does what you want. Without > changing the following two lines (or, better, do change them; > do x <- act > return x > > is the same as just > > act > ). liftIO adds a layer of Either, ErrorT doesn't. > > hFile <- ErrorT $ liftM Right (openFile name ReadMode) > `catch` (\_ -> return $ Left (KnownErr "open failed")) > liftIO $ hGetContents hFile >

2 2

Functional programming principles at higher levels?
by Christopher Howard 25 Sep '11

25 Sep '11

Caveat: I have a lot to learn about functional programming. And it is probably going to take me years to get there, because of all the higher mathematics I need to catch up on. Having said that... It seems to me like there are at least two core ideas to functional programming: 1. Seeing a program as an expression that is evaluated. 2. Referential transparency. And these lead to or involve various other concepts: writing code that can easily be refactored; viewing computations as a set of dependencies to be resolved rather than steps to follow; mathematical rather than procedural approaches to solving problems; the exclusion or minimization of state. But has anyone attempted to apply these principles to programming at higher levels than just writing the code? Say, overarching software architecture? Or resource management models? I've been reading lately about various higher level software approaches and models like RESTful architectures and MVC frameworks and RM-ODP, and it is difficult to see what I should grab onto. -- frigidcode.com theologia.indicium.us

1 0

how more efficient read/write a file ?
by anyzhen 24 Sep '11

24 Sep '11

consider this : i want load a 4G file(or some bigger file) ,and the process data operation just like 010 to 101( XOR bits ) , is it some efficient function down it ? such hPutStr hPutChar is Char layer , is exist bit layer operations? thanks for any help jiangzhen3s(a)qq.com

4 3

how to catch the error thrown by openFile?
by Ovidiu Deac 24 Sep '11

24 Sep '11

Given this function f :: MyMonad String f = do liftIO $ putStrLn "Please enter a file name: " name ← liftIO getLine hFile ← liftIO $ openFile name ReadMode content ← liftIO $ hGetContents hFile return $ content I would like to catch the error thrown by openFile and translate it to my own exception type. So first I tried this: hFile ← (liftIO $ openFile name ReadMode) `catch` λ_ → throwError (KnownErr "open failed") ..but it fails because the error handler is returning a different type then the "try block". Right? Then I tried this: f = do liftIO $ putStrLn "Please enter a file name: " name ← liftIO getLine hFile ← (liftIO $ openFile name ReadMode ↠ return.Right) `catch` λ_ → return (Left $ KnownErr "open failed") case hFile of Right handle → do content ← liftIO $ hGetContents hFile return $ content Left error → throwError error ...which also fails with Couldn't match expected type `ErrorT MyType IO t0' with actual type `IO a0' In a stmt of a 'do' expression: hFile <- (do { handle <- liftIO $ openFile name ReadMode; return (Right handle) }) `catch` \ _ -> return (Left $ KnownErr "open failed") Any help is appreciated. Thanks! Full code here: import Control.Monad.Error import System.IO data MyType = UnknownErr | KnownErr String deriving (Show) instance Error MyType where noMsg = UnknownErr strMsg str = KnownErr str type MyMonad = ErrorT MyType IO main = do r ← runErrorT f reportResult r f :: MyMonad String f = do liftIO $ putStrLn "Please enter a file name: " name ← liftIO getLine hFile ← liftIO $ openFile name ReadMode content ← liftIO $ hGetContents hFile return $ content reportResult (Right c) = putStrLn ("The content is " ⊕ c) reportResult (Left e) = putStrLn ("Error: " ⊕ (show e))

2 1

Question regarding to type classes
by Johannes Engels 24 Sep '11

24 Sep '11

Thank you very much, Antoine Latter and, particularly, Daniel Fischer for your excellent explanation! You have exactly understood what I intended and answered my question completely, so you really made my day! Johannes

1 0

Question regarding to type classes
by Johannes Engels 24 Sep '11

24 Sep '11

Dear list members, as an exercise, I tried to define a type class for structures with ordered key values. The key values could be numbers, but also strings. For instance, I intend to define an address list containing records with names as key values. So far, my type class definition contains a function "key", which should extract the key values from the structures, and a function which compares the key values. So I tried: class StructsWithOrderedKeys a where -- no default definition for key key :: (Ord b) => a -> b (<?) :: a -> a -> Bool x <? y = (key x) < (key y) Here I get the following error message from GHCI: "Ambiguous type variable 'b' in the constraint: 'Ord b' arising from a use of 'key' ... Probable fix: add a type signature that fixes these type variable(s)" Could anybody explain what ambiguity arises here? As the arguments of (<?) are of the same type, I expected also the results (key x) and (key y) to be of the same type, which should be by the type constraint for "key" an instance of Ord. Why I am not allowed to use "key" in the definition of (<?) ? I would be grateful for any hint! Johannes

3 2

apt cabal hackage
by Anuradha L 24 Sep '11

24 Sep '11

Can anyone point me to a tutorial or howto on haskell package management under debian/ubuntu? Some of the things that are making my head spin... How when to use hackage/cabal? And when apt? How to translate haskell internal names (ie names given to import) to package names ie either cabal or apt names? Global (/usr) vs local (under $HOME) packages and figuring out paths Thanks

7 15

Invitation to connect on LinkedIn
by Mukesh Tiwari via LinkedIn 21 Sep '11

21 Sep '11

LinkedIn ------------ Mukesh Tiwari requested to add you as a connection on LinkedIn: ------------------------------------------ Mihai, I'd like to add you to my professional network on LinkedIn. - Mukesh Accept invitation from Mukesh Tiwari http://www.linkedin.com/e/-3dpk6t-gsuvqphz-6b/uyFflI7IwvrmSA8-0MFfTI7lXX8s3… View invitation from Mukesh Tiwari http://www.linkedin.com/e/-3dpk6t-gsuvqphz-6b/uyFflI7IwvrmSA8-0MFfTI7lXX8s3… ------------------------------------------ DID YOU KNOW LinkedIn can help you find the right service providers using recommendations from your trusted network? Using LinkedIn Services, you can take the risky guesswork out of selecting service providers by reading the recommendations of credible, trustworthy members of your network. http://www.linkedin.com/e/-3dpk6t-gsuvqphz-6b/svp/inv-25/?hs=false&tok=3g_j… -- (c) 2011, LinkedIn Corporation

1 0