Am Donnerstag, 14. Juli 2005 13:17 schrieben Sie:
> [...]
> > > where readEntireFile reads the entire file and returns it as a string.
> > > I can imagine several results: [a,a], [a,b], [a,_|_], [_|_,_|_], _|_.
> >
> >I decided to distinguish between read-only I/O and write-permitted I/O.
> > If
At 12:02 PM 7/12/2005, Wolfgang Jeltsch wrote:
Am Montag, 11. Juli 2005 15:51 schrieben Sie:
> [...]
> I am always interested in functional I/O solutions that adopt the
> "world-as-value" paradigm (or the more verbose "explicit multiple
> environment passing" paradigm) that has been exploited in
Am Montag, 11. Juli 2005 15:51 schrieben Sie:
> [...]
> I am always interested in functional I/O solutions that adopt the
> "world-as-value" paradigm (or the more verbose "explicit multiple
> environment passing" paradigm) that has been exploited in Clean's file I/O
> system and GUI library. Your
At 05:01 PM 7/9/2005, Wolfgang Jeltsch wrote:
[..]
Hello,
the idea is to have different monads for I/O on different
resources. A simple
example is to have the two monads WorldIO and FileIO and a type
FileIOHandle.
A file is a part of the world. You have the following
functions:
readChar
On Friday 08 Jul 2005 6:21 pm, Olaf Chitil wrote:
> If this were not a
> primitive in the IO monad, how would you define it in Haskell without
> some nasty hacks (a top-level IORef springs to my mind)?
Do you mean using a top-level IORef is a nasty hack, or you refering
to the nasty hack we have t
Am Samstag, 9. Juli 2005 18:17 schrieb Bulat Ziganshin:
> [...]
> sorry, it is probably not what i'm think about. as i can see, you are
> provide safe equivalent of interleaveIO,
Not really. An important difference between my solution and
unsafeInterleaveIO is that with unsafeInterleaveIO the w
Hello Wolfgang,
Saturday, July 09, 2005, 7:01:06 PM, you wrote:
>> > As part of my diploma thesis, I'm working on a small collection of modules
>> > which provides safe I/O interleaving. The key point is to split the state
>> > of the world since I/O on different parts of the world can be interl
Am Samstag, 9. Juli 2005 08:31 schrieb Bulat Ziganshin:
> Hello Wolfgang,
>
> Friday, July 08, 2005, 11:55:48 PM, you wrote:
>
> > As part of my diploma thesis, I'm working on a small collection of modules
> > which provides safe I/O interleaving. The key point is to split the state
> > of the wor
Am Samstag, 9. Juli 2005 15:25 schrieben Sie:
> On Fri, Jul 08, 2005 at 09:55:48PM +0200, Wolfgang Jeltsch wrote:
> > As part of my diploma thesis, I'm working on a small collection of
> > modules which provides safe I/O interleaving. The key point is to split
> > the state of the world since I/O
On Fri, Jul 08, 2005 at 09:55:48PM +0200, Wolfgang Jeltsch wrote:
> As part of my diploma thesis, I'm working on a small collection of modules
> which provides safe I/O interleaving. The key point is to split the state of
> the world since I/O on different parts of the world can be interleaved
Hello Wolfgang,
Friday, July 08, 2005, 11:55:48 PM, you wrote:
WJ> As part of my diploma thesis, I'm working on a small collection of modules
WJ> which provides safe I/O interleaving. The key point is to split the state
of
WJ> the world since I/O on different parts of the world can be interle
Hello Andrew,
Friday, July 08, 2005, 8:43:02 PM, you wrote:
AP> It is one thing to embrace lazy evaluation order, and another to embrace
AP> lazy IO (implemented using unsafeInterleaveIO). As a relative newcomer
AP> to Haskell, I got the impression that the "interact" style was always a
AP> hack,
Am Freitag, 8. Juli 2005 19:21 schrieb Olaf Chitil:
> [...]
> In fact, unsafeInterleaveIO shows up limitations of the IO monad.
> Without this strange primitive (what is actually unsafe about it?)
unsafeInterleaveIO doesn't break referential transparency, right? I suppose,
it is unsafe in the s
Am Freitag, 8. Juli 2005 18:43 schrieb Andrew Pimlott:
> [...]
> It is one thing to embrace lazy evaluation order, and another to embrace
> lazy IO (implemented using unsafeInterleaveIO). As a relative newcomer
> to Haskell, I got the impression that the "interact" style was always a
> hack, disc
Andrew Pimlott wrote:
It is one thing to embrace lazy evaluation order, and another to embrace
lazy IO (implemented using unsafeInterleaveIO). As a relative newcomer
to Haskell, I got the impression that the "interact" style was always a
hack, discarded for good reason in favor of the IO monad.
On Fri, Jul 08, 2005 at 02:51:11PM +0100, Colin Runciman wrote:
> >>My interaction depends on the (subtle order of) evaluation of a pure and
> >>total function?
> >>
> Pure, yes; total, no.
>
> Many important things depend on order of evaluation in lazy programs:
> for example, whether they comput
Christian Maeder wrote:
Colin Runciman wrote:
buffer xs = foldl const xs xs
I don't find it this easy nor a good programming practise.
My interaction depends on the (subtle order of) evaluation of a pure and
total function?
I would not think so much about the operational evaluation ord
Christian,
>>buffer xs = foldl const xs xs
>>I don't find it this easy nor a good programming practise.
>>
>>
I don't see why you should think it hard to define a function like
'buffer'. The whole purpose of foldl is to encapsulate accumulation.
It demands the full spine of its list argument
Colin Runciman wrote:
> output are less than a line! However, there is no need to build
> line-buffering into the system, because it is easily defined in Haskell:
>
> buffer xs = foldl const xs xs
I don't find it this easy nor a good programming practise.
My interaction depends on the (subtle o
Christian Maeder wrote:
>Could you also insert a prompt that is shown before the lines are read?
>(The first prompt seems to be tricky assuming line buffering )
>
>
If line-buffering is assumed or imposed, of course it prevents the
programming of interactive applications where the units of input
Hello Christian,
Thursday, July 07, 2005, 6:55:13 PM, you wrote:
CM> Could you also insert a prompt that is shown before the lines are read?
CM> (The first prompt seems to be tricky assuming line buffering )
import System.IO
main = do
hSetBuffering stdin LineBuffering
hSetBuffering stdout
Bulat Ziganshin wrote:
> Hello Colin,
>
> Thursday, July 07, 2005, 4:33:39 PM, you wrote:
type FilterProgram = [Line] -> [Line]
>
> CR> interact :: (String -> String) -> IO ()
>
> and there is lines and unlines functions to do just what yopu need
>
> example: main = interact (unlines.filter
Hello Colin,
Thursday, July 07, 2005, 4:33:39 PM, you wrote:
>>>type FilterProgram = [Line] -> [Line]
CR> interact :: (String -> String) -> IO ()
and there is lines and unlines functions to do just what yopu need
example: main = interact (unlines.filter(not.null).lines)
--
Best regards,
Christian Maeder wrote:
-- a filter program process an entire input to yield some output
type FilterProgram = [Line] -> [Line]
Forget this, if it's not an (old) exercise
Yes, people don't write lazy functional programs in Haskell any more.
In the Era of Monadic Enlighte
mt wrote:
> hi,
>
> i'd like to know how to write simply a line-based interactive program, that
> is
> one with which you have a 'talk'.
I would start with:
main =
do putStrLn "Please enter text (or press return to exit):"
s <- getLine
if s /= "" then do
putStrLn s
hi,
i'd like to know how to write simply a line-based interactive program, that is
one with which you have a 'talk'.
a simple filter-like line-based program ca be written as:
-- a filter program process an entire input to yield some output
type FilterProgram = [Line] -> [Line]
but i don't knwo
26 matches
Mail list logo
