Daniel Fischer <[EMAIL PROTECTED]> writes:
>> 'everything matters' is wrong even for IO actions, because the
>> actual value returned when the action is executed is completely
>> irrelevant to the IO action's identity.
> Now that I cannot swallow, that would mean
> return 4 == return 5.
I would
G'day all.
Quoting Daniel Fischer <[EMAIL PROTECTED]>:
> The sad truth is that IO actions in general aren't well defined entities
> (unless we index them with the space-time-coordinates of their invocation).
Not really. One of the ways that IO used to be implemented (still might
be on some Hask
On Jan 24, 2005, at 8:53 PM, Jorge Adriano Aires wrote:
And it would say nothing about things like:
return 4 >> return 5 ==?== return 5
I can live with it.
I feel obliged to point out (because the repeated references to the
question are driving me up the wall) that this simple equality holds in
(Sorry about the recurrent self answers)
> Maybe (not sure) it is sensible to
> sapecify return::(a -> IO a), as an action with no side effects such that
> return x === return x iff x === x.
return x === return y iff x === y<-- this is what I meant to write.
But even that is not enough, s
> >This isn't obvious to me. So x is an action, and it does not always
> > produces the same side effects when executed. But why should that make
> > x/=x? It is the same action, it gets one line from the input, and then
> > prints it...
>
> OK, but then the different side-effects could not be use
hi,
it may happen for different reasons,
but a common one is when you have a foldl pattern (programming with an
accumulator),
for example like this:
sumList1 [] accum = accum
sumList1 (x:xs) accum = sumList1 xs (x + accum)
this adds a list of numbers with an accumulator.
because haskell is
Thank you iavor. But the -K option doesn't appear
to work with ghci. And I guess the bigger
question is what sort of code causes a
stack overflow. If 5M is enough stack for most
programs then I obviously have some basic coding
error which is causing a stack overflow...
What sort of code c
Am Montag, 24. Januar 2005 22:59 schrieb Benjamin Franksen:
> Both are wrong. 'just the result matters' is the correct POV for functions,
> but not for IO actions. 'everything matters' is wrong even for IO actions,
> because the actual value returned when the action is executed is completely
> irre
Am Dienstag, 25. Januar 2005 00:29 schrieb Jorge Adriano Aires:
>> x = getLine >>= putStrLn
>This isn't obvious to me. So x is an action, and it does not always produces
>the same side effects when executed. But why should that make x/=x? It is the
>same action, it gets one line from the input, a
> A constant c :: a is just morphism(function) c : 0 -> a, where 0 is the
> initial object (empty set).
--- Rant2 "correction"
Opss I messed up here. Should be terminal should 1-> a (terminal object/unit
set). At least that's how I usually think of constants in haskell 1 is
()... so I thin
Am Montag, 24. Januar 2005 20:25 schrieb Keean Schupke:
> I think the endofunctors are defined on the types, not the values
> though. So the object of the category is the endofunctor (Type -> Type),
> and unit and join are the identity and binary associative operator on
> which a Monad is defined.
> We face a severe problem here, not only that IO a is not an instance of Eq,
> which takes this whole discussion outside the realm of Haskell, on top of
>
> that we find the horrible fact that x /= x may be true in the IO Monad,
> consider
>
> x = getLine >>= putStrLn
>
> or anything similar --
On Monday 24 January 2005 21:23, Daniel Fischer wrote:
> Am Montag, 24. Januar 2005 11:47 schrieb Jules Bean:
>
>
> > Here are the three monad laws as written on the nomaware site:
> >
> > 1. (return x) >>= f == f x
> > 2. m >>= return == m
> > 3. (m >>= f) >>= g == m >>
GHC assumes the user knows the difference between
the heap and the stack. I don't. No matter how
much heap I specify on the GHCi command line, I
get a stack overflow exception. I have no idea
what that means or how to remedy it. Hints?
Note: My program is basically creating a few 100k
ite
Isaac Jones wrote:
>You might be interested in the new FilePath module that's in the
>works. There's been a lot of work to make these functions portable.
>
>http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/libraries/base/System/FilePath.hs
I didn't realize this was in CVS. IMHO this library is de
Am Montag, 24. Januar 2005 11:47 schrieb Jules Bean:
> Here are the three monad laws as written on the nomaware site:
>
> 1. (return x) >>= f == f x
> 2. m >>= return == m
> 3. (m >>= f) >>= g == m >>= (\x -> f x >>= g)
>
> Taking rule 1, we do not simply mean that
Ketil Malde wrote:
> > The point is that the Unix documentation does not consider the short
> > pause as data is read off your hard drive to be blocking. So that's why
> > select will always report that data is available when you use it with a
> > file handle.
>
> Isn't this also for historic re
David Roundy wrote:
> > >If you're reading from a random-access file, there's no way it can
> > >tell you when the file data is buffered, because it doesn't know which
> > >part of the file you plan to read. The OS may try to guess for
> > >readahead purposes, but select()'s behavior can't dep
Jules Bean wrote:
I've lost track of what you mean by 'this case' and indeed of what you
mean by 'join' (did you mean mplus? the word join is normally used for
the operation of type m (m a) -> m a, which is not often used directly
in haskell)
However, even addressing your point about endofuncto
> Right, but we are dealing with the type system here. Remember Haskell
> monoids are functors on types, not on values ... (ie the base objects the
> 'category theory' is applied to are the types not the values)...
>
> Therefore we only consider the types when considering Monads.
How so? Functors
On 24 Jan 2005, at 18:18, Keean Schupke wrote:
Ashley Yakeley wrote:
If you remember your category theory, you'll recall that two
morphisms are not necessarily the same just because they're between
the same two objects. For instance, the objects may be sets, and the
morphisms may be functions b
Ashley Yakeley wrote:
If you remember your category theory, you'll recall that two morphisms
are not necessarily the same just because they're between the same two
objects. For instance, the objects may be sets, and the morphisms may be
functions between sets: morphisms from A to B are the same
On Mon, Jan 24, 2005 at 04:48:49PM +, Graham Klyne wrote:
> At 20:15 21/01/05 +, John Goerzen wrote:
> >I have built a fixed Hugs for the Zaurus PDA running the OpenZaurus
> >distribution. Download here:
> >http://quux.org/devel/zaurus/hugs_hugs98-Nov2003-r1_arm.ipk
>
> Cool!
>
> I've of
At 15:17 20/01/05 -0500, Mark Carroll wrote:
I tried writing a little command-line utility to find the relative path of
one thing from another thing (with Unix-like systems in mind). ...
FWIW, there's logic to do something like this in my URI module [1]. Bear
in mind that there is not, in general
At 14:53 21/01/05 +, John Goerzen wrote:
I've been playing with HaXmL lately. I've had a need to convert one XML
document to another, and HaXmL was very nice for that.
Along the way, I've discovered that I need to do some I/O as part of the
conversion (specifically due to timezone-related calc
At 20:15 21/01/05 +, John Goerzen wrote:
Hello,
I have built a fixed Hugs for the Zaurus PDA running the OpenZaurus
distribution. Download here:
http://quux.org/devel/zaurus/hugs_hugs98-Nov2003-r1_arm.ipk
Cool!
I've often thought Haskell should be a good language for programming PDA
functions
> > GHC's memory profiling?
>
> I just gave it a try: when compiled with -prof -auto-all, my program
> is memory hungry in both cases, so I cannot really compare...
[cc'd back to list in case anyone else finds this useful; hope that's OK]
Ah. The cost-centre annotations get in the way of the op
In article <[EMAIL PROTECTED]>,
Keean Schupke <[EMAIL PROTECTED]> wrote:
> Right, but we are dealing with the type system here. Remember Haskell
> monoids are functors on types, not on values ... (ie the base objects the
> 'category theory' is applied to are the types not the values)...
>
> Ther
On 24 Jan 2005, at 10:32, Keean Schupke wrote:
Right, but we are dealing with the type system here. Remember Haskell
monoids are functors on types, not on values ... (ie the base objects
the
'category theory' is applied to are the types not the values)...
Therefore we only consider the types when
Ashley Yakeley wrote:
I don't believe this represents a good understanding of IO actions as
Haskell values. For instance, 'return ()' and 'putStrLn "Hello"' are the
same type, but are clearly different actions and so are usually
considered to be different values. That the latter prints out text
In article <[EMAIL PROTECTED]>,
Keean Schupke <[EMAIL PROTECTED]> wrote:
> Yes it is, side effects are quite clearly not counted. The value
> of (putStrLn "Hello" >> mzero") is mzero.
I don't believe this represents a good understanding of IO actions as
Haskell values. For instance, 'return ()'
Just thinking about this, a monad is a Functor plus two
natural-tranformations, Unit and Join. Is there an equivalent definition
for MonadPlus... I am not sure I understand where MonadPlus comes from?
Is it just a Functor and two different definitions of Unit and Join
(from those chosen to be i
On 24 Jan 2005, at 09:36, Keean Schupke wrote:
Ashley Yakeley wrote:
I disagree. Clearly (putStrLn "Hello" >> mzero) is not the same as
mzero.
Yes it is, side effects are quite clearly not counted. The value
of (putStrLn "Hello" >> mzero") is mzero.
This makes no sense to me at all.
putStrLn "He
Ashley Yakeley wrote:
I disagree. Clearly (putStrLn "Hello" >> mzero) is not the same as mzero.
Yes it is, side effects are quite clearly not counted. The value
of (putStrLn "Hello" >> mzero") is mzero.
In reference to the idea of splitting MonadPlus, what category
would you be operating in, if
Marcin 'Qrczak' Kowalczyk wrote:
These rules agree on "foo", "foo." and "foo.tar.gz", yet disagree on
"foo.bar."; I don't know which is more natural.
Filename extensions come from DOS 8.3 format. In these kind of
names only one '.' is allowed. Unix does not have filename extensions,
as '.' is ju
35 matches
Mail list logo
