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:  let in GHCI (Henry Lockyer)
   2. Re:  let in GHCI (Henry Lockyer)
   3.  checking file type (without getLine) (MJ Williams)
   4.  correction: hGetLine, not getLine (MJ Williams)
   5. Re:  Averaging a string of numbers (goodman....@gmail.com)
   6. Re:  Pattern matching over functions (Graham Gill)
   7.  Fwd:  Averaging a string of numbers (Ben Kolera)
   8. Re:  Pattern matching over functions (Felipe Almeida Lessa)


----------------------------------------------------------------------

Message: 1
Date: Sun, 11 Dec 2011 18:55:44 +0000
From: Henry Lockyer <henry.lock...@ntlworld.com>
Subject: Re: [Haskell-beginners] let in GHCI
To: dmcbr...@neondsl.com
Cc: Beginners@haskell.org
Message-ID: <e81381a9-e3a0-4c70-bd2b-ff71ec2b2...@ntlworld.com>
Content-Type: text/plain; charset=us-ascii

Thanks a lot David  - that looks like it. 
Searched 'monomorphism' and found some material in the Haskell wiki to read. 
Wasn't galloping senility at least, 
in this case..
Cheers/ Henry

On 11 Dec 2011, at 18:36, David McBride wrote:

> 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
> <henry.lock...@ntlworld.com> 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
>> Beginners@haskell.org
>> http://www.haskell.org/mailman/listinfo/beginners




------------------------------

Message: 2
Date: Sun, 11 Dec 2011 19:11:00 +0000
From: Henry Lockyer <henry.lock...@ntlworld.com>
Subject: Re: [Haskell-beginners] let in GHCI
To: Daniel Fischer <daniel.is.fisc...@googlemail.com>
Cc: beginners@haskell.org
Message-ID: <d9453c00-b28e-4e6e-986e-0be3acde0...@ntlworld.com>
Content-Type: text/plain; charset=us-ascii

That's most helpful Daniel. I see the root of the issue now.
Will digest.
Thanks/ Henry

On 11 Dec 2011, at 18:54, Daniel Fischer wrote:

> 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.




------------------------------

Message: 3
Date: Sun, 11 Dec 2011 19:47:40 +0000
From: MJ Williams <matthewjwilliams...@gmail.com>
Subject: [Haskell-beginners] checking file type (without getLine)
To: beginners@haskell.org
Message-ID: <4ee508dc.0d5ab40a.7806.ffffd...@mx.google.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Hi guys,
When the hSetEncoding is set to utf8, getLine will attempt to read 
each line as belonging to a UTF-8 and when it encounters an error in 
the encoding it throws an exception.  I wonder if there's a way of 
checking for errors without getLine.  I didn't find any function or 
functions in System.IO that might do the job.  is there another 
library that I should be looking at?

Regards
Matthew




------------------------------

Message: 4
Date: Sun, 11 Dec 2011 20:05:02 +0000
From: MJ Williams <matthewjwilliams...@gmail.com>
Subject: [Haskell-beginners] correction: hGetLine, not getLine
To: beginners@haskell.org
Message-ID: <4ee50cee.6463b40a.463a.2...@mx.google.com>
Content-Type: text/plain; charset="us-ascii"; format=flowed

Apologies guys, I meant, hGetLine, not getLine.
Sorry about that.
Regards
Matthew




------------------------------

Message: 5
Date: Sun, 11 Dec 2011 13:37:37 -0800
From: "goodman....@gmail.com" <goodman....@gmail.com>
Subject: Re: [Haskell-beginners] Averaging a string of numbers
To: Brent Yorgey <byor...@seas.upenn.edu>
Cc: beginners@haskell.org
Message-ID:
        <cagxbfao8n56+mk-nex0ijf4qmee-tycfsfk6jzo1tqpqzfz...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Thanks for the reply, Brent!

I have a question about the "later" I referred to:

