David Roundy <[EMAIL PROTECTED]> wrote:
> hello,
> well that's because haskell is not as pure as it claims to be :-)
Nonsense. Haskell is perfectly pure; the IO monad is just
nondeterministic :)
> if every monad supports errors depends on what you mean by "supporting
> errors".
I mean `supporti
Google for 'punning'. It was removed from Haskell (I don't know why --
look at the list archives). But that used to be legal.
On Thu, 13 Nov 2003, John Meacham wrote:
> so I noticed DrIFT was generating code like
>
> f Foo{bar} = ...
> as seemingly a shorthand for
> f Foo{bar = bar} = ...
>
so I noticed DrIFT was generating code like
f Foo{bar} = ...
as seemingly a shorthand for
f Foo{bar = bar} = ...
which does not seem to work with current compilers. I fixed this in
2.0.2 but was curious why it was generating code like that in the first
place. it appears to be illegal looking at t
hello,
well that's because haskell is not as pure as it claims to be :-)
if every monad supports errors depends on what you mean by "supporting
errors".
i would argue that supporting errors and divergence is not the same thing.
the difference is that one should be able to handle an error thrown by
Hello guys,
any one aware of a Sockets howto for haskell ?
Greets, Jad
___
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
David Roundy <[EMAIL PROTECTED]> wrote:
> i would say that if you are wanting to report errors to users, you
> should not use "fail" or "error". you should instead explicitly
> report the error. when i program i typically use "error" in
> situations that i think are imposible, but if there is a
Quoting Graham Klyne <[EMAIL PROTECTED]>:
> Finally, as evidence for this view of user interfaces, I note that for
> tasks like computer system administration, graphical interfaces have
> pretty much taken over from the old command-line-and-text-file approach.
> Even Linux systems have graphical f
hello,
i would say that if you are wanting to report errors to users, you
should not use "fail" or "error".
you should instead explicitly report the error.
when i program i typically use "error" in situations that i think are
imposible,
but if there is a bug one gets a better error messeage.
i d
Yes, absolutely. See
http://research.microsoft.com/~simonpj/Papers/derive.htm
Section 7, and Trifanov's paper at the Haskell Workshop 2003
Simon
| -Original Message-
| From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ken
| Shan
| Sent: 13 November 2003 05:40
| To: [
I love religious wars.
Having been around awhile, I make a prediction. This will thrash a while,
those who like graphical environments will make their points, those who like
textual environments will make their points, no one will convince anyone
else, and eventually it will die down.
In fact (i
W liście z czw, 13-11-2003, godz. 10:34, [EMAIL PROTECTED]
pisze:
> If 'graphical' isn't taken too literally,
> you can think of a dialog per function with the possibility to specify
> pre and post conditions, tests, comments, etc.
I still doubt it would be more convenient. Maybe it's just me, bu
When one triggers an exception with something like
fail "Error opening file"
The user gets a message like
Fail: user error
Reason: Error opening file
which is confusing to the user, because it the user's fault. Is there some
other way that it is recommended one fail? Or should I be catching
us
As a "serious programmer", I'd be very happy to have a more graphical,
more interactive programming experience as far as _output_ is concern.
I'm happy to input textual expressions and definitions, but I'd
like instant feedback and display of intermediate results as tables,
graphs, trees, charts e
[Switching to haskell-cafe]
For "serious programming", I entirely agree.
But my view is that we are seeing some degree of programmability entering
all sorts of everyday objects -- video recorders spring to mind as an early
example -- and there's lots of work going on in the field of "ubiquitous
> There is a strong difference between asynchronous signals (like SIGIO,
> SIGINT, etc..) and synchronous ones (SIGFPE, SIGSEG). I think only the
> second type should be treated as exceptions, since they are tied to a
> specific thread of execution. tying asynchronous signals to exceptions
> just
Hello,
Has anyone thought about adding hereditary Harrop formulas, in other
words hypothetical reasoning and universal quantification, to the
instance contexts in the Hsakell type class system? Just today (and not
only today) I wanted to write instance definitions like
instance (forall a. C
> > I've sometimes thought that a functional language would be
> the ideal
> > platform to usher in a purely graphical style of programming;
>
> I don't understand why so many people talk about graphical
> programming,
> i.e. putting together functions, arguments, definitins etc. with the
> mou
It's a while since I paid serious attention to making sure that GHC's
transformations are all working right. Things are usually more
complicated than one might hope.
In this case,
* foldl is defined in the prelude using explicit recursion, as it
happens
* you've defined foldl' using foldr, and
18 matches
Mail list logo
