[Haskell-cafe] Announce: hpaste
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 to see hpaste for themselves at http://hpaste.ath.cx:8000 hpaste.org has been registered, and in a few days time will be the permanent home of hpaste. An example of how hpaste was recently used to teach can be seen at http://hpaste.ath.cx:8000/43 A paste-bin is a place for IRC users to paste and annotate code snippets in a stable environment. This keep users from flooding the channel and saves users from having to scroll back constantly to review a paste. hpaste uses haskell syntax coloring (provided by hscolour) and is able to generate a color-coded diff of two pastes to give users an additional tool to share and teach. This project was a wonderful way for me to learn both the old and new HAppS APIs which have both proven to be quite powerful. In addition to providing a web-interface, hpaste is able to announce new pastes to the IRC channel via a bot based on Don Stewart's IRC bot tutorial. darcs has been instrumental in this colaborative effort, and the hpaste source is available with: darcs get --partial http://www.scannedinavian.com/~eric/hpaste Feedback is both encouraged and welcomed! -- Eric Mertens [EMAIL PROTECTED] ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] Hyperlinking source code formatter?
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 there other options? Thanks, If anyone is thinking of writing such a tool, the GHC API would be a great place to start, incedentally. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: IO in lists
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 fact, the type
data Y a = Y (Maybe (a, Y a))
is exactly equivalent to the type [a].
...to intersperse IO along the computation of the list...
define
data X = X { unX :: IO (Maybe (Char,X)) }
So that is exactly equivalent to the type ListT IO Char.
test = X $ do
a - getChar
if a=='q'
then return Nothing
else return (Just (a,test))
That translates to:
test = do
a - liftIO getChar
guard $ a /= 'q'
return $ a `mplus` test
test2 :: X - IO ()
test2 test = do
a - unX test
case a of
Nothing - return ()
Just (a,b) - do
print a
test2 b
Translation:
test2 = runListT . mapM (liftIO print)
Regards,
Yitz
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] strange behavior in Text.Regex.Posix
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 unicode characters. For example, \350 is treated as a single character here: Prelude Text.Regex.Posix Text.Regex subRegex (mkRegex e.l) he\350llo @ [EMAIL PROTECTED] The problem is specific to \350 and doesn't happen with, say, \351: Prelude Text.Regex subRegex (mkRegex \\^) he\351llo @ he\351llo Is this a bug, or just something I'm not understanding? John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe The Text.Regex API calls the regex-posix backend in Text.Regex.Posix which hands off the matching to the (very slow) posix c library. And this library does not know unicode from a hole in the ground -- all Char are truncated to a single byte: chr (ord '\350' `mod` 256) is '^' Thus your pattern, which matches the character '^' will match '\350'. http://darcs.haskell.org/packages/ http://darcs.haskell.org/packages/regex-unstable/ For a full Char matching regex backend you should get regex-parsec. The regex-dfa backend has problems which I have not uploaded the fix to. The regex-pcre backend ought to handle UTF8 -- but you have to handle the conversion to UTF8, for which Data.ByteString will come in handy. The unstable library regex-tdfa is much faster then regex-parsec and is more POSIX compliant than regex-posix. It should go stable within a week. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] IO is not a monad
troll 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 /troll Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
On Tue, 2007-01-23 at 13:35 +0200, Yitzchak Gale wrote: troll 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 /troll Perhaps I'm missing something but I don't see what's wrong. I think what you're saying is that you want (=) to be strict in it's second argument. I don't see that this is a requirement of the monad laws. You'll note that you get the same behaviour for other monads like Maybe and []. I recall that there is some infidelity in standard implementations of the IO monad, but I don't think this is it. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GHC concurrency runtime breaks every 497 (and a bit) days
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 other program, i.e. down to the resolution of the jiifies within the O/S. I've done the non-Windows branch of the GHC.Conc - but I'll need some help with the windows branch. Anyone out there able to help with the intricacies of Windows? Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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 what's wrong. The monad laws say that (= f) . return must be identical to f. The above shows that they are not identical for IO. Therefore, IO is not a monad. I think what you're saying is that you want (=) to be strict in it's second argument. I don't see that this is a requirement of the monad laws. Oh, no, I don't want that at all! Especially not for []! Where would we be then? You'll note that you get the same behaviour for other monads like Maybe and []. Yes. I am starting, as a programmer, from the practical problem that strictness properties are badly broken in MTL. But no one seems to want to fix it. Although it is clear that the current behavior is very wrong, no one seems to be able to define exactly what the correct behavior should be. To understand the problem better myself, I want to understand better the relationship between monads in category theory and strictness. The most common approach seems to be: Make believe that seq does not exist, and use the usual Haskell notions of functions to form a category. Then try to fix up strictness issues as an afterthought, without regard to category theory. The result is a mess. It would be disappointing to me if that is the best we can do. Another approach that we came up with recently on this list is that you can allow seq - in its current form - as a morphism, but use .! instead of . as composition in the category. I find that somewhat attractive, because .! essentially means compose functions while preserving strictness/laziness. Unfortunately, the above paradox shows that this is not the complete answer either. A related issue is the claim that the current behavior of seq is wrong in some way. I am not convinced that there is any problem with the current behavior that \_-_|_ /= _|_, nor that changing it would solve any problems. This paradox also shows that an idea mentioned here a few days ago by Neil Mitchell: class Seq a where seq :: a - b - b is also not sufficient. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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 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 what's wrong. The monad laws say that (= f) . return must be identical to f. The above shows that they are not identical for IO. Therefore, IO is not a monad. I think what you're saying is that you want (=) to be strict in it's second argument. I don't see that this is a requirement of the monad laws. Oh, no, I don't want that at all! Especially not for []! Where would we be then? You'll note that you get the same behaviour for other monads like Maybe and []. Yes. I am starting, as a programmer, from the practical problem that strictness properties are badly broken in MTL. But no one seems to want to fix it. Although it is clear that the current behavior is very wrong, no one seems to be able to define exactly what the correct behavior should be. To understand the problem better myself, I want to understand better the relationship between monads in category theory and strictness. The most common approach seems to be: Make believe that seq does not exist, and use the usual Haskell notions of functions to form a category. Then try to fix up strictness issues as an afterthought, without regard to category theory. The result is a mess. It would be disappointing to me if that is the best we can do. Another approach that we came up with recently on this list is that you can allow seq - in its current form - as a morphism, but use .! instead of . as composition in the category. I find that somewhat attractive, because .! essentially means compose functions while preserving strictness/laziness. Unfortunately, the above paradox shows that this is not the complete answer either. A related issue is the claim that the current behavior of seq is wrong in some way. I am not convinced that there is any problem with the current behavior that \_-_|_ /= _|_, nor that changing it would solve any problems. This paradox also shows that an idea mentioned here a few days ago by Neil Mitchell: class Seq a where seq :: a - b - b is also not sufficient. Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: IO in lists
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 rather how ListT ought to be implemented. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) [EMAIL PROTECTED] Jabber: [EMAIL PROTECTED] http://therning.org/magnus pgpxcsHjtegbV.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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 see how strictness questions fit in with the theory of monads. Anyway - why do you not want seq for functions? Are you making functions second-class citizens in Haskell, so that function-valued expressions can no longer be lazy? If not, then how do you force strictness in a function-valued expression? For example: Prelude Data.List let fs = [const 0, const 1]::[Int-Int] Prelude Data.List let nextf f g = fs !! ((f (0::Int) + g (0::Int))`mod`2) Prelude Data.List :t nextf nextf :: (Int - Int) - (Int - Int) - Int - Int Prelude Data.List foldl' nextf id (concat $ replicate 10 fs) 5 0 Prelude Data.List foldl nextf id (concat $ replicate 10 fs) 5 *** Exception: stack overflow Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: IO in lists
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 Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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 something but I don't see what's wrong. The monad laws say that (= f) . return must be identical to f. I thought it was: return x = f = f x so here the lhs is saturated, so will hit _|_ when the action is executed just as the rhs will. I think the problem you're encountering is just that the above law doesn't imply: (= f) . return = f in Haskell because the lhs is of the form \x - _|_ whereas the rhs, which should really be of the form \x - _|_, is actually _|_ already(!) so the _|_ has effectively been allowed to jump to the left of the arrow hence the inequality detected by seq. Perhaps a solution would be to force _|_ to respect the shape of the type, thus non-terminating values of type a - b would be given the value \_ - _|_ instead of _|_ ? Regards, Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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 x so here the lhs is saturated, so will hit _|_ when the action is executed just as the rhs will. I think the problem you're encountering is just that the above law doesn't imply: (= f) . return = f in Haskell ok so far... because the lhs is of the form \x - _|_ No I got this wrong. Evaluating the lhs to WHNF doesn't hit the _|_. (Incidentally the version using .! evaluates to exactly the same thing since (= f) `seq` ((= f) . return) = ((= f) . return) since (\x - x = f) is already in WHNF afaiu) Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Monomorphism restriction
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 I couldn't find where it explains the reason why these different versions influence on type infer. Thanks for any help. -- malebria Marco Túlio Gontijo e Silva Correio (MSN): [EMAIL PROTECTED] Jabber (GTalk): [EMAIL PROTECTED] Ekiga: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] [EMAIL PROTECTED] Skype: marcotmarcot Telefone: 33346720 Celular: 98116720 Endereço: Rua Paula Cândido, 257/201 Gutierrez 30430-260 Belo Horizonte/MG Brasil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: IO in lists
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. Now I see that I did, I just didn't know that I understood it! :-) -- Dan [1] http://sigfpe.blogspot.com/2006/11/why-isnt-listt-monad.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: IO in lists
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 just didn't know that I understood it! :-) [1] http://sigfpe.blogspot.com/2006/11/why-isnt-listt-monad.html Hmm, I thought it was the old one... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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: return x = f = f x so here the lhs is saturated, so will hit _|_ when the action is executed just as the rhs will. Ooops! But that does not mean the equation holds because for example Prelude (return 3 = f) `seq` 42 42 Prelude (f 3) `seq` 42 *** Exception: Prelude.undefined In the lhs you only hit _|_ when the composite (=) action is actually being executed whereas in the rhs you hit _|_ when computing the function which will return the action to execute so there is difference. Brian. -- http://www.metamilk.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: IO in lists
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)
newtype ListT m a = ListT { runListT :: MList m a }
Note the definition of MList' is isomorphic to a use of Maybe.
--
Dan
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 reasoning about Haskell program behavior in the presence of _|_ *not* like reasoning about logic behavior in the presence of (p^~p)-q? -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 representable in and/or not consistent with Haskell, I'm not sure you've got quite the right notion of what bottom means. There are lots of computations that are representable in Haskell that are equivalent to _|_. _|_ is just a name we give to the class of computations that don't act right (terminate). why/how is reasoning about Haskell program behavior in the presence of _|_ *not* like reasoning about logic behavior in the presence of (p^~p)-q? You seem to be talking around the edges of the Curry-Howard isomorphism. C-H basically says that there is a correspondence between typed lambda calculi and some logical system. Types correspond to logical formulas and lambda terms correspond to proofs. However, a system like Haskell's (where every type is inhabited) corresponds to an inconsistent logic (one where every well- formed statement is provable). That just means that the logic system corresponding to Haskell's type system isn't a very useful one. However, we don't reason _about_ Haskell using that logic, so its not really a problem. 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. Rob Dockins Speak softly and drive a Sherman tank. Laugh hard; it's a long way to the bank. -- TMBG ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 and/or not consistent with Haskell, why/how is reasoning about Haskell program behavior in the presence of _|_ *not* like reasoning about logic behavior in the presence of (p^~p)-q? 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. (Imagine an unsafeSeq operator, such that undefined `unsafeSeq` 42 could *either* raise an exception or return 42, and implementations would be free to replace a `unsafeSeq` b with b when optimizing. Would this be useful?) Can we treat a `seq` b as a sort of pragma and not a real function? Does Haskell semantics become tractable again if we treat Haskell excluding seq (and excluding exceptions? and excluding threads?) as a category, and the exceptions as operating on some kind of meta-level? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 expressing myself well, and I don't have the terminology or enough understanding of things like category theory or formal logic to express myself at all clearly. :( I am modeling _|_ in Haskell as a failed computation: either a nonterminating computation, or an impossible operation (e.g. head []). Once you have an actualized _|_ (or a possible one, as when you apply seq to a computation which may be _|_), your entire computation is suspect. I am modeling (p^~p)-q in logic as a failed production: once you have produced it, your entire logical production is suspect. It seems to me that the recent discussions about forcing strictness are deliberately introducing the equivalent of (p^~p)-q, and it's not clear to me that you can really reason about the resulting behavior. The recent discussions which have seq (or alternatives) leading to theoretical difficulties seem to bear this out. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 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)-q is close to it in effect.) -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 doesn't allow you to 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. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 exactly the problem: `seq` forces _|_ to get into the way, when it normally doesn't. So I'm not clear that trying to fit `seq` into a formalization of Haskell's semantics is the way to go. -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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 _|_ to get into the way, when it normally doesn't. So I'm not clear that trying to fit `seq` into a formalization of Haskell's semantics is the way to go. Agreed, that was the point I was trying to make :) You seemed to be suggesting _|_ was evil (for want of a more precise term) in its behaviour with Haskell. As you seem to say now (and I agree), _|_ is a perfectly useful value, just seq gets in the way. Thanks Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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)-q is close to it in effect.) Here's a couple of papers you might like... Fast and Loose Reasoning is Morally Correct http://web.comlab.ox.ac.uk/oucl/work/jeremy.gibbons/publications/fast+loose.pdf Precise Reasoning About Non-strict Functional Programs How to Chase Bottoms, and How to Ignore Them http://www.cs.chalmers.se/~nad/publications/danielsson-lic.pdf Total Functional Programming http://www.jucs.org/jucs_10_7/total_functional_programming/jucs_10_07_0751_0768_turner.pdf Greg Buchholz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings in Haskell
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 of that already infamously annoying Practical OCaml book, and class object blah... doesn't look like much, not to say that class object sounds about as bad as most English in that book. (Written by an English major... What a decline in US education! :) I come from ML background, so Haskell laziness and OCaml objects are all new to me. But my Haskell book, Haskell School of Expression, is so much better written, that I'm reading it much faster. I'm CC'ing Yaron as his e-mail comes up in my Gmail context adwords on the word Haskell. :) I'm interested in financial data mining and market modeling -- are there any good application of FP there, say in Lisp? Cheers, Alexy P.S. Somebody with an old-fashioned mail client please feel free to change the subject to Financial Engineering with FP, gmail seems to etch its subjects in stone. :) On 1/23/07, Martin Jambon [EMAIL PROTECTED] wrote: On Mon, 22 Jan 2007, Alexy Khrabrov wrote: Greetings -- I'm looking at several FP languages for data mining, and was annoyed to learn that Erlang represents each character as 8 BYTES in a string which is just a list of characters. Now I'm reading a Haskell book which states the same. Is there a more efficient Haskell string-handling method? Which functional language is the most suitable for text processing? In OCaml, strings are compact sequences of bytes. And you can pass them as-is to C functions: http://caml.inria.fr/pub/ml-archives/caml-list/2002/08/e109df224ff0150b302033e2002dbf87.en.html Martin -- Martin Jambon http://martin.jambon.free.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad (and seq, and in general _|_)
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. But that is exactly the problem: `seq` forces _|_ to get into the way, when it normally doesn't. So I'm not clear that trying to fit `seq` into a formalization of Haskell's semantics is the way to go. Agreed, that was the point I was trying to make :) You seemed to be suggesting _|_ was evil (for want of a more precise term) in its behaviour with Haskell. As you seem to say now (and I agree), _|_ is a perfectly useful value, just seq gets in the way. I think at this point I can finally say what I was trying to grasp at (and missing, although I was in the right ballpark at least): It seems to me that the notion of reasoning about Haskell programs in terms of category theory works because category theory is in some sense inherently lazy, whereas (for example) formal logic is inherently strict. So the problem with reasoning about `seq` is that it changes/breaks (depending on how you look at it) the model. Now: either one can come up with a way to model strictness in category theory (compare, for example, modeling I/O in pure functional languages by means of monads), or one can accept that forcing strictness requires reasoning via a different model. Either way, `seq` (or strictness in general) is not really evil. (And neither is _|_.) -- brandon s. allbery[linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [openafs,heimdal,too many hats] [EMAIL PROTECTED] electrical and computer engineering, carnegie mellon universityKF8NH ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Financial Engineering with Haskell
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 OCaml. I think what matters most is being able to compose and specify what you want to do as opposed to how. You could compose your contracts in Lisp but it would not be as elegant as in Haskell. You would need to deal with layers and layers of macros, wrapping your head around the prefix notation and having to add laziness to prevent your data structure from always being evaluated. Lastly, you would want to apply different methods to your engineered contracts, e.g. to price them or print them as documents. There's no pattern matching in Lisp or guards for that matter. This means that you would need to resort to lots of imperative code and case statements that check the type of the data structure passed in to special-process it. Yes, you could add pattern matching to Lisp but it's not natural or that elegant. Yes, you could accomplish the same goal with CLOS, i.e. objects and methods. You could do the same in C++, Python or many other languages. Haskell is uniquely suitable for financial engineering. The boon of Haskell is being able to build a lazy data structure in memory to describe your financial contract, then use pattern matching and guards to deconstruct this data structure and slice it and dice it as you see fit, without having to evaluate it fully and running out of memory in doing so. The boon Haskell is being able to do this cleanly, elegantly and succinctly, without the need for extra helping layers of code. The bane of Haskell is not being able to predict the performance in doing the above. This may not be the reason why Yaron chose to use OCaml at Jane St a few years ago but this is certainly the reason why anyone would hesitate to use Haskell for the same purpose now. Haskell performance optimization is still black art and a few bits of magic. Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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 sense. The monad axioms are stated in terms of morphisms and composition in the category. If we then define - in the category - for each morphism f, a morphism (= f) = join . fmap f then we can derive the identities (= return) = id (= f) . return = f (= g) . (= f) = (= (= g) . f) directly from the monad axioms. Assume, for now, that morphisms in the category will exactly correspond to functions in Haskell. Then the above identities will be the conditions for a monad in Haskell. The conditions for a monad in Haskell are usually stated in the non-points-free form, presumably for clarity. But as you pointed out, that is _not_ equivalent to the above when we are being careful about strictness. My challenge is: 1. Find a way to model strictness/laziness properties of Haskell functions in a category in a way that is reasonably rich. 2. Map monads in that category to Haskell, and see what we get. 3. Compare that to the traditional concept of a monad in Haskell. Is this possible? Any more ideas how to proceed? I told you this was a troll. :) Thanks, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Strings in Haskell
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 definitely has more visibility in finance, due to at least two real world uses: - at Jane St Capital - The lexifi contract description language (www.lexifi.com) 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. 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 over haskell in this domain. Tim ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings in Haskell
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 over haskell in this domain. The reason OCaml was used for LexiFi was _not_ performance. I think Jean-Marc Eber was just a big OCaml user and shared offices or was close to the OCaml team at INRIA. The reason Jane St. is usign OCaml is definitely performance. These guys are trying to shave milliseconds of their processing time. The reason I want to use Haskell where OCaml seems to be more appropriate is because I'm stubborn and a sucker for punishment :-). OCaml also doesn't hold a candle to Haskell in elegance. Think let ... in ..., begin ... end or parens instead of the same, rules for using 'and' in function clauses, etc. etc. etc. I like elegance and hope that performance will catch up, specially with the great strides made in binary IO and data-parallel Haskell. Joel -- http://wagerlabs.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings in Haskell
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. (This I gleaned from him in IRC the other day; apologies to Lennart if I misremember the specifics.) I believe that Goldman Sachs might be using Haskell, too, but I don't know for sure (they have at least one ex-Yale FRP person, at any rate). Wall Street has long had a fondness for esoteric technologies (APL, Linda, you name it). I'm sure there are more Haskell users lurking there somewhere. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings in Haskell
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 the indirections probably hurt less than one would initially think. I think the main issue with string processing speed is not so much the representation of characters, it is that the natural way to express algorithms in haskell is always a character at a time, rather than working on chunks of text at once. of course, Data.ByteStream can let you do this too, but you start to diverge from idiomatic haskell. Not that that is inherently the case forever. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Package rdtsc for reading IA-32 time stamp counters
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 http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announce: Package rdtsc for reading IA-32 time stamp counters
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 current CPU's cycle counter, regardless of who (if anyone) has been burning those cycles. b ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskell vs. OCaml (was: Strings in Haskell)
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 trying to make sense out of OCaml objects out of that already infamously annoying Practical OCaml book, and class object blah... doesn't look like much, not to say that class object sounds about as bad as most English in that book. (Written by an English major... What a decline in US education! :) According to people's reviews, that book is just as bad as the sample chapter (chapter 6), which is like the worst technical book ever. You'd better read Jon Harrop's book Objective Caml for Scientists, or use online resources. (I am being off-topic?) Martin -- Martin Jambon http://martin.jambon.free.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings in Haskell
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 generate financial models for execution by clusters running Excel. (This I gleaned from him in IRC the other day; apologies to Lennart if I misremember the specifics.) I believe that Goldman Sachs might be using Haskell, too, but I don't know for sure (they have at least one ex-Yale FRP person, at any rate). Wall Street has long had a fondness for esoteric technologies (APL, Linda, you name it). I'm sure there are more Haskell users lurking there somewhere. I work at Deutsche Bank. I am using Haskell to manage several databases, using HDBC and HAppS, and do some data mining and (light) numerical calculation. -Jeff ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO is not a monad
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. :) -- Lennart On Jan 23, 2007, at 11:06 , Yitzchak Gale wrote: 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 see how strictness questions fit in with the theory of monads. Anyway - why do you not want seq for functions? Are you making functions second-class citizens in Haskell, so that function-valued expressions can no longer be lazy? If not, then how do you force strictness in a function-valued expression? For example: Prelude Data.List let fs = [const 0, const 1]::[Int-Int] Prelude Data.List let nextf f g = fs !! ((f (0::Int) + g (0::Int)) `mod`2) Prelude Data.List :t nextf nextf :: (Int - Int) - (Int - Int) - Int - Int Prelude Data.List foldl' nextf id (concat $ replicate 10 fs) 5 0 Prelude Data.List foldl nextf id (concat $ replicate 10 fs) 5 *** Exception: stack overflow Regards, Yitz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Strings in Haskell
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 list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] PDF library?
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
Re: [Haskell-cafe] Announce: Package rdtsc for reading IA-32 time stamp counters
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 its threads, have used. The rdtsc instruction gives you a snapshot of the current CPU's cycle counter, regardless of who (if anyone) has been burning those cycles. ah, of course. I made the same mistake before. carry on. :) the linux kernel source has readtsc equivalants for a bunch of different architectures, a simple CPP switch would allow support for most everything. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] small step evaluation as an unfold?
(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 self admittedly not good ocaml, and it seems to be even worse haskell, as i try to extend the simple evaluator i have to deal with managing reporting errors. having the single small step evaluator return a Maybe is fairly close. then the evaluator above it just bottoms out when eval1 expr returns Nothing, by passing expr back up as the result. but it occurs to me that it might be better to express it as an unfold, where the result is a list with the last element as the irresucible expression. or am i insane / intoxicated ? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PDF library?
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 read them. Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] small step evaluation as an unfold?
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 branch in the eval, but that that sub expression has hit bottom. it is self admittedly not good ocaml, and it seems to be even worse haskell, as i try to extend the simple evaluator i have to deal with managing reporting errors. having the single small step evaluator return a Maybe is fairly close. then the evaluator above it just bottoms out when eval1 expr returns Nothing, by passing expr back up as the result. but it occurs to me that it might be better to express it as an unfold, where the result is a list with the last element as the irresucible expression. you would probably be interested in the helium type checker, which is designed to give excellent error messages above all else. Basically, what it does (up to my understanding) is perform a standard type-inference traversal of your code, but rather than unify things as it comes to them, it collects a set of constraints of what to unify with what. then, once they are all collected, it can use a variety of constraint solving techniques, whichever produces the best messages. it even allows users to annotate their routines with specialized constraint solving strategies and type error messages. it is really quite neat. http://www.cs.uu.nl/helium/documentation.html John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] GADTs are expressive
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 actually get is a partial proof - that *if* the expression you are demanding terminates, you will get a value of the correct type. I only want to point out that the above terminates actually is can be put in NF, since putting the expression in WHNF is not enough. In other words, you need deepSeq, not seq when forcing/checking proofs. To partially mitigate this problem, I believe strictness annotations can be used, as in jhc allows (in special cases at the moment, in full generality hopefully soon) the declaration of new strict boxed types. data StrictList a :: ! = Cons a (StrictList a) | Nil I think this could be used to help the situation, as absence analysis can discard unused portions since there is no need to deepSeq everything. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] PDF library?
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? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] embedding haskell into html
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 (like php). Because we would not know what to output, as it is not a procedural language as php. I think the proper way is using a single tag containing a haskell expression (usually a function name) each time of needing haskell. I call it hasp standing for HASkell Page :). It should look like: html headtitle?hasp genTitle?/title/head body ...some html... ?hasp getDataFromDB? ...some html... /body /html And the functions (genTitle, getDataFromDB) should be implemented in /same_dir_to_hasps/hs/same_name_to_each_hasp.hs . It just like the templates in php. There are two possible ways to implementing the mechanism: compiled-CGI, and interpreting(or Just-In-Time Compilation) 1. Complied-CGI: use a preprocessor to combine the hasp templates and hs implementations, then compiled by ghc to generate cgi-bins. That should be easy for me to implement. 2.Interpreting (or JIT-Compilation) I prefer this method because modern web-scripting programmers should be familiar with it. The browser request for somepage.hasp, and Apache knows giving it to hasp interpreter to handle. I am facing to the dilemma between interpreting or JIT-Compilation. The best situation is a perfect haskell interpreting procedure written in haskell. I am trying hs-plugins, and I hope it will help me a lot. Or any other haskell interpreting procedure written in haskell you can tell me? The trouble about JIT-Compilation is that hasp-handler must call ghc through OS shell commandline using System.Cmd, and that is not proper in Apache cgi handler(lots of stuff to configure). BTW, if the haskell interpreting procedure written in haskell does not work well, I could use cmdline ghc -e some_expr file.hs to evaluate the expr, though an ugly way. And in that case, we would face to the problem of external cmd of CGI again. -- Sincerely, Forest Liu(刘云�S) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] catch the stdout when execute a shell cmd
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-cafe
Re: [Haskell-cafe] catch the stdout when execute a shell cmd
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:%m:%y] Nothing Nothing hClose inh hGetContents outh 24:01:07\n Regards, Don There's some wrappers to this floating around too, which should get into base soon enough.. E.g. http://www.cse.unsw.edu.au/~dons/code/newpopen/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
