Re: [Haskell-cafe] Enumerating functions at runtime
More details about interface files can be found at http://hackage.haskell.org/trac/ghc/wiki/Commentary/Compiler/IfaceFiles -- in particular the 'ghc --show-iface' part should be of great interest to you. On Sun, Mar 24, 2013 at 12:22 PM, Don Stewart wrote: > 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 > > -- Alp Mestanogullari ___ 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
I should mention that both functional programming in general and Backus's FP _have_ been influenced by APL, which, while imperative, strongly encourages "algebraic" combination of small functions and had (a fixed set of) higher-order "operators". As for Brute Force Learning by reading imperative code, I have to say that you _can_ learn a lot that way, but there is an abundance of imperative code which is utterly opaque. Come to think if it, I've just taken two days to write 53 lines of imperative code which requires four more pages to explain why it exists and why it looks the way it does. In a functional language, it would be 2 fairly obvious lines, and I am _not_ kidding. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
Corentin: Thanks. It is not exactly the serialization of IO state computations, but when re-started, the IO state is recreated from the serialized intermediate results. It makes use of a simple idea, although it is not easy to realize it practically. I suppose that scala does something similar for their serializable delimited continuations. 2013/3/25 Corentin Dupont > Workflow is impressive! I didn't know you could serialize IO > states/computations. > > > On Mon, Mar 25, 2013 at 2:06 AM, Alberto G. Corona wrote: > >> 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. >> > > -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
It is possible as long as there is a empty event and there is a operation that mix two events to créate an state and an operation that mix an state and a event to créate an state. Then, if the events are serializable, the deserialization of the state from a serialized list of events would be deserialize list= mconcat . read $ list it is a way to have a general expression for the deserialization instead of a ad-hoc loop. 2013/3/25 Corentin Dupont > What do you mean by monoid? It's not clear to me how a state (essentially > a structure with many fields) can be a monoid... > I figured out that the Writer monad may be good for that purpose. > > > On Mon, Mar 25, 2013 at 1:50 AM, Alberto G. Corona wrote: > >> 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. >> > > -- Alberto. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Pattern matching with singletons
Hello,
the following programs seems to hit either some limitation of GHC or maybe
I'm just missing something and it behaves the intended way.
{-# LANGUAGE TemplateHaskell, TypeFamilies, DataKinds, GADTs #-}
module Test where
import Data.Singletons
data TA = CA
data TB = CB
data TC = CC (Either TA TB)
$(genSingletons [''TA, ''TB, ''TC])
type family Output (x :: TC) :: *
type instance Output ('CC ('Left 'CA)) = Int
type instance Output ('CC ('Right 'CB)) = String
f :: Sing (a :: TC) -> Output a
f (SCC (SLeft SCA)) = 1
g :: Sing (a :: TC) -> Output a
g (SCC (SLeft _)) = 1
Function f typechecks as expected. Function g fails to typecheck with the
following error.
Could not deduce (Num (Output ('CC ('Left TA TB n0
arising from the literal `1'
from the context (a ~ 'CC n, SingRep (Either TA TB) n)
bound by a pattern with constructor
SCC :: forall (a_a37R :: TC) (n_a37S :: Either TA TB).
(a_a37R ~ 'CC n_a37S, SingRep (Either TA TB)
n_a37S) =>
Sing (Either TA TB) n_a37S -> Sing TC a_a37R,
in an equation for `g'
at Test.hs:21:4-16
or from (n ~ 'Left TA TB n0,
SingRep TA n0,
SingKind TA ('KindParam TA))
bound by a pattern with constructor
SLeft :: forall (a0 :: BOX)
(b0 :: BOX)
(a1 :: Either a0 b0)
(n0 :: a0).
(a1 ~ 'Left a0 b0 n0, SingRep a0 n0,
SingKind a0 ('KindParam a0)) =>
Sing a0 n0 -> Sing (Either a0 b0) a1,
in an equation for `g'
at Test.hs:21:9-15
Possible fix:
add an instance declaration for
(Num (Output ('CC ('Left TA TB n0
In the expression: 1
In an equation for `g': g (SCC (SLeft _)) = 1
I would expect that a ~ ('CC ('Left 'CA)) in the right hand-side of g (SCC
(SLeft _)) = 1 since SLeft's argument is necessarily of type STA, whose
sole inhabitant is SA.
Now I understand (looking at -ddump-slices, the singletons' library paper
and the error message) that the definition of SCC and SLeft
don't immediately imply what I just wrote above. So my question is: in the
right hand-side of g (SCC (SLeft _)) = 1,
- is a ~ ('CC ('Left 'CA)) a consequence of the definitions of SCC,
SLeft, ... (in which case GHC could infer it but for some reason can't)
- or are these pattern + definitions not sufficient to prove that a
~ ('CC ('Left 'CA)) no matter what?
Cheers,
Paul
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [high-order-munich] Munich Haskell Meeting
Dear all, of course, our Haskell Meeting in Munich will be tomorrow, 26th of March, and not the 25th. Sorry for the wrong date! Heinrich Am 25.03.2013 06:49, schrieb Heinrich Hördegen: 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 ___ high-order-munich mailing list high-order-mun...@fs.lmu.de https://lists.fs.lmu.de/mailman/listinfo/high-order-munich -- -- Funktionale Programmierung Dr. Heinrich Hördegen Gutenbergstr. 26 80638 München FON: +49 (89) 12 59 79 49 FAX: +49 (89) 12 59 79 50 hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make a DSL serializable
On Mon, Mar 25, 2013 at 8:53 AM, Corentin Dupont wrote: > Workflow is impressive! I didn't know you could serialize IO > states/computations. In certain constrained cases you can. General case, as I said earlier, is kinda impossible without serializing the entire machine state. -- 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
Workflow is impressive! I didn't know you could serialize IO states/computations. On Mon, Mar 25, 2013 at 2:06 AM, Alberto G. Corona wrote: > 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
What do you mean by monoid? It's not clear to me how a state (essentially a structure with many fields) can be a monoid... I figured out that the Writer monad may be good for that purpose. On Mon, Mar 25, 2013 at 1:50 AM, Alberto G. Corona wrote: > 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] Make a DSL serializable
Hi Michael, On Sun, Mar 24, 2013 at 05:13:35PM -0500, Michael Better wrote: > Isn't this similar to the problem Cloud Haskell had to solve to send code > to another process to run? As much as I know, the sendable code of 'Cloud Haskell' is limited, you can't just send any kind of function. https://github.com/jepst/CloudHaskell#process-management Greetings, Daniel ___ 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
* Konstantine Rybnikov [2013-03-25 11:22:21+0200] > On Mon, Mar 25, 2013 at 8:49 AM, Roman Cheplyaka wrote: > > > * 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 > > > > Thanks, Roman. I've totally read this answer some time yesterday (too late, > unfortunately). You also seemed (due to logs) to implement functionality I > needed (lookAhead, if I'm not mistaken). Thanks! > > But I just don't understand why such a basic thing as live community-hub > for a project (github page would be enough for this) is so hard to create. > I'm also not saying I would write a lot of docs, but at least making them > more "up to date" doesn't look as too ambitious task. It's not hard to create — it's hard to get traction. Anyway, don't be discouraged by my experience. Go for it! I put back my original repo at https://github.com/feuerbach/parsec-doc — feel free to use it. In particular, it contains an interesting analysis of parsec usage by Dmitry Astapov. Roman ___ 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 8:49 AM, Roman Cheplyaka wrote: > * 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 > Thanks, Roman. I've totally read this answer some time yesterday (too late, unfortunately). You also seemed (due to logs) to implement functionality I needed (lookAhead, if I'm not mistaken). Thanks! But I just don't understand why such a basic thing as live community-hub for a project (github page would be enough for this) is so hard to create. I'm also not saying I would write a lot of docs, but at least making them more "up to date" doesn't look as too ambitious task. ___ 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
Peter Althainz wrote: > Its simply the types are more cumbersome, now. In netwire you > basically have one type, which is "Wire " with some type > parameters (underlying monad, inhibition type, in-type, out-type), > When underlying monad and inhibition type is choosen, you can define a > type synonym and all boils done to "GameWire a b" in all types, events > (GameWire a a), behaviours (GameWire a b), what you want. Signal > inhibition makes Events and Behviours looks equal. Also the overall > network has this type. And by the way, no generalized datatypes > (forall t. ), which I'm also not too comfortable with. Actually for the higher rank types there is a rationale: safety. In fact I first had this: type Event e m = forall a. Wire e m a a However, this turned out to be too restrictive, when I decided to simplify it: type Event e m a = Wire e m a a The reason is that many events like 'require', even though they still act like identities, have to examine the input value to make decisions. Also you can expect that there will be at least one higher rank type in all libraries I release based on Netwire, for example my upcoming Vty-based text UI library: simpleUI :: (Monad m) => (forall a. m a -> IO a) -> UI m () b -> IO b The first argument is a monad morphism. It would be totally fine for it to be less restrictive for this case, but I want to stick with categorical concepts as far as possible. This makes it easier to reason about the code. 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] Haskell-Cafe Digest, Vol 115, Issue 37
Le dimanche 24 mars 2013, a écrit : > Send Haskell-Cafe mailing list submissions to > haskell-cafe@haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.haskell.org/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-requ...@haskell.org > > You can reach the person managing the list at > haskell-cafe-ow...@haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > ___ 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
Hi Heinrich: Its simply the types are more cumbersome, now. In netwire you basically have one type, which is "Wire " with some type parameters (underlying monad, inhibition type, in-type, out-type), When underlying monad and inhibition type is choosen, you can define a type synonym and all boils done to "GameWire a b" in all types, events (GameWire a a), behaviours (GameWire a b), what you want. Signal inhibition makes Events and Behviours looks equal. Also the overall network has this type. And by the way, no generalized datatypes (forall t. ), which I'm also not too comfortable with. In reactive banana we have considerably more types then in netwire: - One tpye for Behaviours - One type for Events - sinks in addition: sinkoutput[text:==showNumber<$>result]- what is that? (I know it has something to do with feedback loops) - scary type for the network description: "forallt.Frameworkst=>Momentt()" best regards Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
