Send Beginners mailing list submissions to beginners@haskell.org To subscribe or unsubscribe via the World Wide Web, visit http://www.haskell.org/mailman/listinfo/beginners or, via email, send a message with subject or body 'help' to beginners-requ...@haskell.org
You can reach the person managing the list at beginners-ow...@haskell.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Beginners digest..." Today's Topics: 1. Re: function - argument termination problem (Chadda? Fouch?) 2. Identical function and variable names and type inference (aditya siram) 3. Re: Identical function and variable names and type inference (Antoine Latter) 4. Re: Identical function and variable names and type inference (Thomas Davie) 5. Re: Identical function and variable names and type inference (Daniel Fischer) 6. Re: Identical function and variable names and type inference (Magnus Therning) 7. Help with CSV (Hong Yang) 8. Re: Figuring out errors (Sterling Clover) ---------------------------------------------------------------------- Message: 1 Date: Wed, 2 Sep 2009 20:46:35 +0200 From: Chadda? Fouch? <chaddai.fou...@gmail.com> Subject: Re: [Haskell-beginners] function - argument termination problem To: Magnus Therning <mag...@therning.org> Cc: beginners@haskell.org Message-ID: <e9350eaf0909021146l5c710a63se2585b2c742a5...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 2009/9/2 Magnus Therning <mag...@therning.org>: >> Is it possible to implement in haskell a function f (A) such that if A >> does not ever terminate then f always terminates, and if A always >> terminates then f does not ever terminate? >> >> Thanks in advance :-), > > Isn't this the halting problem? It is, since to ensure that f terminates and evaluates to a given value for every A that do not terminate it must be able to determine that it don't terminate in finite time, thus solving the halting problem. In other words this can't be written in Haskell and a fortiori can't be written on a computer in any language. -- Jedaï ------------------------------ Message: 2 Date: Wed, 2 Sep 2009 16:24:46 -0500 From: aditya siram <aditya.si...@gmail.com> Subject: [Haskell-beginners] Identical function and variable names and type inference To: beginners <beginners@haskell.org> Message-ID: <594f78210909021424j75e5407evb451d3a508d3a...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi all, Recently I wrote a function that takes a unique identifier that I called 'id'. I then tried to apply the 'id' function to it and GHC did not like that. But it should. For example in 'test' I have told the compiler that the id argument is an Int. So type inference should be able to determine the first 'id' in 'id id' couldn't possibly be an Int, but it complains. So I explicitly told the compiler the type of 'id' in test1 - this didn't work either. The final function 'test3' works as expected. Is there something I am not understand about the way type inference is supposed to work? test :: Int -> Int test id = id id test1 :: Int -> Int test1 id = idFunc id where idFunc :: a -> a idFunc = id test2 :: Int -> Int test2 m...@id = id myid test3 :: Int -> Int test3 id = Prelude.id id thanks ... -deech -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/beginners/attachments/20090902/b6ce09e2/attachment-0001.html ------------------------------ Message: 3 Date: Wed, 2 Sep 2009 16:30:55 -0500 From: Antoine Latter <aslat...@gmail.com> Subject: Re: [Haskell-beginners] Identical function and variable names and type inference To: aditya siram <aditya.si...@gmail.com> Cc: beginners <beginners@haskell.org> Message-ID: <694519c50909021430l52b286fep4c3c7184c2503...@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 2, 2009 at 4:24 PM, aditya siram<aditya.si...@gmail.com> wrote: > Hi all, > Recently I wrote a function that takes a unique identifier that I called > 'id'. I then tried to apply the 'id' function to it and GHC did not like > that. But it should. > > For example in 'test' I have told the compiler that the id argument is an > Int. So type inference should be able to determine the first 'id' in 'id id' > couldn't possibly be an Int, but it complains. So I explicitly told the > compiler the type of 'id' in test1 - this didn't work either. The final > function 'test3' works as expected. Is there something I am not understand > about the way type inference is supposed to work? > > test :: Int -> Int > test id = id id > Type inference plays no role in figuring out what your identifiers refer to. In the body of your function, the only identifier named "id" that's in scope is the argument to the function. There's a compiler warning for GHC you can use to be warned we you introduce identifiers which "shadow" existing identifiers, like in your function. Does my explanation make sense? Antoine ------------------------------ Message: 4 Date: Wed, 2 Sep 2009 23:33:08 +0200 From: Thomas Davie <tom.da...@gmail.com> Subject: Re: [Haskell-beginners] Identical function and variable names and type inference To: aditya siram <aditya.si...@gmail.com> Cc: beginners <beginners@haskell.org> Message-ID: <e803e110-2e74-4802-af3a-faf1f3315...@gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Ints can't make up the function part of an application, that must have type (a -> b). In the mean time, the reason it didn't accept test id = id id is because it must fix the argument id to only one type. It infers that id must have type (a -> b), from the fact that it appears in the function position, then sees it in the argument position, and infers that a = (a -> b) which obviously causes a problem. To resolve that problem, you need rank-2 polymorphism. Bob On 2 Sep 2009, at 23:24, aditya siram wrote: > Hi all, > Recently I wrote a function that takes a unique identifier that I > called 'id'. I then tried to apply the 'id' function to it and GHC > did not like that. But it should. > > For example in 'test' I have told the compiler that the id argument > is an Int. So type inference should be able to determine the first > 'id' in 'id id' couldn't possibly be an Int, but it complains. So I > explicitly told the compiler the type of 'id' in test1 - this didn't > work either. The final function 'test3' works as expected. Is there > something I am not understand about the way type inference is > supposed to work? > > test :: Int -> Int > test id = id id > > test1 :: Int -> Int > test1 id = idFunc id > where > idFunc :: a -> a > idFunc = id > > test2 :: Int -> Int > test2 m...@id = id myid > > test3 :: Int -> Int > test3 id = Prelude.id id > > thanks ... > -deech > > _______________________________________________ > Beginners mailing list > Beginners@haskell.org > http://www.haskell.org/mailman/listinfo/beginners ------------------------------ Message: 5 Date: Wed, 2 Sep 2009 23:37:58 +0200 From: Daniel Fischer <daniel.is.fisc...@web.de> Subject: Re: [Haskell-beginners] Identical function and variable names and type inference To: beginners@haskell.org Message-ID: <200909022337.59114.daniel.is.fisc...@web.de> Content-Type: text/plain; charset="iso-8859-15" Am Mittwoch 02 September 2009 23:24:46 schrieb aditya siram: > Hi all, > Recently I wrote a function that takes a unique identifier that I called > 'id'. I then tried to apply the 'id' function to it and GHC did not like > that. But it should. > > For example in 'test' I have told the compiler that the id argument is an > Int. So type inference should be able to determine the first 'id' in 'id > id' couldn't possibly be an Int, but it complains. So I explicitly told the > compiler the type of 'id' in test1 - this didn't work either. The final > function 'test3' works as expected. Is there something I am not understand > about the way type inference is supposed to work? > > test :: Int -> Int > test id = id id > > test1 :: Int -> Int > test1 id = idFunc id > where > idFunc :: a -> a > idFunc = id > > test2 :: Int -> Int > test2 m...@id = id myid > > test3 :: Int -> Int > test3 id = Prelude.id id > > thanks ... > -deech It's not type inference, it's scoping. By calling the function's parameter id, you shadow the name id, so within that scope each (unqualified) mention of the name id refers to the function's parameter. In test3, you use the qualified name Prelude.id, thus tell the compiler that it's not the parameter you want but the identity function. ------------------------------ Message: 6 Date: Wed, 2 Sep 2009 23:42:45 +0200 From: Magnus Therning <mag...@therning.org> Subject: Re: [Haskell-beginners] Identical function and variable names and type inference To: aditya siram <aditya.si...@gmail.com> Cc: beginners <beginners@haskell.org> Message-ID: <e040b520909021442q2e20e77em8ee312a9a39b9...@mail.gmail.com> Content-Type: text/plain; charset=UTF-8 On Wed, Sep 2, 2009 at 11:24 PM, aditya siram<aditya.si...@gmail.com> wrote: > Hi all, > Recently I wrote a function that takes a unique identifier that I called > 'id'. I then tried to apply the 'id' function to it and GHC did not like > that. But it should. > > For example in 'test' I have told the compiler that the id argument is an > Int. So type inference should be able to determine the first 'id' in 'id id' > couldn't possibly be an Int, but it complains. So I explicitly told the > compiler the type of 'id' in test1 - this didn't work either. The final > function 'test3' works as expected. Is there something I am not understand > about the way type inference is supposed to work? > > test :: Int -> Int > test id = id id > > test1 :: Int -> Int > test1 id = idFunc id >    where >      idFunc :: a -> a >      idFunc = id > > test2 :: Int -> Int > test2 m...@id = id myid > > test3 :: Int -> Int > test3 id = Prelude.id id How is the compiler supposed to differentiate between the situation where you really mean `id id` (and it type checks properly) and where you've mistakenly written `id id` (but it doesn't type check)? If that doesn't make you realise then think of it as your `id` shadowing the Prelude's, and that happens irrespective of the types. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnusï¼ therningï¼org Jabber: magnusï¼ therningï¼org http://therning.org/magnus identi.ca|twitter: magthe ------------------------------ Message: 7 Date: Wed, 2 Sep 2009 17:40:38 -0500 From: Hong Yang <hyang...@gmail.com> Subject: [Haskell-beginners] Help with CSV To: beginners@haskell.org Message-ID: <f31db34d0909021540q7c862926mb9f308440462c...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" I need to process csv files that have the characteristics as follows: 1) each file has thousands of columns which have String, Int, and Double types 2) the number of columns may change 3) for those columns whose name do not change, their location may change I want to process some columns in 3) using Haskell. In Perl, I can easily have the code like below: use Text::CSV; my $csv = Text::CSV->new( { allow_whitespace => 1 } ); open my $temp, "<", "temp.csv" or die "Cannot open temp.csv! ($!)"; my @fields = @{ $csv->getline($temp) }; $csv->column_names(@fields); while ( my $hr = $csv->getline_hr($temp) ) { my $sn = $hr->{"UNIT:unitSerialNumber"}; # processing goes here ... } close $temp; Can someone please give me an equivalent code in Haskell? Then I can digest and expand it. Thanks, Hong -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/beginners/attachments/20090902/0efd9ff1/attachment-0001.html ------------------------------ Message: 8 Date: Wed, 2 Sep 2009 19:15:45 -0400 From: Sterling Clover <s.clo...@gmail.com> Subject: Re: [Haskell-beginners] Figuring out errors To: Edward Z.Yang <ezy...@mit.edu> Cc: beginners <beginners@haskell.org> Message-ID: <321dd7e6-b987-4965-a4dd-e4a4f5ec2...@gmail.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Aug 31, 2009, at 11:02 PM, Edward Z. Yang wrote: > Hello all, > > I've been looking at [1] and trying to make tops and bottoms > (pardon the pun) of error handling in Haskell. I am still > uncertain of what to do. The problem, I think, is that it really depends on the situation. One also should distinguish between errors and exceptions -- errors being when the program/programmer is faulty, and exceptions being signals of expected conditions. The choice is really about when you want to always continue, what the appropriate level to test for failure is, and what to do on various exceptional conditions. I tend to think that pure functions should always return pure results, and error calls should be reserved for labeling actual error situations (i.e. code paths that should never be taken). Then when you want to assert that the result will never occur, you can write a mayToError (i.e. a labeled fromJust) or eitherToError function. Either String should of course not be used to represent a range of string exceptions, but should be thought of as returning a single exception (i.e. "Unable to Parse") with accompanying explanatory text. If you need to make sure that a pure value in IO doesn't contain either an error or a bottom, I would suggest using evaluate and rnf judiciously, both of which are important to understand, not just for error handling, but also for performance. Cheers, S. > I recognize that there are different areas of code that > may have different requirements for errors: > > * Pure code that is simple enough can probably get away > with returning Maybe a > > * Pure code that has multiple failure modes (the canonical > example is parsing) should return a Either e a. The type > of e is a little difficult: many standard libraries seem > to use String, but coming from Python this seems analogous > to the long deprecated "string exceptions", which are quick > and easy but not long-term maintainable due to lack of an > easy way to match for them. This leads naturally into > Either MyError, which is supported using throwError and > catchError. > > * However, [1] specifically warns against using this technique > in the IO monad, and I need a way to short circuit execution > when a crucial pure operation fails (in Python, this would have just > been an uncaught exception). This suggests using ErrorT on > IO, however, [1] also claims that this is generally not a good > idea, and suggests to use throwDyn (which actually looks like > it's been renamed to throw) > > * Unfortunately, when I've tried to use this technique, I've > run up against the fact that throw is implemented using bottom, > so if I do a throw in a pure function, the exception might > not actually surface up until I'm, say, attempting to print > its return value to IO. Denizens on #haskell have instructed > me to treat bottom as the bane of existence and opt for > stacking ErrorT on IO (it would be nice to know if this was > a good idea or bad idea) > > At which point, I am most thoroughly confused. Pointers, please! > > Cheers, > Edward > > [1] http://www.randomhacks.net/articles/2007/03/10/haskell-8-ways- > to-report-errors > _______________________________________________ > Beginners mailing list > Beginners@haskell.org > http://www.haskell.org/mailman/listinfo/beginners ------------------------------ _______________________________________________ Beginners mailing list Beginners@haskell.org http://www.haskell.org/mailman/listinfo/beginners End of Beginners Digest, Vol 15, Issue 2 ****************************************