Re: [Haskell-cafe] Parsec community and up-to-date documentation
* Konstantine Rybnikov [2013-03-25 00:19:04+0200] > Hi! > > I've been busy with (trying to) learning/using parsec lately and as a > beginner had a lot of headache starting from outdated documentation in > various places, lack of more tutorials, confusion between Text.Parsec and > Text.ParseCombinator modules and so on. > > While I solved most of my problems via googling / reading stackoverflow / > reading source code (of outdated version first, btw, the one I got from > Daan's homepage :), I still had a feeling all the time that I'm doing > something wrong and that I can't find place where "party is going on". > > So I wondered, what can I do to create a community around Parsec, to get > issue tracking, pull-requests, up-to-date comprehensive documentation and > tutorials etc.? Parsec seems like a perfect candidate for something like > this. A couple of years ago I decided to do pretty much this — create up-to-date comprehensive documentation for Parsec. Unfortunately, the project turned out too ambitious for me at the time. The only part of it that I've finished is published as this SO answer: http://stackoverflow.com/a/6040237/110081 Of course, SO answers are not a substitute for good documentation, but they are a good way to start, and you can later merge those answers into something more coherent. So this is one way you approach it — just publish the knowledge you've acquired as self-answered questions on SO. Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Munich Haskell Meeting
Dear all, tomorrow, 25th of March, will be our monthly Haskell Meeting in Munich. If you want to join, please go to http://www.haskell-munich.de/dates and click the button. Sorry for the late announcement! I wish everyone of you a nice and successful week, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
On Mon, Mar 25, 2013 at 9:40 AM, Rustom Mody wrote: > - in 1992 it was gofer, the predecessor of haskell > - in 2001 it was scheme. > Sorry typo: 2001 it was python ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
On Mon, Mar 25, 2013 at 4:13 AM, Richard A. O'Keefe wrote: > It's "Backus", people. He was never the god of wine. > > I cannot detect any trace of Backus's FP in Haskell at all. > FP is strict. Haskell is not. > FP is typeless. Haskell is highly typeful. > FP does not name formal parameters. Haskell often does. > FP has roots in APL. Haskell doesn't. > > I don't see any trace of Backus's FP in ML, Clean, or F# either. > > The idea of writing programs by composing lots of small > functions is common to them both, but the idea of > combinators preceded them both. > > I really wonder about this whole discussion -- not the details… the perspective. Its like saying the Ford T http://1.bp.blogspot.com/-KGhxacA_p1k/TV0g_qeHOFI/CF8/5t8NRxpzUCo/s1600/1912-ford-model-t.jpg is an unsafe car http://1.bp.blogspot.com/-7gEOpb7-9IU/TV0g-88-dZI/CF0/u3dh8CXAAGI/s1600/f1244_it0061.jpg and should be equipped with airbags. To the OP: I believe that FP has much to contribute to programming, whether you identify yourself as an FPer or not. - Not the fancy type hackery of modern haskell - Not the math hackery of Backus Just basic stuff like http://blog.languager.org/2012/10/functional-programming-lost-booty.html [Sorry its only an outline and is skimpy] For the most part I agree with the foll -- except the type-classes. > As for > "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose" > the idea is that this ought to be *easier* to understand than > an imperative loop because all of the parts are separated out > instead of being graunched up together. > > inner_product :: Num a => ([a],[a]) -> a > > inner_product = foldr1 (+) . map (uncurry (*)) . uncurry zip > > _is_ expressible in Haskell, although > > inner_product :: Num a => [a] -> [a] -> a > > inner_product = sum . zipWith (*) > > would be more idiomatic. > Personal note: I recently taught a course in Erlang and I did what Ive done for 25 years -- start with FP. In the past its always more or less worked well - in 1988 it was scheme - in 1992 it was gofer, the predecessor of haskell - in 2001 it was scheme. This time I used haskell and the results were not so good, primarily because of typeclasses ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
the package Workflow serialize also the state of a computation, so it can be re-started and continued. It uses also the above mentioned event trick to serialize the state. By the way you can use the workflow monad transformer to recover the state of the game. You don´t need to serialize anything explicitly, the transformer will do it, but your step results must be serializable. If you have this code: loop= do eventhandlercode <- receive handler <- compile eventhandlercode execute handler loop then the lifted process in the workflow monad would be: loop=do eventhandlercode <- step receive handler <- liftIO $ compile eventhandlercode liftIO $ execute handler loop step will store the result and will recover the execution state. Only the step result should be serializable. 2013/3/24 Corentin Dupont > I also came across Scala's Swarm, making use serializable delimited > continuations. Looks good! > http://www.scala-lang.org/node/3485 > > > On Sun, Mar 24, 2013 at 11:13 PM, Michael Better wrote: > >> Isn't this similar to the problem Cloud Haskell had to solve to send code >> to another process to run? >> >> Mike >> On Mar 24, 2013 5:06 PM, "Brandon Allbery" wrote: >> >>> On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont < >>> corentin.dup...@gmail.com> wrote: >>> But I always bothered me that this state is not serializable... >>> >>> >>> I am not quite sure how to respond to that. You seem to be asking for >>> magic. >>> >>> That kind of state has never been sanely serializeable. Not in Haskell, >>> not anywhere else. The usual hack is to dump an entire memory image to >>> disk, either as an executable (see "gcore" and "undump"; also see how the >>> GNU emacs build dumps a "preloaded" emacs executable) or by dumping the >>> data segment as raw bytes and reloading it as such (which doesn't work so >>> well in modern demand paged executables; it can work better with a virtual >>> machine environment, and various Lisp and Smalltalk implementations dump >>> and reload their raw VM images this way). >>> >>> I would not be surprised if what you seem to be asking for turns out to >>> be yet another guise of the halting problem. >>> >>> -- >>> brandon s allbery kf8nh sine nomine >>> associates >>> allber...@gmail.com >>> ballb...@sinenomine.net >>> unix, openafs, kerberos, infrastructure, xmonad >>> http://sinenomine.net >>> >>> ___ >>> 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 > > -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
That is the advantage of recording the sequence of events instead of the final state: that the state don´t need to be seriallizable. And this indeed the way to serlize something that can be decomposed in events. I think that this is elegant.. Specially if the events and the state are elements of a Monoid instance. 2013/3/24 Corentin Dupont > Hi Brandon, > in fact, that's what I'm doing. I record the list of actions performed by > the players, including the submission of the code. I serialize this list of > actions instead of the state of the game. When deserializing, I replay all > the players actions from scratch to get back to the same state than before. > This is the only way to do it (replaying from scratch), since the pieces of > code submitted can interact with other pieces of code submitted earlier: > they are not independant. > But I always bothered me that this state is not serializable... > > > On Sun, Mar 24, 2013 at 10:02 PM, Brandon Allbery wrote: > >> On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont < >> corentin.dup...@gmail.com> wrote: >> >>> Hi Daniel, >>> in my game the handlers are supplied by the players as part of little >>> programs that they submit. An haskell interpreter is reading the program >>> code submitted and inserts it in the game. >>> So there is an infinite number of handlers... >>> >> >> You might store both the compiled code and the originally submitted code, >> and serialize the latter in a form that restart can recompile. I don't >> think that can be any less safe than the original >> submission/compilation/insertion. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec community and up-to-date documentation
On Mon, Mar 25, 2013 at 1:11 AM, Kim-Ee Yeoh wrote:
On Mon, Mar 25, 2013 at 5:19 AM, Konstantine Rybnikov wrote:
> > as a beginner had a lot of headache starting from outdated documentation
> in
> > various places, lack of more tutorials, confusion between Text.Parsec and
> > Text.ParseCombinator modules and so on.
>
> You're indeed right.
>
> > While I solved most of my problems via googling / reading stackoverflow /
> > reading source code (of outdated version first, btw, the one I got from
> > Daan's homepage :), I still had a feeling all the time that I'm doing
> > something wrong and that I can't find place where "party is going on".
>
> If you look at the dates of the papers on Wikipedia [1], the party was
> totally hoppin' in the last decade of the previous century. Not so
> much since. Sigh.
>
> > So I wondered, what can I do to create a community around Parsec, to get
> > issue tracking, pull-requests, up-to-date comprehensive documentation and
> > tutorials etc.? Parsec seems like a perfect candidate for something like
> > this.
>
> While the experience is still fresh in your mind, may I suggest that
> you write a note or two on the most confusing things you encountered
> and how you dealt with them? Making your notes public is a way of
> gathering a community around shared experiences.
>
These things are mostly small ones. The main issue is outdated tutorial [3]
page. From what I can remember now:
1. my confusion definitely began with export-confusion (explaining about
Parsec3 / Parsec2, Text.Parsec and Text.ParseCombinator modules) in various
places (realworldhaskell book [1], parsec's homepage [2])
2. also, while [2] looks like a homepage for parsec, it's also quite old
and points to old version of sources, for example.
2. new parsec3 API (and examples with monad-transformer, parsing of Text)
should be added to [3]. The thing I was looking for (and began implementing
just before I noticed my parsec is too old and new one has what I need) was
also from new API, it was anyToken function. So I was able now to write:
skipWhileNot p =
do { try (lookAhead p) }
<|> do { anyToken;
skipWhileNot p }
combinator that would let me skip pieces of information I can't parse.
3. add type declarations and explanation into [3]
4. documentation [3] should be split into multiple pages with better
navigation
5. not a concrete suggestion, but just adding more examples would be great
I'm sure there were plenty concrete suggestions / small improvements that I
already forgot. I absolutely agree that it's better to write notes when
memories are fresh, that's why I think having issue tracking and ability to
do small pull-requests would really help.
Also, the denizens of the haskell IRC at freenode will gladly converse
> with you about parsec. The same goes for subscribers to this list and
> also haskell-beginners.
>
> [1] http://en.wikipedia.org/wiki/Parser_combinator
>
> -- Kim-Ee
>
It's great that haskell community is such welcome for beginners, thanks.
[1] http://book.realworldhaskell.org/read/using-parsec.html
[2] http://legacy.cs.uu.nl/daan/parsec.html
[3] http://legacy.cs.uu.nl/daan/download/parsec/parsec.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Parsec community and up-to-date documentation
On Mon, Mar 25, 2013 at 5:19 AM, Konstantine Rybnikov wrote: > as a beginner had a lot of headache starting from outdated documentation in > various places, lack of more tutorials, confusion between Text.Parsec and > Text.ParseCombinator modules and so on. You're indeed right. > While I solved most of my problems via googling / reading stackoverflow / > reading source code (of outdated version first, btw, the one I got from > Daan's homepage :), I still had a feeling all the time that I'm doing > something wrong and that I can't find place where "party is going on". If you look at the dates of the papers on Wikipedia [1], the party was totally hoppin' in the last decade of the previous century. Not so much since. Sigh. > So I wondered, what can I do to create a community around Parsec, to get > issue tracking, pull-requests, up-to-date comprehensive documentation and > tutorials etc.? Parsec seems like a perfect candidate for something like > this. While the experience is still fresh in your mind, may I suggest that you write a note or two on the most confusing things you encountered and how you dealt with them? Making your notes public is a way of gathering a community around shared experiences. Also, the denizens of the haskell IRC at freenode will gladly converse with you about parsec. The same goes for subscribers to this list and also haskell-beginners. [1] http://en.wikipedia.org/wiki/Parser_combinator -- Kim-Ee ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A Thought: Backus, FP, and Brute Force Learning
It's "Backus", people. He was never the god of wine. I cannot detect any trace of Backus's FP in Haskell at all. FP is strict. Haskell is not. FP is typeless. Haskell is highly typeful. FP does not name formal parameters. Haskell often does. FP has roots in APL. Haskell doesn't. I don't see any trace of Backus's FP in ML, Clean, or F# either. The idea of writing programs by composing lots of small functions is common to them both, but the idea of combinators preceded them both. As for "Def Innerproduct = (Insert +) o (ApplyToAll x) o Transpose" the idea is that this ought to be *easier* to understand than an imperative loop because all of the parts are separated out instead of being graunched up together. inner_product :: Num a => ([a],[a]) -> a inner_product = foldr1 (+) . map (uncurry (*)) . uncurry zip _is_ expressible in Haskell, although inner_product :: Num a => [a] -> [a] -> a inner_product = sum . zipWith (*) would be more idiomatic. But this is not because of any influence from FP, but because Haskell has function composition and higher order functions. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
On Sun, Mar 24, 2013 at 11:05 PM, Brandon Allbery wrote: > On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont < > corentin.dup...@gmail.com> wrote: > >> But I always bothered me that this state is not serializable... > > > I am not quite sure how to respond to that. You seem to be asking for > magic. > haha as always :) But Haskell is a bit about magic... > > That kind of state has never been sanely serializeable. Not in Haskell, > not anywhere else. The usual hack is to dump an entire memory image to > disk, either as an executable (see "gcore" and "undump"; also see how the > GNU emacs build dumps a "preloaded" emacs executable) or by dumping the > data segment as raw bytes and reloading it as such (which doesn't work so > well in modern demand paged executables; it can work better with a virtual > machine environment, and various Lisp and Smalltalk implementations dump > and reload their raw VM images this way). > > I would not be surprised if what you seem to be asking for turns out to be > yet another guise of the halting problem. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
I also came across Scala's Swarm, making use serializable delimited continuations. Looks good! http://www.scala-lang.org/node/3485 On Sun, Mar 24, 2013 at 11:13 PM, Michael Better wrote: > Isn't this similar to the problem Cloud Haskell had to solve to send code > to another process to run? > > Mike > On Mar 24, 2013 5:06 PM, "Brandon Allbery" wrote: > >> On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont < >> corentin.dup...@gmail.com> wrote: >> >>> But I always bothered me that this state is not serializable... >> >> >> I am not quite sure how to respond to that. You seem to be asking for >> magic. >> >> That kind of state has never been sanely serializeable. Not in Haskell, >> not anywhere else. The usual hack is to dump an entire memory image to >> disk, either as an executable (see "gcore" and "undump"; also see how the >> GNU emacs build dumps a "preloaded" emacs executable) or by dumping the >> data segment as raw bytes and reloading it as such (which doesn't work so >> well in modern demand paged executables; it can work better with a virtual >> machine environment, and various Lisp and Smalltalk implementations dump >> and reload their raw VM images this way). >> >> I would not be surprised if what you seem to be asking for turns out to >> be yet another guise of the halting problem. >> >> -- >> brandon s allbery kf8nh sine nomine >> associates >> allber...@gmail.com >> ballb...@sinenomine.net >> unix, openafs, kerberos, infrastructure, xmonad >> http://sinenomine.net >> >> ___ >> 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] Parsec community and up-to-date documentation
Hi! I've been busy with (trying to) learning/using parsec lately and as a beginner had a lot of headache starting from outdated documentation in various places, lack of more tutorials, confusion between Text.Parsec and Text.ParseCombinator modules and so on. While I solved most of my problems via googling / reading stackoverflow / reading source code (of outdated version first, btw, the one I got from Daan's homepage :), I still had a feeling all the time that I'm doing something wrong and that I can't find place where "party is going on". So I wondered, what can I do to create a community around Parsec, to get issue tracking, pull-requests, up-to-date comprehensive documentation and tutorials etc.? Parsec seems like a perfect candidate for something like this. Thank you. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
Isn't this similar to the problem Cloud Haskell had to solve to send code to another process to run? Mike On Mar 24, 2013 5:06 PM, "Brandon Allbery" wrote: > On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont < > corentin.dup...@gmail.com> wrote: > >> But I always bothered me that this state is not serializable... > > > I am not quite sure how to respond to that. You seem to be asking for > magic. > > That kind of state has never been sanely serializeable. Not in Haskell, > not anywhere else. The usual hack is to dump an entire memory image to > disk, either as an executable (see "gcore" and "undump"; also see how the > GNU emacs build dumps a "preloaded" emacs executable) or by dumping the > data segment as raw bytes and reloading it as such (which doesn't work so > well in modern demand paged executables; it can work better with a virtual > machine environment, and various Lisp and Smalltalk implementations dump > and reload their raw VM images this way). > > I would not be surprised if what you seem to be asking for turns out to be > yet another guise of the halting problem. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > > ___ > 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] Make a DSL serializable
On Sun, Mar 24, 2013 at 5:44 PM, Corentin Dupont wrote: > But I always bothered me that this state is not serializable... I am not quite sure how to respond to that. You seem to be asking for magic. That kind of state has never been sanely serializeable. Not in Haskell, not anywhere else. The usual hack is to dump an entire memory image to disk, either as an executable (see "gcore" and "undump"; also see how the GNU emacs build dumps a "preloaded" emacs executable) or by dumping the data segment as raw bytes and reloading it as such (which doesn't work so well in modern demand paged executables; it can work better with a virtual machine environment, and various Lisp and Smalltalk implementations dump and reload their raw VM images this way). I would not be surprised if what you seem to be asking for turns out to be yet another guise of the halting problem. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.StorableVector vs Data.Vector.Storable
On 25 March 2013 05:04, Roman Cheplyaka wrote: > What is the relationship between these two modules? Do we really need > both? There doesn't seem to be any relationship at all between them... > > (Data.Vector.Storable is part of vector, Data.StorableVector is from a > separate package, storablevector.) Going by the initial release date for the two of them, storablevector is a few months older than vector. Otherwise, it's just like why we have multiple implementations of monad transformer stacks, etc. > > Roman > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
Hi Brandon, in fact, that's what I'm doing. I record the list of actions performed by the players, including the submission of the code. I serialize this list of actions instead of the state of the game. When deserializing, I replay all the players actions from scratch to get back to the same state than before. This is the only way to do it (replaying from scratch), since the pieces of code submitted can interact with other pieces of code submitted earlier: they are not independant. But I always bothered me that this state is not serializable... On Sun, Mar 24, 2013 at 10:02 PM, Brandon Allbery wrote: > On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont < > corentin.dup...@gmail.com> wrote: > >> Hi Daniel, >> in my game the handlers are supplied by the players as part of little >> programs that they submit. An haskell interpreter is reading the program >> code submitted and inserts it in the game. >> So there is an infinite number of handlers... >> > > You might store both the compiled code and the originally submitted code, > and serialize the latter in a form that restart can recompile. I don't > think that can be any less safe than the original > submission/compilation/insertion. > > -- > brandon s allbery kf8nh sine nomine > associates > allber...@gmail.com > ballb...@sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
On Sun, Mar 24, 2013 at 4:16 PM, Corentin Dupont wrote: > Hi Daniel, > in my game the handlers are supplied by the players as part of little > programs that they submit. An haskell interpreter is reading the program > code submitted and inserts it in the game. > So there is an infinite number of handlers... > You might store both the compiled code and the originally submitted code, and serialize the latter in a form that restart can recompile. I don't think that can be any less safe than the original submission/compilation/insertion. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
Hi Daniel, in my game the handlers are supplied by the players as part of little programs that they submit. An haskell interpreter is reading the program code submitted and inserts it in the game. So there is an infinite number of handlers... I was thinking of hiding the parameters of the handlers like this: data Exp a where OnEvent :: EventName -> Exp () -> Exp () getArg :: Exp Int setArg :: Exp () deriving (Show) Now it should be possible to write the Show instance: instance Show a -> Show (Exp a) where ... You could write a program like this: myProgram :: Exp () myProgram = do OnEvent NewPlayer (getArg >>= (\name -> output $ "Hello to player " ++ name)) But I don't find it elegant at all: there is no compile time guaranty that the caller will set the argument correctly as you can have with normal function signatures... Best, Corentin On Sun, Mar 24, 2013 at 6:25 PM, Daniel Trstenjak < daniel.trsten...@gmail.com> wrote: > > Hi Corentin, > > > I have a DSL like this: > > data Exp where > > OnEvent :: EventName -> (Int -> Exp) -> Exp > > (...) > > > > The "OnEvent" element carries a function (the handler to be called when > the > > event happens), and that makes my DSL non showable/serializable. > > How could I fix that? This is a real handicap not to be able to serialize > > the state of my whole application because of that :) > > You could have a unique id for your handlers, which might be > an Int or a String and have some kind of registration for the > handlers. > > data Exp where > OnEvent :: EventName -> HandlerId -> Exp > > type HandlerId = String > type Handler = (Int -> Exp) > type Handlers = HashMap HandlerId Handler > > registerHandler :: Handlers -> (HandlerId, Handler) -> Handlers > getHandler :: Handlers -> HandlerId -> Maybe Handler > > But you have to ensure, that for each application run the same > HandlerId also gets the same Handler. > > > Less flexible but more secure is an ADT for you Handler. > > data Handler = DoThat > | DoSometingElse > > You can than just pattern match on your handler and don't need any kind > of registration. > > > But you can go further and define your own little Handler DSL. > > > Greetings, > Daniel > > ___ > 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] my take at knucleotide
I have placed constraint on version of hashable, time is exactly same.bmaxa@maxa:~/shootout/knucleotide$ cabal list hashable* hashable Synopsis: A class for types that can be converted to a hash valueDefault available version: 1.2.0.5Installed versions: 1.1.2.5Homepage: http://github.com/tibbe/hashableLicense: BSD3 Date: Sun, 24 Mar 2013 20:12:57 +0100 Subject: Re: [Haskell-cafe] my take at knucleotide From: g...@gregorycollins.net To: bm...@hotmail.com CC: haskell-cafe@haskell.org What happens to performance if you compile and link with "cabal install --constraint='hashable < 1.2'" ? G ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] my take at knucleotide
What happens to performance if you compile and link with "cabal install
--constraint='hashable < 1.2'" ?
G
On Sun, Mar 24, 2013 at 4:08 PM, Branimir Maksimovic wrote:
> Hi, I have tried to implement knucleotide benchmark program this time:
>
> http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide
>
> Implementation is shorter (uses hashtable from hashtables package),
> but two time slower then current Haskell entry ( which is too low level
> for my taste :)).
> What is interesting is that if I try to place Int64 as a key to
> hash table, performance is even slower.
> Strange that dropping and taking from bytestring would be
> faster than packing string in 64 bit int and directly indexing.
>
> If someone can see something that can bring performance on par
> with current haskell entry , I would post it , otherwise no point,
> except that program is shorter and not low level.
>
> {-# Language BangPatterns #-}
> --
> -- The Computer Language Benchmarks Game
> -- http://benchmarksgame.alioth.debian.org/
> --
> -- Contributed by Branimir Maksimovic
> --
> import Data.Char
> import Data.List
> import Data.IORef
> import qualified Data.HashTable.IO as H
> import qualified Data.ByteString.Char8 as S
> import Control.Concurrent
> import Text.Printf
>
> main = do
> s <- S.getContents
> let content = (S.map toUpper . S.concat . tail .
> dropWhile (\l->not $ S.isPrefixOf (S.pack ">THREE") l) .
> S.lines) s
> mapM_ (execute content) actions
>
> data Actions = I Int | S String
> actions = [I 1,I 2,
>S "GGT",S "GGTA",S "GGTATT",S "GGTAAATT",S
> "GGTAAATTTATAGT"]
> execute content (I i) = writeFrequencies content i
> execute content (S s) = writeCount content s
>
> writeFrequencies input size = do
> ht <- tcalculate input size
> lst <- H.foldM (\lst (k,v)->do
> v' <- readIORef v
> return $ insertBy (\(_,x) (_,y)->y `compare` x) (k,v') lst) [] ht
> let sum = fromIntegral ((S.length input) + 1 - size)
> mapM_ (\(k,v)-> do
> printf "%s %.3f\n"
> (S.unpack k) ((100 * (fromIntegral v)/sum)::Double)) lst
> putChar '\n'
>
> writeCount input string = do
> let size = length string
> ht <- tcalculate input size
> res <- H.lookup ht (S.pack string)
> case res of
> Nothing -> putStrLn $ string ++ " not found..."
> Just v -> do
> r <- readIORef v
> printf "%d\t%s\n" r (string::String)
>
> tcalculate input size = do
> let
> l = [0..7]
> actions = map (\i -> (calculate input i size (length l))) l
> vars <- mapM (\action -> do
> var <- newEmptyMVar
> forkIO $ do
> answer <- action
> putMVar var answer
> return var) actions
> result <- newTable
> results <- mapM takeMVar vars
> mapM_ (\ht -> H.foldM (\lst (k,v) -> do
> res <- H.lookup lst k
> case res of
> Nothing -> do
> r1 <- readIORef v
> r2 <- newIORef r1
> H.insert lst k r2
> Just v1 -> do
> r1 <- readIORef v1
> r2 <- readIORef v
> writeIORef v1 (r1+r2)
> return lst) result ht) results
> return result
>
> calculate input beg size incr = do
> ht <- newTable
> let
> calculate' :: S.ByteString -> Int -> IO HashTable
> calculate' str i
> | i >= ((S.length input)+1 - size) = return ht
> | otherwise = do
> res <- H.lookup ht k
> case res of
> Nothing -> do
> !r <- newIORef 1
> H.insert ht k r
> Just v -> do
> !r <- readIORef v
> writeIORef v (r+1)
> calculate' (S.drop incr str) (i+incr)
> where k = S.take size str
> calculate' (S.drop beg input) beg
>
> type HashTable = H.BasicHashTable S.ByteString (IORef Int)
> newTable :: IO HashTable
> newTable = H.new
>
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
--
Gregory Collins
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.StorableVector vs Data.Vector.Storable
What is the relationship between these two modules? Do we really need both? (Data.Vector.Storable is part of vector, Data.StorableVector is from a separate package, storablevector.) Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Need some advice around lazy IO
Thanks for the pointer Mukesh I'll go over the blog. Changing the xml parser to another one from hackage - xml - helped but not fully. I think I would need to change to bytestring. But for now, I split the program into smaller programs and it seems to work. Regards, Kashyap On Sat, Mar 23, 2013 at 11:55 AM, mukesh tiwari < mukeshtiwari.ii...@gmail.com> wrote: > Hi Kashyap > I am not sure if this solution to your problem but try using Bytestring > rather than String in > > parseXML' :: String -> XMLAST > parseXML' str = > f ast where > ast = parse (spaces >> xmlParser) "" str > f (Right x) = x > > f (Left x) = CouldNotParse > > > Also see this post[1] My Space is Leaking.. > > Regards, > Mukesh Tiwari > > [1] http://www.mega-nerd.com/erikd/Blog/ > > > On Sat, Mar 23, 2013 at 11:11 AM, C K Kashyap wrote: > >> Oops...I sent out the earlier message accidentally. >> >> I got some profiling done and got this pdf generated. I see unhealthy >> growths in my XML parser. >> https://github.com/ckkashyap/haskell-perf-repro/blob/master/RSXP.hs >> I must be not using parsec efficiently. >> >> Regards, >> Kashyap >> >> >> >> >> On Sat, Mar 23, 2013 at 11:07 AM, C K Kashyap wrote: >> >>> I got some profiling done and got this pdf generated. I see unhealthy >>> growths in my XML parser. >>> >>> >>> >>> On Fri, Mar 22, 2013 at 8:12 PM, C K Kashyap wrote: >>> Hi folks, I've run into more issues with my report generation tool I'd really appreciate some help. I've created a repro project on github to demonstrate the problem. git://github.com/ckkashyap/haskell-perf-repro.git There is a template xml file that needs to be replicated several times (3000 or so) under the data directory and then "driver" needs to be run. The memory used by driver keeps growing until it runs out of memory. Also, I'd appreciate some tips on how to go about debugging this situation. I am on the windows platform. Regards, Kashyap On Tue, Mar 19, 2013 at 1:11 PM, Kim-Ee Yeoh wrote: > On Tue, Mar 19, 2013 at 2:01 PM, Konstantin Litvinenko > wrote: > > Yes. You (and Dan) are totally right. 'Let' just bind expression, not > > evaluating it. Dan's evaluate trick force rnf to run before hClose. > As I > > said - it's tricky part especially for newbie like me :) > > To place this in perspective, one only needs to descend one or two > more layers before the semantics starts confusing even experts. > > Whereas the difference between seq and evaluate shouldn't be too hard > to grasp, that between evaluate and (return $!) is considerably more > subtle, as Edward Yang notified us 10 days ago. See the thread titled > To seq or not to seq. > > -- Kim-Ee > > ___ > 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 mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
Hi Corentin, > I have a DSL like this: > data Exp where > OnEvent :: EventName -> (Int -> Exp) -> Exp > (...) > > The "OnEvent" element carries a function (the handler to be called when the > event happens), and that makes my DSL non showable/serializable. > How could I fix that? This is a real handicap not to be able to serialize > the state of my whole application because of that :) You could have a unique id for your handlers, which might be an Int or a String and have some kind of registration for the handlers. data Exp where OnEvent :: EventName -> HandlerId -> Exp type HandlerId = String type Handler = (Int -> Exp) type Handlers = HashMap HandlerId Handler registerHandler :: Handlers -> (HandlerId, Handler) -> Handlers getHandler :: Handlers -> HandlerId -> Maybe Handler But you have to ensure, that for each application run the same HandlerId also gets the same Handler. Less flexible but more secure is an ADT for you Handler. data Handler = DoThat | DoSometingElse You can than just pattern match on your handler and don't need any kind of registration. But you can go further and define your own little Handler DSL. Greetings, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire
Heinrich Apfelmus wrote: > So context has the same purpose as Conal's trim combinator [1]. > However, I believe that it is too inconvenient for managing very > dynamic collections that need to keep track of state, as the context > function significantly limits the scope of the stateful wire. That's > why I've opted for a more flexible approach in Reactive.Banana.Switch > , even if that introduces significant complexity in the type > signatures. Again you are thinking in primitive combinators. Keep in mind that context is nothing primitive. In earlier releases of Netwire I had a "manager" wire that allowed to manage a set of running wires by message passing. However, that wire turned out to be either too generic or too specific. There was no good balance, so I decided to get rid of it altogether. Now every library layer or application would write its own application-specific manager wire. > Again, I would be interested in an implementation of the BarTab > example [2] to compare the two approaches. I'm happy to provide one. Please be patient until I release netwire-vty, a terminal UI library based on Netwire. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Make a DSL serializable
Hi Café, I have a DSL like this: data Exp where OnEvent :: EventName -> (Int -> Exp) -> Exp (...) The "OnEvent" element carries a function (the handler to be called when the event happens), and that makes my DSL non showable/serializable. How could I fix that? This is a real handicap not to be able to serialize the state of my whole application because of that :) Thanks, Corentin ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire
Ertugrul Söylemez wrote:
Heinrich Apfelmus wrote:
I concur that chaining wires with the andThen combinator is very
slick, I like it a lot. Wolfgang Jeltsch recently described a similar
pattern for classical FRP, namely a behavior that doesn't live
forever, but actually ends at some point in time, which can be
interpreted as an event occurrence. ("It ends with a bang!")
Well, that would work, but I wonder why then you wouldn't want to go all
the way to signal inhibition. You don't need AFRP to have it. It's
actually quite a light-weight change. Allow behaviors not to produce a
value, i.e. somewhere in your library replace "a" by "Maybe a".
I think that the andThen combinator is slick, but I'm not sure whether
I find the underlying model -- signal inhibition -- to be equally
pleasing. In the context of GUI programming, chaining several events
with the andThen combinator is almost never needed, so I've postponed
these questions for now.
How would you express the TwoCounters example [1] using dynamic event
switching in netwire? (The example can be implemented without dynamic
event switching, but that's not what I mean.) What about the BarTab
example [2]?
I've been asked that via private mail. Let me just quote my answer:
"This is a misconception caused by the very different nature of
Netwire. In Netwire everything is dynamic. What really happens in
w1 --> w2 is that at the beginning only w1 exists. When it inhibits
it is removed from the network and w2 takes its place. The missing
ingredient is that w2 is not actually produced by a wire, but this
is equally easy and natural. Just consider the context wires:
context id w
This wire will dynamically create a version of 'w' for every
different input, so it acts like a router that will create wires if
they don't already exist. Deletion works similarly:
contextLatest id 1000 w
This is a version that only keeps the 1000 latest contexts.
So context has the same purpose as Conal's trim combinator [1].
However, I believe that it is too inconvenient for managing very dynamic
collections that need to keep track of state, as the context function
significantly limits the scope of the stateful wire. That's why I've
opted for a more flexible approach in Reactive.Banana.Switch , even if
that introduces significant complexity in the type signatures. Again, I
would be interested in an implementation of the BarTab example [2] to
compare the two approaches.
[1]:
http://conal.net/blog/posts/trimming-inputs-in-functional-reactive-programming
[2]: http://www.haskell.org/haskellwiki/Reactive-banana/Examples#bartab
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] my take at knucleotide
Hi, I have tried to implement knucleotide benchmark program this
time:http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=knucleotide
Implementation is shorter (uses hashtable from hashtables package),but two time
slower then current Haskell entry ( which is too low levelfor my taste :)).What
is interesting is that if I try to place Int64 as a key tohash table,
performance is even slower.Strange that dropping and taking from bytestring
would befaster than packing string in 64 bit int and directly indexing.
If someone can see something that can bring performance on parwith current
haskell entry , I would post it , otherwise no point,except that program is
shorter and not low level.
{-# Language BangPatterns #-} The Computer Language Benchmarks Game--
http://benchmarksgame.alioth.debian.org/ Contributed by Branimir
Maksimovic--import Data.Charimport Data.Listimport Data.IORefimport qualified
Data.HashTable.IO as Himport qualified Data.ByteString.Char8 as Simport
Control.Concurrentimport Text.Printf
main = dos <- S.getContentslet content = (S.map toUpper . S.concat .
tail . dropWhile (\l->not $ S.isPrefixOf (S.pack ">THREE") l)
. S.lines) smapM_ (execute content) actions
data Actions = I Int | S Stringactions = [I 1,I 2, S "GGT",S "GGTA",S
"GGTATT",S "GGTAAATT",S "GGTAAATTTATAGT"]execute content (I i) =
writeFrequencies content iexecute content (S s) = writeCount content s
writeFrequencies input size = doht <- tcalculate input sizelst <-
H.foldM (\lst (k,v)->do v' <- readIORef vreturn $ insertBy
(\(_,x) (_,y)->y `compare` x) (k,v') lst) [] htlet sum = fromIntegral
((S.length input) + 1 - size)mapM_ (\(k,v)-> doprintf "%s %.3f\n"
(S.unpack k) ((100 * (fromIntegral v)/sum)::Double)) lstputChar
'\n'
writeCount input string = dolet size = length stringht <- tcalculate
input sizeres <- H.lookup ht (S.pack string)case res of Nothing
-> putStrLn $ string ++ " not found..."Just v -> dor <-
readIORef vprintf "%d\t%s\n" r (string::String)
tcalculate input size = dolet l = [0..7]actions = map (\i
-> (calculate input i size (length l))) lvars <- mapM (\action -> do
var <- newEmptyMVarforkIO $ do
answer <- actionputMVar var answer
return var) actionsresult <- newTableresults <- mapM takeMVar vars
mapM_ (\ht -> H.foldM (\lst (k,v) -> do res <-
H.lookup lst kcase res of
Nothing -> dor1 <- readIORef v
r2 <- newIORef r1
H.insert lst k r2Just v1 -> do
r1 <- readIORef v1r2 <-
readIORef vwriteIORef v1 (r1+r2)
return lst) result ht) resultsreturn resultcalculate
input beg size incr = doht <- newTableletcalculate' ::
S.ByteString -> Int -> IO HashTablecalculate' str i | i >=
((S.length input)+1 - size) = return ht | otherwise = dores
<- H.lookup ht kcase res ofNothing -> do
!r <- newIORef 1H.insert ht k rJust
v -> do!r <- readIORef vwriteIORef v
(r+1)calculate' (S.drop incr str) (i+incr)where k =
S.take size strcalculate' (S.drop beg input) beg
type HashTable = H.BasicHashTable S.ByteString (IORef Int) newTable :: IO
HashTablenewTable = H.new
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire
Heinrich Apfelmus wrote:
> I concur that chaining wires with the andThen combinator is very
> slick, I like it a lot. Wolfgang Jeltsch recently described a similar
> pattern for classical FRP, namely a behavior that doesn't live
> forever, but actually ends at some point in time, which can be
> interpreted as an event occurrence. ("It ends with a bang!")
Well, that would work, but I wonder why then you wouldn't want to go all
the way to signal inhibition. You don't need AFRP to have it. It's
actually quite a light-weight change. Allow behaviors not to produce a
value, i.e. somewhere in your library replace "a" by "Maybe a".
> However, do note that the andThen combinator in netwire can only be so
> slick because "switching restarts time" (as the documentation puts
> it). I don't see a nice way to switch between wires that have
> accumulated state.
Time doesn't necessarily restart. This choice is left to the (-->)
combinator. I've decided for that one to restart time, because it
more closely resembles the behavior of other libraries. As a
counterexample consider this:
time . holdFor 0.5 (periodically 1) <|> 2*time
This wire will switch back and forth between the two wires 'time' and
'2*time' filling the gap between the inactive times of each. Unlike
(-->), the (<|>) combinator keeps state. This is also true for the
context wires (see below).
> How would you express the TwoCounters example [1] using dynamic event
> switching in netwire? (The example can be implemented without dynamic
> event switching, but that's not what I mean.) What about the BarTab
> example [2]?
I've been asked that via private mail. Let me just quote my answer:
"This is a misconception caused by the very different nature of
Netwire. In Netwire everything is dynamic. What really happens in
w1 --> w2 is that at the beginning only w1 exists. When it inhibits
it is removed from the network and w2 takes its place. The missing
ingredient is that w2 is not actually produced by a wire, but this
is equally easy and natural. Just consider the context wires:
context id w
This wire will dynamically create a version of 'w' for every
different input, so it acts like a router that will create wires if
they don't already exist. Deletion works similarly:
contextLatest id 1000 w
This is a version that only keeps the 1000 latest contexts. There
is also the classic dynamic switcher called 'switch':
switch nw w
This wire acts like 'w' until 'nw' produces a new wire, then
switches to that one. Indeed 'nw' is of type Wire e m a (Wire e m a
b).
Really nothing is static in Netwire. It's actually very easy to
write combinators like 'switch' and 'context' yourself. In fact you
can even write a sensible ArrowApply instance. The problem is that
it would have linear time complexity with respect to the number of
instants that have passed, so it's not exactly useful."
Notice that wires (just like all other arrowic automata in Haskell)
switch all the time. Moving forward in time involves switching, so it's
their very nature to do it. They could decide to switch to anything
(provided the types fit) and they can observe the switching of other
wires. There is no need for special library support for wires that
manage a set of wires.
Greets,
Ertugrul
--
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
signature.asc
Description: PGP signature
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Enumerating functions at runtime
All the info is in the .hi files On Sunday, 24 March 2013, Brent Yorgey wrote: > On Sat, Mar 23, 2013 at 08:26:52PM -0700, Luke Evans wrote: > > I'm curious about using Haskell for metaprogramming. > > > > It looks like I can dynamically compile, load and run some Haskell with > the plugins package. Actually I've briefly tried this and it seems to work > for some simple cases at least. > > Now I would like to be able to enumerate precompiled public functions in > modules that I might use as building blocks in such dynamic compilation. > So far I'm not seeing anything that does this directly. > > Can anyone provide some pointers? > > > > If it's just not possible to introspect on compiled modules, then I > suppose I could use external metadata of my own, or even perhaps haddock > info if it exists, to attempt to generate this info. Clearly though, > that's nowhere near as good as extracting the info from something the > compiler built directly. > > I have no idea how it works, but I'm pretty sure yi does this --- > e.g. if you hit M-x (when in emacs emulation mode) and then > tab-complete, you see a list of all the available functions. Maybe > you want to take a look at the yi source code and see how they do it. > > -Brent > > ___ > 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] Enumerating functions at runtime
On Sat, Mar 23, 2013 at 08:26:52PM -0700, Luke Evans wrote: > I'm curious about using Haskell for metaprogramming. > > It looks like I can dynamically compile, load and run some Haskell with the > plugins package. Actually I've briefly tried this and it seems to work for > some simple cases at least. > Now I would like to be able to enumerate precompiled public functions in > modules that I might use as building blocks in such dynamic compilation. So > far I'm not seeing anything that does this directly. > Can anyone provide some pointers? > > If it's just not possible to introspect on compiled modules, then I suppose I > could use external metadata of my own, or even perhaps haddock info if it > exists, to attempt to generate this info. Clearly though, that's nowhere > near as good as extracting the info from something the compiler built > directly. I have no idea how it works, but I'm pretty sure yi does this --- e.g. if you hit M-x (when in emacs emulation mode) and then tab-complete, you see a list of all the available functions. Maybe you want to take a look at the yi source code and see how they do it. -Brent ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] hsc2hs fails?
L.S., I am trying to install SDL-ttf: SDL-ttf-0.6.2>cabal install : : Preprocessing library SDL-ttf-0.6.2... dist\build\Graphics\UI\SDL\TTF\Version.hs:1:1: File name does not match module name: Saw: `Main' Expected: `Graphics.UI.SDL.TTF.Version' Failed to install SDL-ttf-0.6.2 : The error message is caused by the fact that Version.hs is empty; there is however a file dist\build\Graphics\UI\SDL\TTF\stdout.txt that contains the contents of Version.hs; there is also a file dist\build\Graphics\UI\SDL\TTF\Types.hs that is empty. These files are generated from Version.hsc and Types.hsc, in directory Graphics\UI\SDL\TTF How can this occur? Any way to debug this? Regards, Henk-Jan van Tuyl -- http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - why netwire
Ertugrul Söylemez wrote:
Heinrich Apfelmus wrote:
You said that reactive-banana didn't feel as simple after the
introduction of dynamic event switching, though. Could you pinpoint
some particular thing that made you feel like that? Maybe a type
signature or a tutorial or something else? I took great care trying to
make the dynamic event switching stuff entirely optional, so you can
use reactive-banana without understanding it at all, but I'm not sure
if I succeeded.
I think this is less of an issue with reactive-banana than with classic
FRP in general. The type signatures of Netwire can be scary at first
sight, but they are consistent throughout the entire library. Once you
understand one of these type signatures you understand all of them.
Once you know how to use one wire, you know how to use all others.
Let me pinpoint something in particular: events. In reactive-banana
events are special, in Netwire they are not. This makes dynamic
switching special in reactive-banana and natural in Netwire. Let me
show you an example: You want to dispaly "one" for ten seconds, then
"two" for twelve seconds, then start over:
myWire =
"one" . for 10 -->
"two" . for 12 -->
myWire
Events and particularly dynamic event switching is one of the main
problems Netwire solves elegantly. You can add this to reactive-banana,
too, but it would require changing almost the entire event interface.
I concur that chaining wires with the andThen combinator is very
slick, I like it a lot. Wolfgang Jeltsch recently described a similar
pattern for classical FRP, namely a behavior that doesn't live forever,
but actually ends at some point in time, which can be interpreted as an
event occurrence. ("It ends with a bang!")
However, do note that the andThen combinator in netwire can only be so
slick because "switching restarts time" (as the documentation puts it).
I don't see a nice way to switch between wires that have accumulated
state. How would you express the TwoCounters example [1] using dynamic
event switching in netwire? (The example can be implemented without
dynamic event switching, but that's not what I mean.) What about the
BarTab example [2]?
[1]:
http://www.haskell.org/haskellwiki/Reactive-banana/Examples#twoCounters
[2]: http://www.haskell.org/haskellwiki/Reactive-banana/Examples#bartab
Best regards,
Heinrich Apfelmus
--
http://apfelmus.nfshost.com
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Announcement - HGamer3D - 0.2.1 - featuring FRP based GUI and more
> I simply have no time currently to mainain another platform. Fair enough. Nice to know it should be possible at least. > I started on Windows, because I like it and I thought its the platform with > the most gamers. Most "gamers" probably don't care about Haskell anyway, or even programming. (If popularity is to rule you should only make gaming libs in C++/Java.) Making the code itself portable (as Ertugrul suggested) is a good thing, even if you don't want to maintain multiple platforms (which is fully understandable). Best wishes! /Johan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
