oxware:
> I use "system" in System.Cmd to execute a shell cmd, then how can I
> catch its stdout?
Use System.Process,
http://haskell.org/ghc/docs/latest/html/libraries/base/System-Process.html
And example, call the 'date' program:
> (inh,outh,errh,pid) <- runInteractiveProcess "date" ["+%d:
I use "system" in System.Cmd to execute a shell cmd, then how can I
catch its stdout?
--
Sincerely,
Forest Liu(刘云�S)
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-caf
I am new to haskell, and now working on embedding haskell into html.
Thus we will write webapp using haskell as server-side language like
php. Here I explain my plan and ask some questions, looking for
experienced ones to discuss with.
It is not proper embedding lines of haskell code into html (l
I know Peter Moberg at Chalmers was working on some PDF stuff. You
might want to try to get hold of him and ask.
Cheers,
Johan
On 1/24/07, Clifford Beshers <[EMAIL PROTECTED]> wrote:
I don't suppose anyone has any Haskell code that understands the PDF
format, do they?
_
On Mon, Jan 08, 2007 at 09:48:09PM +0100, Roberto Zunino wrote:
> Robin Green wrote:
> >Well, not really - or not the proof you thought you were getting. As I
> >am constantly at pains to point out, in a language with the possibility
> >of well-typed, non-terminating terms, like Haskell, what you a
On Tue, Jan 23, 2007 at 10:25:27PM -0500, Steve Downey wrote:
> (overall context - working through TaPL on my own, reimplemnting
> typecheckers in haskell)
> the type checkers all follow the same pattern, in ocaml they throw an
> exception when the small step fails, which may mean taking another
>
On Jan 23, 2007, at 5:13 PM, Clifford Beshers wrote:
I don't suppose anyone has any Haskell code that understands the
PDF format, do they?
I know of one, though I'm not sure how complete it is:
http://www.alpheccar.org/en/soft/hpdf
I know it can create PDF files. I'm not sure if it can
(overall context - working through TaPL on my own, reimplemnting
typecheckers in haskell)
the type checkers all follow the same pattern, in ocaml they throw an
exception when the small step fails, which may mean taking another
branch in the eval, but that that sub expression has hit bottom.
it is
On Tue, Jan 23, 2007 at 04:10:10PM -0800, Bryan O'Sullivan wrote:
> John Meacham wrote:
> >I would think this would be how the haskell 98 standard library CPUTime
> >is implemented, is it not?
>
> No. System.CPUTime gives you an approximate idea of the amount of CPU
> time your process, and all
I don't suppose anyone has any Haskell code that understands the PDF
format, do they?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
On 1/23/07, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
generate financial models for execution by clusters running Excel.
There used to be, on Slashdot, a saying: "Now imagine a Beowulf
cluster of these!" :)
Cheers,
Alexy
___
Haskell-Cafe mailing l
I don't think disallowing seq for functions makes them any more
second class than not allow == for functions. I'm willing to
sacrifice seq on functions to get parametricity back.
There is a good reason seq cannot be defined for functions in
the pure lambda calculus... It doesn't belong there. :)
Hello,
On 1/23/07, Bryan O'Sullivan <[EMAIL PROTECTED]> wrote:
Tim Docker wrote:
> I'm not aware of any ongoing haskell work in finance, other that
> some private work being done by Alain Cremieux, reported in the HCAR.
Lennart Augustsson works for Credit Suisse, using a Haskell DSEL to
genera
On Tue, 23 Jan 2007, Alexy Khrabrov wrote:
I wonder if that's another reason OCaml is used in a(t least one)
hedge fund -- why Jane St. preferred OCaml to Haskell, I wonder? Was
it the state of affairs then that OCaml was more efficient (? --
WAGuess), and would they prefer Haskell now? I'm tr
John Meacham wrote:
I would think this would be how the haskell 98 standard library CPUTime
is implemented, is it not?
No. System.CPUTime gives you an approximate idea of the amount of CPU
time your process, and all its threads, have used. The rdtsc
instruction gives you a snapshot of the c
I would think this would be how the haskell 98 standard library CPUTime
is implemented, is it not?
http://haskell.org/onlinereport/cputime.html
John
--
John Meacham - ⑆repetae.net⑆john⑈
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
htt
On Mon, Jan 22, 2007 at 09:37:21PM -0500, Bryan Donlan wrote:
> Or you can get the best of both worlds by using Data.ByteString.Lazy :)
> Even with laziness, all the indirections that String causes hurts
> performance.
actually, strictness analysis is really good at unboxing things like
this, so
Dan Piponi wrote:
No, definitely the new one. The old one is:
newtype ListT m a = ListT { runListT :: m [a] }
which treats the entire list as one uninterleavable lump.
The new one is:
data MList' m a = MNil | a `MCons` MList m a
type MList m a = m (MList' m a)
newtype ListT m a = ListT { run
Tim Docker wrote:
I'm not aware of any ongoing haskell work in finance, other that
some private work being done by Alain Cremieux, reported in the HCAR.
Lennart Augustsson works for Credit Suisse, using a Haskell DSEL to
generate financial models for execution by clusters running Excel.
(Thi
On Jan 23, 2007, at 10:37 PM, Tim Docker wrote:
I'm not aware of any ongoing haskell work in finance,
I'm gearing up to do something but don't have anything to show yet.
I'd be happy to learn of any more, however. I don't think there's any
reasons right now why one ought to favour ocaml ove
Alexy Khabrov wrote:
> I wonder if that's another reason OCaml is used in a(t least one)
> hedge fund -- why Jane St. preferred OCaml to Haskell, I wonder?
Was
> it the state of affairs then that OCaml was more efficient (? --
> WAGuess), and would they prefer Haskell now?
Ocaml definit
Hi Brian,
Brian Hulley wrote:
I thought it was:
return x >>= f = f x
...I think the problem you're encountering is just
that the above law doesn't imply:
(>>= f) . return = f
Sorry, I was not clear.
For the purposes of this thread, I am using the
word "monad" in the category-theoretic
Alexy,
This is a subject near and dear to my heart and I also dabble in Lisp
and Erlang.
Google for "Composing Financial Contracts", you will surely like the
paper. This is the paper that got me started with Haskell. I'm sure
you could do financial data mining in either Lisp, Haskell or O
On Jan 23, 2007, at 15:50 , Neil Mitchell wrote:
> prove/compute anything you couldn't before. While removing _|_ from
> the language does make some things nicer to reason about, there
aren't
> many corners where _|_ really gets in the way that much - seq being
> one of those few corners.
B
I wonder if that's another reason OCaml is used in a(t least one)
hedge fund -- why Jane St. preferred OCaml to Haskell, I wonder? Was
it the state of affairs then that OCaml was more efficient (? --
WAGuess), and would they prefer Haskell now? I'm trying to make sense
out of OCaml objects out o
Brandon S. Allbery KF8NH wrote:
> That's not quite what I was trying to say. (p^~p)->q is equivalent
> to _|_ in the sense that once you derive/compute (respectively) it,
> the "world" in which it exists breaks. (I don't think formal logic
> can have a Haskell-like _|_, but deriving (p^~p)-
Hi
> prove/compute anything you couldn't before. While removing _|_ from
> the language does make some things nicer to reason about, there aren't
> many corners where _|_ really gets in the way that much - seq being
> one of those few corners.
But that is exactly the problem: `seq` forces _|_
On Jan 23, 2007, at 15:34 , Neil Mitchell wrote:
prove/compute anything you couldn't before. While removing _|_ from
the language does make some things nicer to reason about, there aren't
many corners where _|_ really gets in the way that much - seq being
one of those few corners.
But that is
Hi
That's not quite what I was trying to say. (p^~p)->q is equivalent
to _|_ in the sense that once you derive/compute (respectively) it,
the "world" in which it exists breaks.
I think thats a bit overly harsh view of _|_ to take. The world does
not break once you compute _|_ - a _|_ value do
On Jan 23, 2007, at 14:58 , Seth Gordon wrote:
The only catch I see to that POV is that the way `seq` is defined,
"undefined `seq` 42" *must* return an error. If this were
analogous to
"(p^~p)->q", then "undefined `seq` 42" would be allowed to return any
value whatsoever.
That's not quite
On Jan 23, 2007, at 14:48 , Robert Dockins wrote:
Its possible, however, that I don't understand your question. The
formula (p^~p)->q (AKA, proof by contradiction) is valid most
classical and constructive logics that I know of, so I'm not quite
sure what you're getting at.
I'm not expre
Brandon S. Allbery KF8NH wrote:
> Can someone explain to me, given that (a) I'm not particularly expert
> at maths, (b) I'm not particularly expert at Haskell, and (c) I'm a bit
> fuzzybrained of late:
Me too...
> Given that _|_ represents in some sense any computation not
> representable in a
On Jan 23, 2007, at 2:09 PM, Brandon S. Allbery KF8NH wrote:
Can someone explain to me, given that (a) I'm not particularly
expert at maths, (b) I'm not particularly expert at Haskell, and
(c) I'm a bit fuzzybrained of late:
Given that _|_ represents in some sense any computation not
repr
Can someone explain to me, given that (a) I'm not particularly expert
at maths, (b) I'm not particularly expert at Haskell, and (c) I'm a
bit fuzzybrained of late:
Given that _|_ represents in some sense any computation not
representable in and/or not consistent with Haskell, why/how is
r
Yitzchak,
Hmm, I thought it was the old one...
No, definitely the new one. The old one is:
newtype ListT m a = ListT { runListT :: m [a] }
which treats the entire list as one uninterleavable lump.
The new one is:
data MList' m a = MNil | a `MCons` MList m a
type MList m a = m (MList' m a)
Brian Hulley wrote:
Brian Hulley wrote:
Yitzchak Gale wrote:
I wrote:
Prelude> let f = undefined :: Int -> IO Int
Prelude> f `seq` 42
*** Exception: Prelude.undefined
Prelude> ((>>= f) . return) `seq` 42
42
The monad laws say that (>>= f) . return must be
identical to f.
I thought it was:
I wrote:
You have written a great explanation of how
ListT works by writing out its definitions in an
interesting way!
Dan Piponi wrote:
I put quite a bit of time into understanding why the old ListT isn't a
monad [1]. But I thought I didn't yet understand the new one. Now I
see that I did, I
On 1/23/07, Yitzchak Gale <[EMAIL PROTECTED]> wrote:
You have written a great explanation of how
ListT works by writing out its definitions in an
interesting way!
I put quite a bit of time into understanding why the old ListT isn't a
monad [1]. But I thought I didn't yet understand the new one.
Hi
This should clear up some of the questions:
http://haskell.org/hawiki/MonomorphismRestriction
Note to others (esp Cale): does this page not appear on the new wiki?
Thanks
Neil
On 1/23/07, Marco Túlio Gontijo e Silva <[EMAIL PROTECTED]> wrote:
Hello,
I talked for a while with bd_ about t
Hello,
I talked for a while with bd_ about this on #haskell, and I think maybe
I'm just being silly. But I can't get why:
> lambda = \x -> length (show x)
or
> dot = length . show
is different from
> pre x = length $ show x
I read about monomorphism restriction on the haskell 98 report, but
Brian Hulley wrote:
Yitzchak Gale wrote:
I wrote:
Prelude> let f = undefined :: Int -> IO Int
Prelude> f `seq` 42
*** Exception: Prelude.undefined
Prelude> ((>>= f) . return) `seq` 42
42
The monad laws say that (>>= f) . return must be
identical to f.
I thought it was:
return x >>= f = f
Yitzchak Gale wrote:
I wrote:
Prelude> let f .! g = ((.) $! f) $! g
Prelude> let f = undefined :: Int -> IO Int
Prelude> f `seq` 42
*** Exception: Prelude.undefined
Prelude> ((>>= f) . return) `seq` 42
42
Prelude> ((>>= f) .! return) `seq` 42
42
Duncan Coutts wrote:
Perhaps I'm missing someth
Magnus Therning wrote:
I assume you aren't talking about the standard ListT, the one that
forces unnecessary strictness, right? But rather how ListT ought to be
implemented.
Ha! There it is again! :)
Regards,
Yitz
___
Haskell-Cafe mailing list
Haske
Hi,
Lennart Augustsson wrote:
Could you explain why would a class Seq not be sufficient?
If there were a class Seq, I'd not want functions to be in
that class.
Oh, I see. Well that is pretty much the same
as ignoring seq altogether. I am hoping to get
a better answer than that - where we can s
On Tue, Jan 23, 2007 at 11:59:58 +0200, Yitzchak Gale wrote:
>Hi Dan,
>
>You have written a great explanation of how ListT works by writing out
>its definitions in an interesting way!
I assume you aren't talking about the standard ListT, the one that
forces unnecessary strictness, right? But rath
Could you explain why would a class Seq not be sufficient?
If there were a class Seq, I'd not want functions to be in
that class.
-- Lennart
On Jan 23, 2007, at 08:57 , Yitzchak Gale wrote:
I wrote:
Prelude> let f .! g = ((.) $! f) $! g
Prelude> let f = undefined :: Int -> IO Int
Prel
I wrote:
Prelude> let f .! g = ((.) $! f) $! g
Prelude> let f = undefined :: Int -> IO Int
Prelude> f `seq` 42
*** Exception: Prelude.undefined
Prelude> ((>>= f) . return) `seq` 42
42
Prelude> ((>>= f) .! return) `seq` 42
42
Duncan Coutts wrote:
Perhaps I'm missing something but I don't see wh
I've prototyped a fix for this issue which will now only wrap every
585,000 years or so. It also removes the 1/50th of a second timer
resolution for the runtime. This means that the additional 20ms (or
thereabouts) of delay in the wakeup has gone.
This means that GHC is now on a par with any othe
On Tue, 2007-01-23 at 13:35 +0200, Yitzchak Gale wrote:
>
>
> Prelude> let f .! g = ((.) $! f) $! g
> Prelude> let f = undefined :: Int -> IO Int
> Prelude> f `seq` 42
> *** Exception: Prelude.undefined
> Prelude> ((>>= f) . return) `seq` 42
> 42
> Prelude> ((>>= f) .! return) `seq` 42
> 42
>
>
Prelude> let f .! g = ((.) $! f) $! g
Prelude> let f = undefined :: Int -> IO Int
Prelude> f `seq` 42
*** Exception: Prelude.undefined
Prelude> ((>>= f) . return) `seq` 42
42
Prelude> ((>>= f) .! return) `seq` 42
42
Regards,
Yitz
___
Haskell-Cafe ma
John MacFarlane wrote:
> Can anyone help me understand this odd behavior in Text.Regex.Posix (GHC 6.6)?
>
> Prelude Text.Regex.Posix Text.Regex> subRegex (mkRegex "\\^") "he\350llo" "@"
> "[EMAIL PROTECTED]"
>
> Why does /\^/ match \350 here? Generally Text.Regex.Posix seems to work
> fine with
Hi Dan,
You have written a great explanation of how
ListT works by writing out its definitions in an
interesting way!
Dan Piponi wrote:
A slightly different approach that doesn't use anything unsafe:
A list of type [Char] is essentially a
solution to the equation
X = Maybe (Char,X)
Yes. In fa
Conal Elliott wrote:
I'd like to turn source code (mine and others') into a fully hyperlinked
form, in which every name reference links to the name's definition.
Syntax-coloring would be great also. I see Programmatica. Is it in
use, supported, and reasonably easy to install and use? Are th
Hello,
I am pleased to announce "hpaste", the Haskell Paste-bin. Over the
course of this week many of the active #haskell members and I have
been developing this application to provide #haskell with a reliable
paste bot whose features are tuned to the needs of the channel.
Everyone is invited t
54 matches
Mail list logo
