Send Beginners mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
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? <[email protected]>
Subject: Re: [Haskell-beginners] function - argument termination
problem
To: Magnus Therning <[email protected]>
Cc: [email protected]
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
2009/9/2 Magnus Therning <[email protected]>:
>> 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 <[email protected]>
Subject: [Haskell-beginners] Identical function and variable names and
type inference
To: beginners <[email protected]>
Message-ID:
<[email protected]>
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 <[email protected]>
Subject: Re: [Haskell-beginners] Identical function and variable names
and type inference
To: aditya siram <[email protected]>
Cc: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Sep 2, 2009 at 4:24 PM, aditya siram<[email protected]> 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 <[email protected]>
Subject: Re: [Haskell-beginners] Identical function and variable names
and type inference
To: aditya siram <[email protected]>
Cc: beginners <[email protected]>
Message-ID: <[email protected]>
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
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 5
Date: Wed, 2 Sep 2009 23:37:58 +0200
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] Identical function and variable names
and type inference
To: [email protected]
Message-ID: <[email protected]>
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 <[email protected]>
Subject: Re: [Haskell-beginners] Identical function and variable names
and type inference
To: aditya siram <[email protected]>
Cc: beginners <[email protected]>
Message-ID:
<[email protected]>
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 2, 2009 at 11:24 PM, aditya siram<[email protected]> 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 <[email protected]>
Subject: [Haskell-beginners] Help with CSV
To: [email protected]
Message-ID:
<[email protected]>
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 <[email protected]>
Subject: Re: [Haskell-beginners] Figuring out errors
To: Edward Z.Yang <[email protected]>
Cc: beginners <[email protected]>
Message-ID: <[email protected]>
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
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 15, Issue 2
****************************************
