[Haskell-cafe] Re: Top Level TWI's again was Re: [Haskell] Re: Parameterized Show

[Keean Schupke]

Obviously without knowing the details I am speculating, but would it not 
be possible
to do a first pass of the XML and build a list of files to read (a pure 
function) this returns
its result to the IO monad where the files are read and concatenated 
together, and passed
to a second (pure functional) processing function. If written well this 
can take advantage
of lazy execution, so both functions end up running concurrently.

It seems to me that as unsafePerformIO is not in the standard and only 
implemented on some
compilers/interpreters, that you limit the portability of code by using 
it, and that it is best avoided. Also as any safe use of unsafePerformIO 
can be refactored to not use it I could
certainly live without it.

    Keean.

Graham Klyne wrote:

> [Switching to Haskell-cafe]
>
> I have used it once, with reservations, but at the time I didn't have 
> the time/energy to find a better solution.  (The occasion of its use 
> was accessing external entities within an XML parser;  by making the 
> assumption that the external entities do not change within any context 
> in which results from a program are compared, I was able to satisfy 
> the "proof obligation" of not causing or being sensitive to side 
> effects.)
>
> The reason this was important to me is that I wanted to be able to use 
> the parser from code that was not visibly in the IO monad.  For me, 
> treating Web data transformations as pure functions is one of the 
> attractions of using Haskell.
>
> (Since doing that, I had an idea that I might be able to parameterize 
> the entity processing code on some Monad, and use either an Identity 
> monad or IO depending on the actual requirements.  This way, I could 
> keep pure XML processing out of the IO monad, but use IO when IO was 
> needed.)
>
> In short:  I think it's usually possible to avoid using 
> unsafePerformIO, but I'd be reluctant to cede it altogether, if only 
> for sometimes quick-and-dirty pragmatic reasons.
>
> #g
>
>
> ------------
> Graham Klyne
> For email:
> http://www.ninebynine.org/#Contact
>