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: Installing regex-pcre (revisited) (Stephen Tetley)
2. Re: Averaging a string of numbers (Brent Yorgey)
3. Re: Pattern matching over functions (Graham Gill)
4. let in GHCI (Henry Lockyer)
5. Re: Pattern matching over functions (Daniel Fischer)
6. Re: Pattern matching over functions (Felipe Almeida Lessa)
7. Re: let in GHCI (David McBride)
8. Re: let in GHCI (Daniel Fischer)
----------------------------------------------------------------------
Message: 1
Date: Sun, 11 Dec 2011 12:11:51 +0000
From: Stephen Tetley <[email protected]>
Subject: Re: [Haskell-beginners] Installing regex-pcre (revisited)
Cc: [email protected]
Message-ID:
<cab2tpraopurzshe08ipakaacrsowqiz1fmg+vymjqz7kw7l...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On 11 December 2011 08:41, Asokan Pichai <[email protected]> wrote:
> The OP's question is for a Unix-like environment on Windows; which
> is Cygwin.
Indeed (and also MSYS), but the OP wants especially to work with PCRE
and the Haskell bindings to it are unlikely to work directly with
Cygwin, but they should with MinGW / MSYS.
>
>>
>> The reason for this is basically that everyone else does. Linking
>> static libraries is a bit different internally to Cygwin and it does
>> not seem to "just work" whereas it usually does on MinGW provided you
>> have the C library already working.
>
> I do not understand this part.
Yes - it wasn't at all clear.
FFI bindings (in Haskell) link to C static libraries - *.a files on
Cygwin or MSYS (plus headers are needed during compilation).
There are differences between Cygwin and MSYS *.a files, I know little
about what the differences are but I know that the consequence is
linking to Cygwin libs doesn't work seemlessly with GHC[*]. Maybe it
wouldn't be much work to get GHC working with Cygwin libs but no-one
appears to have done it and documented their success, hence "everyone"
uses MSYS where things are already working.
[*] GHC actually ships with build tools from MinGW / MSYS, but once
you start working with FFI bindings you really want a proper
installation of MSYS.
------------------------------
Message: 2
Date: Sun, 11 Dec 2011 10:19:05 -0500
From: Brent Yorgey <[email protected]>
Subject: Re: [Haskell-beginners] Averaging a string of numbers
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Sat, Dec 10, 2011 at 07:21:58PM -0800, [email protected] wrote:
> Hi beginners list,
>
> I want to take a string of numbers and return the average. It is a
> string because I expect the input to be from STDIN or a file. I would
> like it to handle infinite lists. Further, I create the Stats data
> structure because later I will add support for other statistics, like
> max, min, sum, prod, etc. The following code works, but I'm not sure
> it's the proper way to do things in Haskell. For instance, maybe I
> could use a fold method instead of the explicit recursion in
> getStats?
You could indeed implement getStats with a fold, but we can even do
one better.
> -- avg.hs
> -- sm is sum, len is number of elements
> data Stats = Stats { sm :: Double, len :: Int } deriving Show
Let's add a Monoid instance for Stats, which specifies how two Stats
objects should be combined:
instance Monoid Stats where
mempty = Stats 0 0
mappend (Stats sm1 len1) (Stats sm2 len2) = Stats (sm1 + sm2) (len1 + len2)
We also specify how to create a default Stats object:
mkStats x = Stats x 1
Now getStats is simply:
getStats :: [Double] -> Stats
getStats = mconcat . map mkStats
That is, create a default Stats object from each list element, then
combine/summarize them all using the Monoid instance.
Other than that your code looks good to me.
-Brent
------------------------------
Message: 3
Date: Sun, 11 Dec 2011 13:07:06 -0500
From: Graham Gill <[email protected]>
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: Ken KAWAMOTO <[email protected]>
Cc: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 10-Dec-2011 11:17 AM, Ken KAWAMOTO wrote:
> On Thu, Dec 8, 2011 at 3:14 PM, Brent Yorgey<[email protected]> wrote:
>> On Wed, Dec 07, 2011 at 06:10:01PM +0100, Giacomo Tesio wrote:
>>> I would find already very useful a compiler that is able to understand id f
>>> = f, that (\x -> 3 + x) == (\y = 3 + y) == (+3) even if it isn't able to
>>> see that (+3) == (\x -> 2 + 1 + x).
>> But then we would lose referential transparency.
> As I understand, this would be against lazy evaluation since it would
> request to evaluate expressions in lambda, but I don't see how this
> relates to referential transparency.
> Can you elaborate this a little bit?
I second the question. From what I understand referential transparency
means that an expression can be replaced by its value with no change to
program semantics, or equivalently that a function always produces the
same result/behaviour given the same input. How does determining whether
two (pure) functions are equivalent break referential transparency?
cheers!
Graham
>
> Thanks,
> Ken
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 4
Date: Sun, 11 Dec 2011 18:14:56 +0000
From: Henry Lockyer <[email protected]>
Subject: [Haskell-beginners] let in GHCI
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Hello Haskellers
Why is it that in GHCI I can do, for example,
> replicate 6 5
[5,5,5,5,5,5]
> let my6 = replicate 6
> my6 5
[5,5,5,5,5,5]
but if I do
> sort "bav"
"abv"
this is ok, but
> let mySort = sort
> mySort "bav"
<interactive>:1:8:
Couldn't match expected type `()' with actual type `Char'
Expected type: [()]
Actual type: [Char]
In the first argument of `mySort', namely `"bav"'
In the expression: mySort "bav"
and/or
> mySort [6,5,9]
<interactive>:1:13:
No instance for (Num ())
arising from the literal `9'
Possible fix: add an instance declaration for (Num ())
In the expression: 9
In the first argument of `mySort', namely `[6, 5, 9]'
In the expression: mySort [6, 5, 9]
This is eluding me at the moment..! ;-)
/ Henry
------------------------------
Message: 5
Date: Sun, 11 Dec 2011 19:24:45 +0100
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: [email protected]
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset="iso-8859-1"
On Sunday 11 December 2011, 19:07:06, Graham Gill wrote:
> On 10-Dec-2011 11:17 AM, Ken KAWAMOTO wrote:
> > On Thu, Dec 8, 2011 at 3:14 PM, Brent Yorgey<[email protected]>
wrote:
> >> On Wed, Dec 07, 2011 at 06:10:01PM +0100, Giacomo Tesio wrote:
> >>> I would find already very useful a compiler that is able to
> >>> understand id f = f, that (\x -> 3 + x) == (\y = 3 + y) == (+3)
> >>> even if it isn't able to see that (+3) == (\x -> 2 + 1 + x).
> >>
> >> But then we would lose referential transparency.
> >
> > As I understand, this would be against lazy evaluation since it would
> > request to evaluate expressions in lambda, but I don't see how this
> > relates to referential transparency.
> > Can you elaborate this a little bit?
>
> I second the question. From what I understand referential transparency
> means that an expression can be replaced by its value with no change to
> program semantics, or equivalently that a function always produces the
> same result/behaviour given the same input. How does determining whether
> two (pure) functions are equivalent break referential transparency?
I think if it were possible to find out whether two functions are the same
for *every* pair of two functions, it wouldn't violate referential
transparency.
But it's not possible, so all you have is that for some pairs of functions
equality can be proved, for some pairs it can be disproved and for some
pairs, it cannot be decided.
So
foo f g = if canProveEqual f g then "Yay :)" else "Nay :("
wouldn't be referentially transparent,
foo (+3) (\x -> x+3) = "Yay :)"
foo (+3) somethingWhichIsTheSameButCan'tBeProvedToBe = "Nay :("
------------------------------
Message: 6
Date: Sun, 11 Dec 2011 16:26:16 -0200
From: Felipe Almeida Lessa <[email protected]>
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: Graham Gill <[email protected]>
Cc: [email protected]
Message-ID:
<CANd=OGGCjbRE=BC=waywbhlra8ojfwqgbs3_pmsg-nsddd0...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
On Sun, Dec 11, 2011 at 4:07 PM, Graham Gill <[email protected]> wrote:
> I second the question. From what I understand referential transparency means
> that an expression can be replaced by its value with no change to program
> semantics, or equivalently that a function always produces the same
> result/behaviour given the same input. How does determining whether two
> (pure) functions are equivalent break referential transparency?
It doesn't. Whoever it also isn't guaranteed to terminate.
What *does* break referential transparency is a function equality that
works sometimes, but not other.
Cheers,
--
Felipe.
------------------------------
Message: 7
Date: Sun, 11 Dec 2011 13:36:27 -0500
From: David McBride <[email protected]>
Subject: Re: [Haskell-beginners] let in GHCI
To: Henry Lockyer <[email protected]>
Cc: [email protected]
Message-ID:
<can+tr40h3uk2wag1p7wy8znvo+n72qhxhv8bebcg6ako++_...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
I don't understand it perse, but I've run into it often enough to say
that the problem is the monomorphism restriction. When you say let
mySort = sort, instead of having the type
mySort :: Ord a => [a] -> [a]
which is what you'd expect, instead there is some bizarre rule in the
haskell spec that says it has to choose () for a in this case so if
you look at the type after you define it in ghci, you'll see the type
is actually
mySort :: [()] -> [()]
which is completely useless for anything. If you go :set
-XNoMonomorphismRestriction in ghci, you'll get the correct type and
it will work the way you intend. There is apparently some obscure
case where this is desirable and that is the only reason it has not
been removed by default.
On Sun, Dec 11, 2011 at 1:14 PM, Henry Lockyer
<[email protected]> wrote:
> Hello Haskellers
>
> Why is it that in GHCI I can do, for example,
>
>> replicate 6 5
> [5,5,5,5,5,5]
>> let my6 = replicate 6
>> my6 5
> [5,5,5,5,5,5]
>
> but if I do
>
>> sort "bav"
> "abv"
>
> this is ok, but
>
>> let mySort = sort
>> mySort "bav"
>
> <interactive>:1:8:
> ? ?Couldn't match expected type `()' with actual type `Char'
> ? ?Expected type: [()]
> ? ? ?Actual type: [Char]
> ? ?In the first argument of `mySort', namely `"bav"'
> ? ?In the expression: mySort "bav"
>
> and/or
>
>> mySort [6,5,9]
>
> <interactive>:1:13:
> ? ?No instance for (Num ())
> ? ? ?arising from the literal `9'
> ? ?Possible fix: add an instance declaration for (Num ())
> ? ?In the expression: 9
> ? ?In the first argument of `mySort', namely `[6, 5, 9]'
> ? ?In the expression: mySort [6, 5, 9]
>
> This is eluding me at the moment..! ?;-)
>
> / Henry
>
>
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
------------------------------
Message: 8
Date: Sun, 11 Dec 2011 19:54:37 +0100
From: Daniel Fischer <[email protected]>
Subject: Re: [Haskell-beginners] let in GHCI
To: [email protected]
Message-ID: <[email protected]>
Content-Type: Text/Plain; charset="iso-8859-1"
On Sunday 11 December 2011, 19:14:56, Henry Lockyer wrote:
> Hello Haskellers
>
> Why is it that in GHCI I can do, for example,
>
> > let my6 = replicate 6
> > my6 5
>
> [5,5,5,5,5,5]
>
> but if I do
>
> > sort "bav"
>
> "abv"
>
> this is ok, but
>
> > let mySort = sort
It's the monomorphism restriction.
If a value is bound by a simple pattern binding (let val = whatever)
without a type signature, and if the inferred type is constrained by some
class requirements, the value gets a monomorphic type, any constrained type
variables are resolved according to the defaulting rules in
http://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4
The first example has no constrained type variables,
replicate :: Int -> a -> [a]
so
my6 :: a -> [a]
is parametric, it works the same for all types. Therefore it remains
polymorphic.
But
sort :: Ord a => [a] -> [a]
has a constrained type variable, so a value bound like
let mySort = sort
gets a monomorphic type, the constrained type variable a is replaced with a
fixed type according to defaulting rules.
Since the defaulting rules in the linked section require one of the
constraining classes to be a numeric class, that binding should be a static
error by these rules.
However, strict adherence to the defaulting rules would produce a *lot* of
type errors at the ghci prompt, so ghci has extended defaulting rules,
resolving more cases, for example, Show, Eq and Ord constraints (with no
numeric constraint around) are satisfied by instantiating the constrained
type variable with ().
Thus the binding
> let mySort = sort
at the ghci prompt results in
> :t mySort
mySort :: [()] -> [()]
You get the inferred (most general) type if you
1) bind the value with a function binding (one with at least one argument
before the =),
> let mySort xs = sort xs
2) give a polymorphic type signature
> let mySort :: Ord a => [a] -> [a]; mySort = sort
3) disable the monomorphism restriction
> :set -XNoMonomorphismRestriction
> let mySort = sort
It's often a good idea to disable the monomorphism restriction at the ghci
prompt by default, so you might consider doing that in your .ghci file.
If the monomorphism restriction so often leads to surprising and confusing
results, why does it exist at all?
Because without it, there'd be another surprising and unpleasant result.
If you have something that looks like a constant,
name = value
you'd likely expect it to be evaluated only once. But if name got a
polymorphic type, it would have to be re-evaluated for every use.
To avoid the unpleasant surprise of bad performance due to re-evaluation,
we have the monomorphism restriction.
If you give it a polymorphic signature ore bind it via a function binding,
it's obvious that the value isn't shared and has to be recalculated.
Is that a sufficiently good reason to have the MR?
Opinions differ.
------------------------------
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
End of Beginners Digest, Vol 42, Issue 13
*****************************************
