==
** SINCERE APOLOGIES IF YOU RECEIVE MULTIPLE COPIES OF THIS CfC **
***
Call for contributions
18th IFIP World Computer Congress
The premier international forum on
Sciences and Technologies of Information and
Hi, the interact remark triggered me to post this remark on nested use of
IO. (I posted something similar some month ago on haskell-cafe/I read the
haskell-archives ones so often)
What about this program:
main :: IO ()
main = putStr (show (putStr Hello World!))
Am I the only one who feels
Bruce,
All this discussion of 'interact' makes me feel quite nostalgic. In
the late 80s(!) I did some work on this, since Miranda's only IO was in
the form of interact. Understanding the interleaving behaviour is
problematic, and hand-coded solutions proved to be difficult. I came up
with a way
What about this program:
main :: IO ()
main = putStr (show (putStr Hello World!))
Am I the only one who feels that there is some conceptual _wrongness_ about
Hugs responding with IO action?
I think it is exactly right.
Having it print Hello World would clearly be wrong since
it
Dear Haskellers,
as part of our project on Refactoring Functional Programs
http://www.cs.kent.ac.uk/projects/refactor-fp/
we are pleased to announce the availability of HaRe 0.1 (also
known as HaRe 01/10/2003 ;-), a snapshot of our Haskell Refactorer
prototype. You can get it via
Alastair Reid wrote:
Another question with a trivial answer, what is the result of:
main :: IO (IO ())
main = return (putStr Hello World!)
It is a computation which, if executed, will print Hello World
Clearly it also shows the relation between IO and chosen evaluation
strategy.
This
On Thu, 02 Oct 2003 12:47:15 +0200
Lennart Augustsson [EMAIL PROTECTED] wrote:
Alastair Reid wrote:
Another question with a trivial answer, what is the result of:
main :: IO (IO ())
main = return (putStr Hello World!)
It is a computation which, if executed, will print Hello
Derek Elkins wrote:
If I'm not mistaken, the Report restricts main's type to be, at least,
IO a. Anyways, it's perfectly sensible to return anything. The RTS
simply discards it. The above example as an entire program is an IO
action that returns an IO action that is discarded by the RTS.
You're
I think there's a typo in section 7.3.12.3:
[[
You can't use existential quantification for newtype declarations. So this
is illegal:
newtype T = forall a. Ord a = MkT a
Reason: a value of type T must be represented as a pair of a dictionary for
Ord t and a value of type t. That contradicts
G'day all.
Alastair Reid [EMAIL PROTECTED] wrote:
I think it is exactly right.
I think it's wrong. The return type of IO should be discarded.
Even if it isn't, it doesn't make sense for IO to be in Show.
Cheers,
Andrew Bromage
___
Haskell mailing
[apologies for multiple copies - experience has shown that not
all Haskellers can be reached via the main Haskell list anymore]
An entry for your diaries (no other action required right now):
--Pre-Call
Your contributions to the
Off the top of my head:
1) Compute length of C string.
(As usual, need to use seq on the '+1' argument.)
2) Scan from right to left, constructing the list.
Ah yes, that's the trick I was forgetting about, thanks.
Or, since making two passes seems ugly, construct the list in
reverse
Actually what I really need is peekCStringLen. This function can
surely avoid stack overflow by building up the result from right to
left?
I think for peekCString the solution might be to get the length using
the C function strlen (which is more optimised than a Haskell alternative)
and then call
[apologies for multiple copies - experience has shown that not
all Haskellers can be reached via the main Haskell list anymore]
An entry for your diaries (no other action required right now):
--Pre-Call
Your contributions to the
Petter Egesund [EMAIL PROTECTED] writes:
I load my file in one chunk, and does a lot of substitutes on the string -
this is quick eating all my memory and the computers start to get really
slow.
Keep in mind that Strings are lists of characters. I think (somebody
correct me if I'm wrong) GHC
Petter Egesund [EMAIL PROTECTED] writes:
fun :: String - String
look for pat1 in string - if found subst with sub1
look for pat2 in string - if found subst with sub2
look for pat3 in string - if found subst with sub3
recurse until no pattern is found
I would structure
On Wed, 1 Oct 2003, Robert Ennals wrote:
Haskell is a good language, pureness is good, type classes are good,
monads are good - but laziness is holding it back.
Hear hear.
I have often wondered how much simpler the various Haskell implementations
would be if they used strict evaluation. It
Am Donnerstag, 2. Oktober 2003, 10:52 schrieb Nicholas Nethercote:
On Wed, 1 Oct 2003, Robert Ennals wrote:
Haskell is a good language, pureness is good, type classes are good,
monads are good - but laziness is holding it back.
Hear hear.
I have often wondered how much simpler the various
I have an extremely-newbie question about monads and how to interpret
the monadic laws; I asked that same question yesterday on IRC and the
answers were interesting but non-conclusive (to me anyway).
I'm trying to learn monads by reading All About Monads, version 1.0.2.
I though of defining a
W licie z czw, 02-10-2003, godz. 11:13, Juanma Barranquero pisze:
The intent is that Counted objects count the number of times an
operation is applied to them.
As you discovered, there is no meaningful count of operations. If an
operation doesn't do anything, do you count it? I suppose yes -
Hi folks,
I have simulator which should grind away all night but check the keyboard once per
iteration to see if I'm trying to view the results, change parameters or terminate it.
Therefore I need a non-blocking keyboard peek function. So far, my searching only lead
to some stuff about using
Keep in mind that Strings are lists of characters. I think (somebody
correct me if I'm wrong) GHC will store a character inside a cons
cell, but that still leaves 8 bytes per character. Worst case it will
store the 8-byte cons cell pointing to a 32-bit char value, 12 bytes
per character.
Adrian May [EMAIL PROTECTED] writes:
Therefore I need a non-blocking keyboard peek function.
So far, my searching only lead to some stuff about using threads
in GHC but that seems far too complicated and messy.
Look in the standard IO library for 'hReady', which is a non-blocking
check for
Simon Marlow wrote:
So, we're agreed that the presence of lazy evaluation makes implementing
optimistic evaluation (and other evaluation strategies) more
complicated. Personally, I find it disturbing that the presence of this
family of library functions affects something as low-level as the
On Thu, 2 Oct 2003, Wolfgang Jeltsch wrote:
Yes, but I think that the reason for laziness is not to make compiler
constructors' lifes easier but language users'.
I appreciate the prefer-users'-ease-over-compiler-writers' idea. For
example, syntactic sugar can be a great thing. But I think
On Wed, Oct 01, 2003 at 03:06:50PM +0100, Simon Marlow wrote:
... Then run it with +RTS -DS -Sstderr, observe it going very slowly and
see if it throws any assertion failures.
I get a:
ASSERTION FAILED: file Storage.c, line 875
This is in ghc CVS HEAD as of yesterday morning. It shows up
The real problem is that lazy I/O injects side effects into the pure
world of expressions. Haskell has a perfectly good system for
encapsulating side effects - the IO monad. So why put
these sneaky side
effects into pure values?
I fear one problem is that the word side effect is
On Thu, 2 Oct 2003, Nicholas Nethercote wrote:
I appreciate the prefer-users'-ease-over-compiler-writers' idea. For
example, syntactic sugar can be a great thing. But I think there's a
point where it becomes too much. Haskell has arguably passed that point.
Sorry, this was ambiguous; when
On Thu, 02 Oct 2003 11:22:13 +0200
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
As you discovered, there is no meaningful count of operations. If an
operation doesn't do anything, do you count it?
It's not about counting the operations (that's just an example), but
accumulating any kind
(taken to -cafe)
C.Reinke [EMAIL PROTECTED] writes:
Dear Haskellers,
as part of our project on Refactoring Functional Programs
http://www.cs.kent.ac.uk/projects/refactor-fp/
we are pleased to announce the availability of HaRe 0.1 (also
known as HaRe 01/10/2003 ;-), a snapshot of
Nicholas Nethercote wrote:
Also, I'm not convinced that laziness does make users' lives easier --
witness a lot of the traffic on this list. Witness the subject of this
thread. In which case the extra difficulty heaped upon compiler writers
is of questionable value.
I'm convinced that if
On Thu, 2 Oct 2003, Thomas Johnsson wrote:
I'm convinced that if laziness (or call by name) were the norm in
languages in general, then there would be similar traffic
in lists like this one about the problems of strict evaluation -- and
there would be a lot more of it,
since strictness
I'm not trying to create useful monads (I'm pretty sure they
aren't :),
but understanding the concepts. So, the question remains:
when the monad
laws say that
(return x) = f == f x
The Monad class is just called Monad because it is intended
to cover a monad. But it doesn't ensure the
So, the question remains: when the monad
laws say that
(return x) = f == f x
what is intended in that ==?
Observational equivalence.
For monads like list and maybe, this boils down to the normal equality because
the standard equality on these types is exactly observational equality.
On Thu, 02 Oct 2003 12:59:25 +0200
Juanma Barranquero [EMAIL PROTECTED] wrote:
On Thu, 02 Oct 2003 11:22:13 +0200
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
As you discovered, there is no meaningful count of operations. If an
operation doesn't do anything, do you count it?
The
On Thu, 2 Oct 2003 13:16:13 +0200
[EMAIL PROTECTED] wrote:
The Monad class is just called Monad because it is intended
to cover a monad. But it doesn't ensure the laws. That is your
sole responsibility.
Yeah, I know. But it's difficult to ensure I'm satisfying the laws when
I'm not entirely
W licie z czw, 02-10-2003, godz. 12:59, Juanma Barranquero pisze:
It's not about counting the operations (that's just an example), but
accumulating any kind of state. For example:
data Accum a = Ac [a] a
instance Monad Accum where
return x = Ac [x] x
Ac _ x = f = let
On Thu, 2 Oct 2003 12:30:54 +0100
Alastair Reid [EMAIL PROTECTED] wrote:
Observational equivalence.
For monads like list and maybe, this boils down to the normal equality because
the standard equality on these types is exactly observational equality.
For monads like IO, you can't define
W licie z czw, 02-10-2003, godz. 14:25, Juanma Barranquero pisze:
Yeah, I know. But it's difficult to ensure I'm satisfying the laws when
I'm not entirely sure what do they ask from me...
1. (return x) = f == f x
2. m = return == m
3. (m = f) = g == m = (\x - f x = g)
My intuition:
1 2.
On Thu, 02 Oct 2003 14:27:29 +0200
Marcin 'Qrczak' Kowalczyk [EMAIL PROTECTED] wrote:
Accumulating state is fine. These definitions don't accumulate state:
'return' should yield a neutral state, and the above = ignores the
state of the lhs.
You're right.
data Accum s a = Ac [s] a
First, let me say that I'm intrigued. This looks like really neat
functionality to have available.
Thanks; obviously, we think so, too!
I'm curious whether you are planning (or have developed) tools to
*detect* cases for refactoring? Occasionally, I find myself wishing
for a tool to help
Incidentally, it is quite common to define a Monad instance but no Eq
instance. (e.g., the IO monad, most parser monads, most state transformer
monads, etc.)
So you should not interpret the '==' in the monad law as requiring you to
define an Eq instance.
If you do define an Eq instance, it
From your examples and interpretations, it looks like you need to become
more familiar and comfortable with -using- monads before you bother
trying to write one. Then once you have that down, seeing how -correct-
monads work would probably be the next most helpful thing. You'll have
a very hard
Thomas Hallgren [EMAIL PROTECTED] replies to Simon M:
Simon Marlow wrote:
The real problem is that lazy I/O injects side effects into the pure
world of expressions. Haskell has a perfectly good system for
encapsulating side effects - the IO monad. So why put these sneaky side
effects into
So... you agree that getContents in its current form should really be
called unsafeGetContents? Unless perhaps we redefine its semantics to
either (a) yield a random string or (b) eagerly slurp the entire stream
contents?
Well, I'm not sure that the semantics of getContents is currently
I've been trying to use existential types [*] in my code.
[*] cf. Glasgow Haskell Compiler (GHC) user guide, section 7.3.12
My experiments have thrown up a couple of questions:
1. forall x introduces x as existential when it appears immediately
preceding a datatype constructor declaration,
On Thu, 2 Oct 2003 16:09:11 +0100, Alastair Reid [EMAIL PROTECTED] wrote:
So you should not interpret the '==' in the monad law as requiring you to
define an Eq instance.
If you do define an Eq instance, it ought to be reflexive, symmetric and
transitive (i.e., an equivalence) if you want
On Thu, Oct 02, 2003 at 12:08:07PM +0100, Nicholas Nethercote wrote:
But I can't imagine they would complain about the problem of being
confused... this strict code evaluated immediately, what's going on?! :)
This is because strict evaluation is always easy to understand.
Lazy/non-strict
On Thu, Oct 02, 2003 at 11:48:29AM +0100, Simon Marlow wrote:
So... you agree that getContents in its current form should really be
called unsafeGetContents? Unless perhaps we redefine its semantics to
either (a) yield a random string or (b) eagerly slurp the entire stream
contents?
John Meacham wrote:
personally, I think the easiest solution would be to punt the whole
issue by having:
getContents
lazily read the file if it is mmapable or a pipe
eagerly slurp the whole file if it refers to a tty
I think this kind of irregular behaviour would make the IO functions
even
data Datatype ex = forall vt . Datatype (DatatypeVal ex vt)
In practice one rarely would write
forall vt. Datatype (DatatypeVal ex vt)
unless he is writing something like the ST monad.
You can only pass vt to functions with the signature
forall vt. vt - C1 vt C2 C3 ...
where
[apologies for multiple copies - experience has shown that not
all Haskellers can be reached via the main Haskell list anymore]
An entry for your diaries (no other action required right now):
--Pre-Call
Your contributions to the
52 matches
Mail list logo