On Sun, Dec 11, 2011 at 7:19 AM, Brent Yorgey <byor...@seas.upenn.edu> wrote:
> On Sat, Dec 10, 2011 at 07:21:58PM -0800, goodman....@gmail.com wrote:
>> ... later I will add support for other statistics, like
>> max, min, sum, prod, etc.

Specifically, how max and min work with the Monoid implementation.

> 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)

Monoids are new to me, but I just read a bit about them in Real World
Haskell, and what you have makes sense. mempty is the identity
function of Stats, and mappend is the associative binary operator. And
thus far these properties hold true for the definition of Stats. If I
add entries for min and max, it seems like it could still be valid. Of
course, for an empty list of numbers, whereas sum can be 0.0 and len
can be 0, there is no corresponding value for max and min, so I make
them Maybe Double with an initial value of Nothing, and modify your
code as follows:

data Stats = Stats { sm :: Double, mn, mx :: Maybe Double, len :: Int }
             deriving Show

instance Monoid Stats where
  mempty = Stats 0.0 Nothing Nothing 0
  mappend (Stats sm1 mn1 mx1 len1) (Stats sm2 mn2 mx2 len2)
         = Stats (sm1 + sm2) (min mn1 mn2) (max mx1 mx2) (len1 + len2)

mkStats x = Stats x (Just x) (Just x) 1

This compiles and works for max, but min does not work. I tested in ghci, and:

Prelude> min (Just 0.1) (Nothing)
Nothing
Prelude> max (Just 0.1) (Nothing)
Just 0.1

Which explains the problem. Any idea for the solution?

-- 
-Michael Wayne Goodman



------------------------------

Message: 6
Date: Sun, 11 Dec 2011 17:09:25 -0500
From: Graham Gill <math.simp...@gmail.com>
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: Daniel Fischer <daniel.is.fisc...@googlemail.com>
Cc: beginners@haskell.org
Message-ID: <4ee52a15.9050...@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Excellent, thanks Daniel and Felipe.

We don't even need to invoke infinite or undecidable problems, since 
it's easy to construct equal functions for which determining equality 
would be prohibitively expensive. If then you can only check equality 
for some functions, because you want compilation to finish, say, within 
the programmer's lifetime, you lose referential transparency.

Graham

On 11-Dec-2011 1:24 PM, Daniel Fischer wrote:
> 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<byor...@seas.upenn.edu>
> 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: 7
Date: Mon, 12 Dec 2011 08:21:18 +1000
From: Ben Kolera <ben.kol...@gmail.com>
Subject: [Haskell-beginners] Fwd:  Averaging a string of numbers
To: beginners@haskell.org
Message-ID:
        <CAPmqrp-5bA8QmWG=ntpftabdc++33a54phhmdx0f_6-wri9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

That is just because you are calling min and max against the Maybe
rather than on the values inside of your maybes. Max is working
because there is an instance of Ord for Maybe and

Nothing > Just n > Just ( n + 1 )

This is certainly not the most elegant solution ( I am a beginner, too
) but here is what I would do:

instance Monoid Stats where
?mempty ?= Stats 0 Nothing Nothing 0
?mappend (Stats sm1 mn1 mx1 len1) (Stats sm2 mn2 mx2 len2) =
? ?Stats
? ?(sm1 + sm2)
? ?(chooseMaybe min mn1 mn2)
? ?(chooseMaybe max mx1 mx2)
? ?(len1 + len2)

chooseMaybe _ Nothing Nothing ? = Nothing
chooseMaybe _ (Just a) Nothing ?= Just a
chooseMaybe _ Nothing ?(Just b) = Just b
chooseMaybe f (Just a) (Just b) = Just $ f a b


Hopefully this quick answer can get you on your way to solving your
problem and we can both learn a better way of doing it when someone
optimises my solution. ;)


