Bulat Ziganshin wrote:
> Hello apfelmus,
>
> Saturday, August 4, 2007, 12:18:33 PM, you wrote:
>
> > Then, mytransaction reads
>
> > mytransaction = return foo `apT` xvar0 `apT` xvar1 `apT` ...
>
> how about a+b*(c+d)?
That follows the same pattern,
return (+) `apT` a `apT`
(r
george.moschovitis:
>
>is it possible to create a FCGI server that listens to a
>specific port using the Haskell FCGI library?
>The front end web server would then communicate with this
>back end FCGI server through this port.
>A small example would be really appreciated.
>
On Aug 4, 2007, at 14:51 , Bulat Ziganshin wrote:
Hello Brandon,
Saturday, August 4, 2007, 8:44:46 PM, you wrote:
That would be why I'm using a language which lets me compose things
in complex ways. And just once, abstracting it away into a library,
which you seem to be missing.
and you h
I can't seem to find any information on how to deal with C functions
that return a (pointer to a) struct. C2hs tells me there's no automatic
support for marshalling structs (I'm using version 0.14.5).
If I'm to do it by hand, is there a preferred way? (E.g. make the type
adhere to the type Stora
I noticed that there is no official FreeBSD/amd64 port yet, although
there's a binary with a working "ghc" but non-working "ghci." Has
there been any progress on the amd64 port? Any estimate on when it
will be available? Any known workarounds (is it possible to install
and run an x86 ghc in Fre
On 8/4/07, Stephen Forrest <[EMAIL PROTECTED]> wrote:
> Of course, taking the nth root is multi-valued, so if you're to return a
> single value, you must choose a convention. Many implementations I have
> seen choose the solution with lowest argument (i.e. the first solution
> encounted by a count
Another way of understanding the terminology is this:
A "dependent product" type (usually written \Pi x:A.B) can be thought of
as a big product of the types (B[a1/x], ..., B[aN/x]) for the
inhabitants a1...aN of the type A. To introduce a dependent product, you
have to provide each component of t
On 8/4/07, Dan Piponi <[EMAIL PROTECTED]> wrote:
>
> On 8/4/07, Albert Y. C. Lai <[EMAIL PROTECTED]> wrote:
> > There is no reason to expect complex ** to agree with real **.
>
> There's every reason. It is standard mathematical practice to embed
> the integers in the rationals in the reals in the
On Sat, 2007-08-04 at 23:25 +0800, Shin-Cheng Mu wrote:
>
[...]
> In Haskell, the existential quantifier is mimicked by forall.
> We define:
>
> > data DepSum a p = forall i . DepSum (a i) (p i)
>
> The term "dependent sum" is borrowed from the Omega tutorial
> of Sheard, Hook, and Linger [2] (
On 8/4/07, Albert Y. C. Lai <[EMAIL PROTECTED]> wrote:
> There is no reason to expect complex ** to agree with real **.
There's every reason. It is standard mathematical practice to embed
the integers in the rationals in the reals in the complex numbers and
it is nice to have as many functions as
Andrew Coppin wrote:
> 0^2
0
> (0 :+ 0)^2
0 :+ 0
> 0**2
0
> (0 :+ 0)**2
NaN :+ NaN
There is nothing wrong AFAIK. (How much do I know? BSc in math, went
through classes on real analysis and complex analysis.)
There is no reason to expect complex ** to agree with real **.
Real x**y is
Hello Brandon,
Saturday, August 4, 2007, 8:44:46 PM, you wrote:
> That would be why I'm using a language which lets me compose things
> in complex ways. And just once, abstracting it away into a library,
> which you seem to be missing.
and you hate 'do' syntax sugar?
--
Best regards,
Bulat
Hi
If you just use Catch (http://www-users.cs.york.ac.uk/~ndm/catch/):
> > foo x
> >| x < 0 = ...
> >| x == 0 = ...
> >| x > 0 = ...
This gives an error. Something identical to this code is in
Data.FiniteMap, and indeed, when using floats and NaN's (or just silly
Ord classes) you ca
On Sat, Aug 04, 2007 at 04:38:08PM +0100, Andrew Coppin wrote:
>
> BTW, I recently had some code like this:
>
> foo x
>| x < 0 = ...
>| x == 0 = ...
>| x > 0 = ...
>
> I was most perplexed when I got a "non-exhaustive patterns" exception...
> It turns out there was a NaN in there.
Infinity is a very slippery concept, you can't compute with it like that.
You can compute various limits, though.
So, e.g., for a > 0
lim x*a -> Inf
x->Inf
and
lim x*0 -> 0
x->Inf
But
lim x*(1/x) -> 1
x->Inf
And that last one would be "Inf*0" in the limit. In fact, you can make
Inf*0 a
Um... why would infinity * 0 be NaN? That doesn't make sense...
Infinity times anything is Infinity. Zero times anything is zero. So
what should Infinity * zero be? There isn't one right answer. In
this case the "morally correct" answer is zero, but in other contexts
it might be Infinit
The Haskell type class RealFloat has a reasonable number of operations to
test for NaN, denormalized numbers, etc.
You can also ask if the implementation uses IEEE.
-- Lennart
On 8/4/07, Paul Johnson <[EMAIL PROTECTED]> wrote:
>
> Andrew Coppin wrote:
> > Paul Johnson wrote:
> >> > log 0
> >> -
Also see
http://hal.archives-ouvertes.fr/hal-00128124
before you start on any serious numerical software.
Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Andrew Coppin wrote:
Paul Johnson wrote:
> log 0
-Infinity
Oh. So... since when does Haskell know about infinity?
I should have mentioned that the underlying platform in my case is an
Intel P4. Haskell does not specify a floating point implementation; the
assumption is that it uses whatever t
Andrew Coppin wrote:
It's news to me that the IEEE floating point standard defines
infinity. (NaN I knew about...)
See http://en.wikipedia.org/wiki/IEEE_754
Paul.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/li
Shin-Cheng Mu wrote:
> I am curious about the possibility of developing Haskell programs
> spontaneously with proofs about their properties and have the
> type checker verify the proofs for us, in a way one would do in
> a dependently typed language.
>
> In the exercise below, I tried to redo part
On Aug 4, 2007, at 11:48 , Bulat Ziganshin wrote:
Hello Brandon,
Saturday, August 4, 2007, 7:27:16 PM, you wrote:
On Aug 4, 2007, at 11:19 , Bulat Ziganshin wrote:
and use it. want to assign a=b/(c+d)? nothing can be easier! just
define one more macro!
And? Everything above machine co
Lennart Augustsson wrote:
Haskell doesn't know much about infinity, but Haskell implementations
are allowed to use IEEE floating point which has infinity.
And to get things right, there needs to be a few changes to the
library to do the right thing for certain numbers, this is not news.
In fac
I think that defining lifted versions of every function is dangerous,
especially in a widely-used library. Monadic code will start to look
pure, and before long someone will be using let expressions and where
blocks to share monadic computations rather than using do blocks to
share the *results*
On 8/4/07, Shin-Cheng Mu <[EMAIL PROTECTED]> wrote:
> Unfortunately, unlike Omega, Haskell does not provide type
> functions.
Something similar is coming:
http://haskell.org/haskellwiki/GHC/Indexed_types#Instance_declarations_2
> Haskell does not know that Plus m n is actually
> a function and c
Hello Claus,
Saturday, August 4, 2007, 7:55:18 PM, you wrote:
>>> so, there could be a library defining
>>
>>> lhs ==: rhs = putMVar <$> lhs <*> rhs
> the lifted operations combine as the unlifted ones do. so there's
> one definition each for =, /, +, not one definition for each of
> their
so, there could be a library defining
lhs ==: rhs = putMVar <$> lhs <*> rhs
ouch! since putMVar is already impure, there's a join missing:
lhs ==: rhs = putMVar <$> lhs <*> rhs
and in your application code, you could write
newEmptyMVar ==: putStrLn "hi there"
.. rant deleted
Hello Brandon,
Saturday, August 4, 2007, 7:27:16 PM, you wrote:
> On Aug 4, 2007, at 11:19 , Bulat Ziganshin wrote:
>> and use it. want to assign a=b/(c+d)? nothing can be easier! just
>> define one more macro!
> And? Everything above machine code is just "macros" at various
> levels of abst
Haskell doesn't know much about infinity, but Haskell implementations are
allowed to use IEEE floating point which has infinity.
And to get things right, there needs to be a few changes to the library to
do the right thing for certain numbers, this is not news. In fact I filed a
bug report a while
Hi Claus,
> but the point is that you have a standard set of operations
> when working at that level, including conditionals, assignments,
> pointer increments, read/write, etc. you only need to define
> lifted variants of each of those operations *once*, in a library.
I think that defining lift
Paul Johnson wrote:
Andrew Coppin wrote:
> 0**2
0
> (0 :+ 0)**2
NaN :+ NaN
(Is this a bug?)
According to the Standard Prelude,
# x ** y = exp (log x * y)
I had a feeling this would be the cause.
> log 0
-Infinity
Oh. So... since when does Haskell know about infinity?
BTW,
On Aug 4, 2007, at 11:19 , Bulat Ziganshin wrote:
and use it. want to assign a=b/(c+d)? nothing can be easier! just
define one more macro!
And? Everything above machine code is just "macros" at various
levels of abstraction, including all our favorite higher-level
abstractions.
--
bran
I am curious about the possibility of developing Haskell programs
spontaneously with proofs about their properties and have the
type checker verify the proofs for us, in a way one would do in
a dependently typed language.
In the exercise below, I tried to redo part of the merge-sort
example in Al
Hello Claus,
Saturday, August 4, 2007, 6:57:13 PM, you wrote:
> so, there could be a library defining
> lhs ==: rhs = putMVar <$> lhs <*> rhs
> and in your application code, you could write
> newEmptyMVar ==: putStrLn "hi there"
> (not that this would be useful;-)
it's great! how fools
Andrew Coppin wrote:
> 0**2
0
> (0 :+ 0)**2
NaN :+ NaN
(Is this a bug?)
According to the Standard Prelude,
# x ** y = exp (log x * y)
So 0 ** 2 is equivalent to exp (log 0 * 2)
> log 0
-Infinity
> log 0 * 2
-Infinity
> exp (log 0 * 2)
0.0
On to the complex number case. From
i know that it may be trsanslated to everything including pure
assembler. what i'm missing in current Haskell is USEFUL SYNTAX for
these expressions. adding tons of liftM and ap can't make me happy
but the point is that you have a standard set of operations
when working at that level, including
> 0^2
0
> (0 :+ 0)^2
0 :+ 0
> 0**2
0
> (0 :+ 0)**2
NaN :+ NaN
(Is this a bug?)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Hello Claus,
Saturday, August 4, 2007, 3:06:11 PM, you wrote:
>> can you give translation you mean? i don't have anything against
>> combinators, they just need to be easy to use, don't forcing me to
>> think where i should put one, as i don't think with lazy code and C
>> imperative code. and th
can you give translation you mean? i don't have anything against
combinators, they just need to be easy to use, don't forcing me to
think where i should put one, as i don't think with lazy code and C
imperative code. and they shouldn't clatter the code, too. just try to
write complex expression us
Hello apfelmus,
Saturday, August 4, 2007, 12:18:33 PM, you wrote:
> Then, mytransaction reads
> mytransaction = return foo `apT` xvar0 `apT` xvar1 `apT` ...
how about a+b*(c+d)?
--
Best regards,
Bulatmailto:[EMAIL PROTECTED]
__
Sebastian Sylvan wrote:
> Claus Reinke wrote:
>>> mytransaction = do {
>>> x0 <- readTVar xvar0
>>> x1 <- readTVar xvar1
>>> :
>>> xn <- readTVar xvarn
>>> return $ foo x0 x1 .. xn
>>> }
>>
>> ah, a concrete example. but isn't that the typical use case for ap?
>>
>> mytransaction = foo `liftM`
41 matches
Mail list logo
