ve computation attempts to call unsafePerformIO or evaluate the IO
from an unsafeInterleaveIO then the speculation is immediately aborted. IO is
never speculated.
Anyone wanting to find out more about optimistic evaluation is encouraged to
download the paper from here:
http://www.c
ually speculative/optimistic evaluation should be fine.
Optimistic Evaluation refuses to speculate IO for exactly this reason.
If a speculative computation attempts to call unsafePerformIO or evaluate
the IO from an unsafeInterleaveIO then the speculation is immediately aborted.
IO is never speculated.
> In your example it's more or less guaranteed that putting "b"
> and "c" will
> never happen, because the result of the combinated IO action
> isn't demanded.
well yes, it was a bad example. i got another answer basically saying
that threading could screw it up (i'm not using thread) as could,
Hi,
> if i say:
>
> foo = do
> putStrLn "a"
> unsafeInterleaveIO (putStrLn "b" >> putStrLn "c")
> putStrLn "d"
>
> is it guarenteed that nothing will happen between putting "b" and "c"?
> that is, whil
On Friday 29 August 2003 7:23 pm, Hal Daume wrote:
> if i say:
>
> foo = do
> putStrLn "a"
> unsafeInterleaveIO (putStrLn "b" >> putStrLn "c")
> putStrLn "d"
>
> is it guarenteed that nothing will happen between putting
if i say:
foo = do
putStrLn "a"
unsafeInterleaveIO (putStrLn "b" >> putStrLn "c")
putStrLn "d"
is it guarenteed that nothing will happen between putting "b" and "c"?
that is, while the place/time at which the (putStrLn
On 01-Jun-2000, Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote:
>
> Like there is no way in Haskell 98 to access OS services beyond a certain
> subset, there is no way in C90 or C99 to access OS services beyond a
> certain subset. Haskell's subset is actually larger than C's.
>
> Like Haskell
On Thu, Jun 01, 2000 at 03:34:10PM +1000, Manuel M. T. Chakravarty wrote:
> Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote,
>
> > On Wed, May 31, 2000 at 12:06:00PM +1000, Manuel M. T. Chakravarty wrote:
> > > The one hole I am most concerned about is
> > > access to standard OS services and co
Antti-Juhani Kaijanaho <[EMAIL PROTECTED]> wrote,
> On Wed, May 31, 2000 at 12:06:00PM +1000, Manuel M. T. Chakravarty wrote:
> > The one hole I am most concerned about is
> > access to standard OS services and code written in other
> > languages
>
> FWIW, C has the same problem, and yet n+1 pro
On Wed, May 31, 2000 at 12:06:00PM +1000, Manuel M. T. Chakravarty wrote:
> The one hole I am most concerned about is
> access to standard OS services and code written in other
> languages
FWIW, C has the same problem, and yet n+1 programmers are happy with C
(and its descendants).
--
%%% Antti
Lennart Augustsson <[EMAIL PROTECTED]> wrote,
> "Ronald J. Legere" wrote:
>
> > Thanks that explaination was very very helpfull! (Also Martins comments).
> > One thing that I would like to understand is why so many of these
> > nonstandard extensions get used all the time. It is very hard to
>
On 30-May-2000, George Russell <[EMAIL PROTECTED]> wrote:
> Fergus Henderson wrote:
> > (If nothing at all can be guaranteed, then no-one should be using those
> > features, and they should be removed from the Hugs/ghc extension libraries.
> > But it should be possible to make some guarantees.)
>
Tue, 30 May 2000 18:52:53 +0200, Lennart Augustsson <[EMAIL PROTECTED]> pisze:
> I feel quite strongly about this, and when I write Haskell programs
> I try to avoid non-standard features as much as I can. Very often
> you can; it might be a little inconvenient, but I think it's worth
> the pric
Fergus Henderson wrote:
> (If nothing at all can be guaranteed, then no-one should be using those
> features, and they should be removed from the Hugs/ghc extension libraries.
> But it should be possible to make some guarantees.)
What on earth is a guarantee? GHC is a research project. I don't e
On 30-May-2000, George Russell <[EMAIL PROTECTED]> wrote:
> "Ronald J. Legere" wrote:
> >
> > SUMMARY: How about a supplement to the standard that contains the
> > 'standard' extensions that everyone uses.
> One problem I have with this is that "unsafe" operations, being unsafe,
> are difficult
"Ronald J. Legere" wrote:
>
> SUMMARY: How about a supplement to the standard that contains the
> 'standard' extensions that everyone uses.
One problem I have with this is that "unsafe" operations, being unsafe,
are difficult to fit in with the rest of the language. For example
a common use of
"Ronald J. Legere" wrote:
> Thanks that explaination was very very helpfull! (Also Martins comments).
> One thing that I would like to understand is why so many of these
> nonstandard extensions get used all the time. It is very hard to
> find any application package that doesnt use some nonstan
r IO function to put more values into that same list (stream)? So I
started poking around in the library files and thats how I got around to
asking the question about unsafeinterleaveIO.
Ok so what is my point? Perhaps some of these 'extensions' are so damn
useful and so commonly used they sh
ot; effect, and the value obtained is immutable
as every value should, and the thing is so useful, that we live with
that little impurity.
> unsafeInterleaveIO. WHAT the heck is that thing?
When applied to an IO action, it immediately produces a magic value,
which, when later evaluated, will execu
, you can use the function
"unsafeInterleaveIO", provided by many Haskell compilers (at
least Hugs, GHC and HBC), but *not* part of the Haskell
standard.
This is because it is an *unsafe* function, a function that
might give strange results, a functione which is not
semantically well-d
How
can I make it do it lazily? I hunted around in the Hugs libraries (but
this is not a Hugs question!!! ) and found that in the Channel library
there is a function just like this for channels, and somehow to make
it work it uses unsafeInterleaveIO. WHAT the heck is that thing? I
looked at it and
21 matches
Mail list logo