On Mon, Dec 12, 2011 at 7:37 AM, goodman....@gmail.com
<goodman....@gmail.com> wrote:
> Thanks for the reply, Brent!
>
> I have a question about the "later" I referred to:
>
> On Sun, Dec 11, 2011 at 7:19 AM, Brent Yorgey <byor...@seas.upenn.edu> wrote:
>> On Sat, Dec 10, 2011 at 07:21:58PM -0800, goodman....@gmail.com wrote:
>>> ... later I will add support for other statistics, like
>>> max, min, sum, prod, etc.
>
> Specifically, how max and min work with the Monoid implementation.
>
>> 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)
>
> Monoids are new to me, but I just read a bit about them in Real World
> Haskell, and what you have makes sense. mempty is the identity
> function of Stats, and mappend is the associative binary operator. And
> thus far these properties hold true for the definition of Stats. If I
> add entries for min and max, it seems like it could still be valid. Of
> course, for an empty list of numbers, whereas sum can be 0.0 and len
> can be 0, there is no corresponding value for max and min, so I make
> them Maybe Double with an initial value of Nothing, and modify your
> code as follows:
>
> data Stats = Stats { sm :: Double, mn, mx :: Maybe Double, len :: Int }
> ? ? ? ? ? ? deriving Show
>
> instance Monoid Stats where
> ?mempty = Stats 0.0 Nothing Nothing 0
> ?mappend (Stats sm1 mn1 mx1 len1) (Stats sm2 mn2 mx2 len2)
> ? ? ? ? = Stats (sm1 + sm2) (min mn1 mn2) (max mx1 mx2) (len1 + len2)
>
> mkStats x = Stats x (Just x) (Just x) 1
>
> This compiles and works for max, but min does not work. I tested in ghci, and:
>
> Prelude> min (Just 0.1) (Nothing)
> Nothing
> Prelude> max (Just 0.1) (Nothing)
> Just 0.1
>
> Which explains the problem. Any idea for the solution?
>
> --
> -Michael Wayne Goodman
>
> _______________________________________________
> Beginners mailing list
> Beginners@haskell.org
> http://www.haskell.org/mailman/listinfo/beginners



------------------------------

Message: 8
Date: Sun, 11 Dec 2011 23:27:01 -0200
From: Felipe Almeida Lessa <felipe.le...@gmail.com>
Subject: Re: [Haskell-beginners] Pattern matching over functions
To: simplex.math.servi...@gmail.com
Cc: beginners@haskell.org, Daniel Fischer
        <daniel.is.fisc...@googlemail.com>
Message-ID:
        <CANd=ogepyk-dlbx6j+5fm_+7ts6txcvgxmdu2hksp_jd9gv...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

On Sun, Dec 11, 2011 at 8:09 PM, Graham Gill <math.simp...@gmail.com> wrote:
> Excellent, thanks Daniel and Felipe.
>
> We don't even need to invoke infinite or undecidable problems, since it's
> easy to construct equal functions for which determining equality would be
> prohibitively expensive. If then you can only check equality for some
> functions, because you want compilation to finish, say, within the
> programmer's lifetime, you lose referential transparency.

Note that the time isn't spent on compilation time, but on run time!
Which is actually worse ;-).

Also note that it is possible to imagine something like

  obviouslyEqual :: a -> a -> Bool

where 'obviouslyEqual x y' is 'True' when it's easy to see that they
are equal or 'False' if you can't decide.  Actually, with GHC you may
say

  {-# LANGUAGE MagicHash #-}

  import GHC.Exts

  obviouslyEqual :: a -> a -> Bool
  obviouslyEqual a b =
    case I# (reallyUnsafePtrEquality# a b) of
      0 -> False
      _ -> True

However, this functions is *not* referentially transparent (exercise:
show an example of how obviouslyEqual breaks referential
transparency).  reallyUnsafePtrEquality# is really unsafe for a reason
=).

Cheers,

-- 
Felipe.



------------------------------

_______________________________________________
Beginners mailing list
Beginners@haskell.org
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 42, Issue 14
*****************************************

Reply via email to