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: How Haskell Fits Into an Operating System / API
Environment (Darren Grant)
2. Re: Text.XML.writeFile question (Alan Buxton)
3. Re: How Haskell Fits Into an Operating System / API
Environment (Heinrich Apfelmus)
----------------------------------------------------------------------
Message: 1
Date: Mon, 12 Aug 2013 22:30:37 -0700
From: Darren Grant <[email protected]>
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell <[email protected]>
Subject: Re: [Haskell-beginners] How Haskell Fits Into an Operating
System / API Environment
Message-ID:
<ca+9vpfc-7-rvlvmcq-3u+e4y6ggnacdmkdummejitgb5cm5...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Mon, Aug 12, 2013 at 9:45 PM, damodar kulkarni <[email protected]>wrote:
>
> Curiously, whenever I use state, my programs start to become similarly
>> brittle. There is no reason why state should be a fundamental element of a
>> programming language, and as a design pattern, state is best avoided at all
>> cost.
>
>
> Just as a curiosity, how would one avoid state in cases like protocol
> design? e.g. protocols specifications (like TCP/IP) do have a large element
> of state dependent behavior that "seems essential" to the problem. How
> would one deal with such cases?
>
State can be achieved in pure functional languages. The difference is that
the state management is not directly accessible to the programmer as it is
hidden behind a highly declarative set of abstractions. This provides the
benefits of consistency, and sometimes frustration when the resulting
machine code doesn't perform as expected.
Cheers,
Darren
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130812/9854399e/attachment-0001.html>
------------------------------
Message: 2
Date: Tue, 13 Aug 2013 09:06:14 +0100
From: "Alan Buxton" <[email protected]>
To: "'The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell'" <[email protected]>
Subject: Re: [Haskell-beginners] Text.XML.writeFile question
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Thanks David. Spot on.
a
From: Beginners [mailto:[email protected]] On Behalf Of David
McBride
Sent: 12 August 2013 21:52
To: The Haskell-Beginners Mailing List - Discussion of primarily
beginner-level topics related to Haskell
Subject: Re: [Haskell-beginners] Text.XML.writeFile question
When you use overloadedstrings, it will type all literal strings as IsString
a => a as a type. Unfortunately your tsString is not a literal, it is a run
time function that always returns a string and a string is not a filepath.
You should be able to do fmap fromString tsString, provided you import
Data.String.
On Mon, Aug 12, 2013 at 4:35 PM, Alan Buxton <[email protected]> wrote:
Hi
I am trying to write an XML file where the filename is created based on a
timestamp. Simplified version below. This won't compile - I get this error
in doWrite2
filepathtest.hs|24 col 17 error| Couldn't match expected type
`system-filepath-0.4.7:Filesystem.Path.Internal.FilePath'
|| with actual type `String'
|| In the second argument of `writeFile', namely `t1'
|| In a stmt of a 'do' block: writeFile def t1 doc
|| In the expression:
|| do { t1 <- tsString;
|| writeFile def t1 doc }
Somehow the String "text.xml" in doWrite1 is converted into a FilePath, but
not the String t1 in doWrite2. What am I doing wrong?
{-# LANGUAGE OverloadedStrings #-}
module Filepathtest where
import Text.XML
import Data.Time.Clock.POSIX (utcTimeToPOSIXSeconds)
import Data.Time.Clock (getCurrentTime)
import Prelude hiding (writeFile, FilePath)
tsString :: IO String
tsString = do
x <- getCurrentTime
let x' = show $ floor $ utcTimeToPOSIXSeconds x
return x'
doWrite1 :: Document -> IO ()
doWrite1 doc =
writeFile def "test1.xml" doc
doWrite2 :: Document -> IO ()
doWrite2 doc = do
t1 <- tsString
writeFile def t1 doc
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.haskell.org/pipermail/beginners/attachments/20130813/b4dcff90/attachment-0001.html>
------------------------------
Message: 3
Date: Tue, 13 Aug 2013 11:33:38 +0200
From: Heinrich Apfelmus <[email protected]>
To: [email protected]
Subject: Re: [Haskell-beginners] How Haskell Fits Into an Operating
System / API Environment
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
damodar kulkarni wrote:
>> Curiously, whenever I use state, my programs start to become similarly
>> brittle. There is no reason why state should be a fundamental element of a
>> programming language, and as a design pattern, state is best avoided at all
>> cost.
>
>
> Just as a curiosity, how would one avoid state in cases like protocol
> design? e.g. protocols specifications (like TCP/IP) do have a large element
> of state dependent behavior that "seems essential" to the problem. How
> would one deal with such cases?
Well, in a protocol like TCP/IP, the response of a participant does
depend on the history of the communication, and that history can neatly
be summarized in a small amount of state. I don't think it's possible to
avoid state in this case.
But I meant something else, actually, and should have been more precise.
Namely, it is best to avoid *mutable* state as a *design pattern*, i.e.
the use of IORef and thelike. Pure functions State -> State are fine,
but anything were the meaning of an expression depends heavily on the
context (the program state) is prone to bugs. The problem is more about
source code than it is about state. To avoid bugs, each piece of source
code should be understandable in isolation, i.e. it should give the same
results in all contexts ("code paths"). This way, it is a lot easier to
determine its correctness.
Of course, "source code" has different scales, and can include protocol
design. After all, protocols are made by humans, and clever design can
prevent headaches later. For instance, HTTP GET requests were designed
to be stateless, and that makes the protocol a lot more robust.
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
------------------------------
Subject: Digest Footer
_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners
------------------------------
End of Beginners Digest, Vol 62, Issue 13
*****************************************
