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
38 matches
Mail list logo
