Hi, All!
Searching the web I've come across some theorem provers for Haskell. I
wonder if somebody is using them in his daily work.
Any way I would like to hear your opinions about some of the provers
as well as about the whole idea of proving programs rather than
testing them.
--
Best regards,
Joe English wrote:
> case nodeName node of
> "html:p" -> ...
> "html:h1" -> ...
> "html:pre" -> ...
> The approach I'm thinking of is to let the application programmer
> define an "internal" namespace environment, then rewrite
> element and attribute names in the pars
G'day all.
On Fri, Feb 21, 2003 at 04:28:27PM -0800, Richard Nathan Linger wrote:
> What do people think about this?
> Has anyone else ever wished they had such support for unnamed sums?
I sometimes wish that Haskell did _not_ have support for unnamed
product types. To be honest, how hard is it
Haskell has nice syntactic support for unnamed product types (tuples).
It is as though there were builtin several datatype definitions of the form:
data (a,b) = (a,b)
data (a,b,c) = (a,b,c)
data (a,b,c,d) = (a,b,c,d)
...
But for sum types, there is only one generi
hi,
the read only "state" monad is usually called "environment", or "reader"
monad. since it is goind to be "read-only" there is no need to return a
new state in the result (as it would presumably be the same as the input
state). so the type becomes:
newtype Env e a = E (e -> a)
for somethi
I guess I figured that Arrays were the natural data type for the tickets
since it has a fixed size and the elements all have a specific player
associated with them. I am coming from a Scheme background so I am already
very fluent in list manipulation. I'm not an imperative programer, so that's
no
"Mike T. Machenry" <[EMAIL PROTECTED]> wrote:
> Hey Everyone,
>
> I am having a hard time making a data structure that I can
> incrimentally
> update. Mostly because dealing with arrays is so tough. Does anyone
> think I'm going about this completely the wrong way? This is what I
> have.
IMO t
