Send Beginners mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://mail.haskell.org/cgi-bin/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: testing IO code
(Sumit Sahrawat, Maths & Computing, IIT (BHU))
2. Re: Equivalent of IO Monad in other functional languages?
(Sumit Sahrawat, Maths & Computing, IIT (BHU))
3. Re: Equivalent of IO Monad in other functional languages?
(Sumit Sahrawat, Maths & Computing, IIT (BHU))
----------------------------------------------------------------------
Message: 1
Date: Mon, 16 Mar 2015 20:10:35 +0530
From: "Sumit Sahrawat, Maths & Computing, IIT (BHU)"
<[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>,
Haskell-cafe Cafe <[email protected]>
Subject: Re: [Haskell-beginners] testing IO code
Message-ID:
<cajbew8mjj1mm5emeswjgfkxs0xwuu98f_xrgmuf9erjavds...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
On 16 March 2015 at 19:51, Maurizio Vitale <[email protected]> wrote:
> suppose I have a restricted IO monad, RIO that only exposes readFile.
> and then I have a monad SIO that will eventually provide a virtual file
> system from a map path->content, also with a readFile function returning
> SIO(String).
>
> What is the way to write a function parseFile that can operate in both
> monads so that I can use SIO for testing? should I define a third monad
> CompileMonad that has instances for both RIO and SIO and then having
> parseFile :: CompileMonad ast?
>
You might be able to do something like,
class MonadIO m => ProvidesReadFile m where
readFile :: FilePath -> m String
instance ProvidesReadFile RIO where
readFile = readFileRIO -- the RIO specific readFile
instance ProvidesReadFile SIO where
readFile = readFileSIO -- the SIO specific readFile
parseFile :: ProvidesReadFile m => FilePath -> m ast
parseFile = do
f <- readFile
let ast = parse f -- the pure parser
return ast -- works for both monads
> Thanks,
>
> Maurizio
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
>
This is more suitable for the haskell-cafe. I am posting it there so that
more people might comment on it.
HTH.
--
Regards
Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150316/9545df39/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 16 Mar 2015 20:28:27 +0530
From: "Sumit Sahrawat, Maths & Computing, IIT (BHU)"
<[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Equivalent of IO Monad in other
functional languages?
Message-ID:
<cajbew8mocg1yr4f7ywjfm4ljpgrsdugqg_prbacjfueobch...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Sorry for having strayed towards a different path. I'll try to answer only
your question this time :)
An example from [1], for SML (bottom of the page) shows a function, with
the following type signature in haskell
copyTextFile :: String -> String
One cannot write such a function in haskell that does the same thing
because the example uses IO within a function with a pure looking type.
I'm sure people experienced with other functional languages will have good
examples, so I'll leave it to them.
To answer your second question, I'm still not sure :).
I was just relaying how I understood purity, so that somebody might also
correct me if I'm wrong.
Summarizing the discussion above, a function is pure if it gives the same
output for the same input. Now a function returning 'IO a' always returns
the same IO instructions (these instructions might be impure), but the
function (by the virtue of always returning the same output for the same
inputs) is ultimately pure. Frerich has also raised an important point that
an IO computation might actually depend on some random file, which breaks
this pattern.
[1]: http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec09.html
On 16 March 2015 at 20:15, Simon Kitching <[email protected]> wrote:
> On 03/16/2015 03:04 PM, Heinrich Apfelmus wrote:
>
>> Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
>>
>>> On 15 March 2015 at 23:19, <[email protected]> wrote:
>>>
>>> From that perspective isn't every language pure? Haskell's still got
>>>> "randomIO" and "print <=< readMVar"
>>>>
>>>
>>> Haskell is impure only when you use the unsafe* functions (atleast that's
>>> how I understand purity).
>>>
>>> My understanding is that a language is impure if it allows one to write
>>> arbitrary IO within a function and still give it a proper (mathematical)
>>> function type. In other words impurity arises only if you can unwrap the
>>> IO
>>> monad (which is what the unsafe functions do).
>>>
>>> The two examples you give above are pure under such a perspective, but I
>>> might be wrong.
>>>
>>
>> You're right, indeed. A language is pure if supplying a value `x` of type
>> `A` to the a function
>>
>> A -> B
>>
>> will always returns the same result, no matter how often or in which
>> order this function is called. This is true for both
>>
>> randomIO :: Random a => IO a
>> (readMVar >=> print) :: Show a => MVar a -> IO ()
>>
>> because they return an IO action. This action will always be the same
>> given the same arguments.
>>
>> The language would be impure if these functions had the types
>>
>> randomIO :: Random a => a
>> (readMVar >=> print) :: Show a => MVar a -> ()
>>
>
> Doesn't "pure" correspond to "can write a unit test for"? When a
> function's return value only ever depends on its inputs, then I can
> write a set of test-cases for various inputs, and assert that the
> return-value has the expected content.
>
> A function that reads from a file, stdin, etc. cannot be tested in the
> same way; I cannot _assert_ that the returned value has specific content.
>
> Sumit stated earlier that IO is "a pure program that can be executed",
> which seems similar to your description above (which I admit I
> don't yet 100% understand). How can I "assert" anything about this
> "program", or make a Haskell-based application 'safer' in any way by
> leveraging this kind of 'purity'?
>
> Thanks,
> Simon
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
--
Regards
Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150316/6311bfc6/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 16 Mar 2015 20:31:06 +0530
From: "Sumit Sahrawat, Maths & Computing, IIT (BHU)"
<[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] Equivalent of IO Monad in other
functional languages?
Message-ID:
<CAJbEW8Ma4WEL-=hcve5dwb8e-qyv8rsxtvzq2e5dnz_ogbt...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Frerich, the function would still be pure, even if it returns a poisoned
recipe as you say. Thus, a little thought leads me to believe that the
pattern would still not break if no unsafe* functions are used.
On 16 March 2015 at 20:28, Sumit Sahrawat, Maths & Computing, IIT (BHU) <
[email protected]> wrote:
> Sorry for having strayed towards a different path. I'll try to answer only
> your question this time :)
>
> An example from [1], for SML (bottom of the page) shows a function, with
> the following type signature in haskell
>
> copyTextFile :: String -> String
>
> One cannot write such a function in haskell that does the same thing
> because the example uses IO within a function with a pure looking type.
>
> I'm sure people experienced with other functional languages will have good
> examples, so I'll leave it to them.
>
> To answer your second question, I'm still not sure :).
> I was just relaying how I understood purity, so that somebody might also
> correct me if I'm wrong.
>
> Summarizing the discussion above, a function is pure if it gives the same
> output for the same input. Now a function returning 'IO a' always returns
> the same IO instructions (these instructions might be impure), but the
> function (by the virtue of always returning the same output for the same
> inputs) is ultimately pure. Frerich has also raised an important point that
> an IO computation might actually depend on some random file, which breaks
> this pattern.
>
> [1]: http://www.cs.cornell.edu/courses/cs312/2006fa/recitations/rec09.html
>
> On 16 March 2015 at 20:15, Simon Kitching <[email protected]> wrote:
>
>> On 03/16/2015 03:04 PM, Heinrich Apfelmus wrote:
>>
>>> Sumit Sahrawat, Maths & Computing, IIT (BHU) wrote:
>>>
>>>> On 15 March 2015 at 23:19, <[email protected]> wrote:
>>>>
>>>> From that perspective isn't every language pure? Haskell's still got
>>>>> "randomIO" and "print <=< readMVar"
>>>>>
>>>>
>>>> Haskell is impure only when you use the unsafe* functions (atleast
>>>> that's
>>>> how I understand purity).
>>>>
>>>> My understanding is that a language is impure if it allows one to write
>>>> arbitrary IO within a function and still give it a proper (mathematical)
>>>> function type. In other words impurity arises only if you can unwrap
>>>> the IO
>>>> monad (which is what the unsafe functions do).
>>>>
>>>> The two examples you give above are pure under such a perspective, but I
>>>> might be wrong.
>>>>
>>>
>>> You're right, indeed. A language is pure if supplying a value `x` of
>>> type `A` to the a function
>>>
>>> A -> B
>>>
>>> will always returns the same result, no matter how often or in which
>>> order this function is called. This is true for both
>>>
>>> randomIO :: Random a => IO a
>>> (readMVar >=> print) :: Show a => MVar a -> IO ()
>>>
>>> because they return an IO action. This action will always be the same
>>> given the same arguments.
>>>
>>> The language would be impure if these functions had the types
>>>
>>> randomIO :: Random a => a
>>> (readMVar >=> print) :: Show a => MVar a -> ()
>>>
>>
>> Doesn't "pure" correspond to "can write a unit test for"? When a
>> function's return value only ever depends on its inputs, then I can
>> write a set of test-cases for various inputs, and assert that the
>> return-value has the expected content.
>>
>> A function that reads from a file, stdin, etc. cannot be tested in the
>> same way; I cannot _assert_ that the returned value has specific content.
>>
>> Sumit stated earlier that IO is "a pure program that can be executed",
>> which seems similar to your description above (which I admit I
>> don't yet 100% understand). How can I "assert" anything about this
>> "program", or make a Haskell-based application 'safer' in any way by
>> leveraging this kind of 'purity'?
>>
>> Thanks,
>> Simon
>>
>> _______________________________________________
>> Beginners mailing list
>> [email protected]
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>>
>
>
>
> --
> Regards
>
> Sumit Sahrawat
>
--
Regards
Sumit Sahrawat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.haskell.org/pipermail/beginners/attachments/20150316/04fce54c/attachment.html>
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 81, Issue 46
*****************************************
