Today in Code

When is the last time you’ve written a project from the ground up? Every single day as programmers, we write products on already established libraries - as is sane discourse. But what happens... when we don’t - when we say, “I’m going to use the bare minimum - and write everything else myself.” I would say we learn (a lot).

I inadvertently started this project through beginning my own game framework, named clibgame. I had been writing a couple of games and I found myself writing the exact same code over and over again. I decided to instead write it once in a general format and call it a library of its own. From that point it naturally evolved into more and more of a game engine. In its current state (at time of writing), one inherits from a pre-built Entity Component System (ECP), they define behaviors through implementing their own components, and they attach them to different unique IDs within the ECP. The engine as a whole has only 4 dependencies: GLEW, GLFW, Freetype, and libpng. As it stands, all of those links are obviously libraries - as opposed to frameworks or engines of their own. They don’t provide a helping hand outside of abstracting away a little bit of nitty-gritty file parsing and kernel-or-graphics-drivers level API calls.

I learned a lot predominantly in 3 areas:

OpenGL - Of course and OpenGL-based game library is going to include something of writing code aimed at the OpenGL API. Though I had a notable amount of work in OpenGL before (through different languages and projects), writing a library is remarkably different. When writing a library your product isn’t only an application that runs well enough - it’s a library that runs optimally. I’m not going to claim that clibgame is at that state yet, but even those thoughts are enough to learn more about your theoretical limitations.

Managing a C++ Project - Prior to this project I hadn’t worked on anything of this scale in C++. I’m not trying to imply that this project is by any means large, only that it is larger than other ones I’ve undertaken. C++ is the kind of languages that has tens of ways to perform a single task - with only one or two of them being valid, idiomatic solutions. Obviously the larger a project becomes, the easier it is to slip into poor coding habits, making the code less and less maintainable. I think working on a slightly larger project taught me about managing some amount of a standard for code quality as a project grows.

Developing a C++ Library - This one is much like the former - only it applies more specifically to creating a library with C++. Much of this particular area is dedicated especially to managing code in such a way that it can be deployed easily. Throughout this process I’ve been attempting to keep the installation process simple (assuming you have all of the required libraries). As it stands there are no ‘gotchas’ regarding installation, it’s the normal process for a simple CMake project.

The next stepping stone on this journey was starting an actual videogame, jumponthings. As it stands, it’s very much so in-development. In its most recent version (at time of writing, yet again), you can run around on a piece of grass, and jump about. This project only has one dependency, clibgame. The idea behind creating this game is to only need that one dependency. If I need something that I feel ought to be in the library itself - I add it. That way future projects (both written by myself and others) will need not write the same code over again. The idea and the hope with this is that this project will urge clibgame to a place where it is a fully functional game engine. Though the goal of this project is to grow clibgame further, it has incidentally also led to some learning in and of itself.

It’s been an adventure learning to write code around a component & event based model. It is a paradigm where one does not have control over the data around it (an aside, this is not directly true in clibgame. One can go through the process of directly accessing and mutating the components of the current entity. It can also access - in a const fashion - the data of every component in the entity component system). It can only control its own data - all mutations to the world around it are handled through a global eventing system.

The next challenge in this project is more intelligent and resilient file parsing. I need this for a couple of things - namely asset parsing in clibgame and world parsing in jumponthings. In its current state it’s using a std::istream to try to match different values, but I’m looking to create more advanced parsing constructs - and as such I’ve just started parsical - a parser combinator library based off of Parsec, a Haskell library. There’s got to be a plethora of parsing libraries already made for C++, but in the spirit of this project, I want to create my own. This is just another avenue to learn about a specific piece of programming - this being parsing.

(From Hacker School)

Hacker School is over. Rather, Hacker School is over for me. It's thankfully still going strong. When I sum up these past 10-ish weeks, I inevitably say a couple things: It was amazing, the environment is fantastic, it was definitely one of -- if not the -- best experience of my life. Honestly, not even just for the programming. I learned quite a bit about a number of different things (more to come on that later), but more valuable to me was the growth I experienced as a person.

New York City was completely out of my comfort zone. Before hearing about the Hacker School I would never have thought I'd want to be in NYC for any extended period of time. After Hacker School, though, I love the city. One could look at that and simply see someone realizing that they like cities, but for me I feel like it means more. I went to the Hacker School far more timid, more anxious, than I am now. I've experienced so much accelerated growth from being in the Hacker School. Honestly, if I were to think about why, it's their (explicit) social rules.

If you go here and scroll down a little you can see them listed under 'Social Rules'. Their importance to my own growth I feel came from the fact that the socials rules inherently create a safe space for you to put yourself out of your comfort zone, thereby expanding it. I don't think there was a single week at the Hacker School where I didn't feel as though I was growing somehow. Either by becoming a better programmer, or by becoming a better person.

Hey! I've been doing loads and loads of stuff. But the thing is I haven't been updating my blog on any of it. So I'm going to do another update that's just a generic, "what have I been working on" kind of thing.

Sinterklooser

I'm Dutch-- well half-Dutch. The point is that this Christmas season I'm going to be celebrating a little delayed version of Sinterklaas. To sum it up, it's pretty much a version of Secret Santa where people all make more personal gifts. I did it for the first time last year and I really like it. Anyways, the point is that this year there are going to be a bunch of people at my family's Sinterklaas celebration. The nature of more people means that there are more people who don't know each other. There are a couple options with that:

Divide the group into different subsections.

Make some really cool algorithm to solve it instead.

Given the fact that I love programming and algorithm design stuffs, I, of course, picked the latter. So I made something I'm calling Sinterklooser. It's the words Sinterklaas and chooser sort of mashed together.

The idea is that you make a graph of people who know each other. You then input it into the program and it spits out the set of people who should get other people as their Sinterklaas recipients. There are a number of ways to solve this, with some better than others (especially when you bring in the variable of what is an optimal solution to this problem).

Right now there are two branches on the GitHub, the master branch being slightly less developed than the analogue branch. The main difference between the two is I changed the Graph implementation and I made the algorithm work on analogue values instead of digital values. That is to say, two given people have a degree of familiarity with one another instead of a binary do-they-or-don't-they know each other. I'm pretty sure the master branch is a little bit more stable, but is definitely missing a bunch of code from the analogue branch.

Right now it works, in that it'll give you the set of people. But there are a few optimizations I want to work out. Namely one that I've been thinking of: the algorithm should choose the people with the least connections as the first ones to go. I primarily think this is a good idea for the algorithm for the sake of making sure someone who doesn't know many people gets to have someone they do know. It's probably less important for someone who knows them to get them (in the event that there's no perfect solution), because someone who knows more of the group (who would then go last) would feel more comfortable asking around in the group.

Anyways, yeah, that's that project. It was really fun getting my hands dirty with more of the algorithms side of programming. I haven't really quite done that in a while.

generator-crockeo

There's not much to say about this one. I just developed a Yeoman generator such that when I make new Node projects I already have an infrastructure (one I tend to use a lot) in place. I used to spend about an hour doing generic work on a given project before I could start actually working on the project. So instead I spent ~2 on learning a little about Yeoman and making this. It can be found here. There's a bunch of me-specific things in there, but I may remove them in the future.

dotfile-manager

I'm really tired of writing at this point, so instead of giving you a long-winded explanation of my motivations, I'm just going to explain what it does. I wrote this thing. It's called dotfile-manager. The basic idea is that you install it, then if you have some set of dotfiles somewhere, it'll automate the installation. The demo I have on the repo is for installing my crockeo/vimconfig repository. Said repo contains my config files for Vim and a script to install Vundle.

So, on and off for the past 5-or-so months I've been working on game development with Haskell. Specifically I've been trying to determine the best systems to work with each other in order to design games and game engines. I've since settled on using Elerea and OpenGL (with GLFW for windowing and OpenGL contexts) - though not for games so much as game engines. I find myself having more fun with that side of all of this. Since starting this I've done a number of projects in that zone. For the record, all of those words are their own link. The point that I'm trying to get across is that I've been doing this for a while.

And now other people are too!. Okay that's just one example. But there are other people too! Like Chucklefish with their new game Wayward Tide! They're using Elerea with SDL2... which is close enough. Not to mention the fact that a Haskell Gamedev has started.

In my last post (6 days ago according to tumblr's little 'posted when' thing on the bottom of the post), I mentioned that I felt as though I had burned myself out with programming. Then, Tuesday of that week, I really, really burned out. I got the flu - fever and all. It sucked, a lot. I'm still a little bit sick from it, but at this point it's really just the aftermath of my body starting to feeling completely healthy again. I'm not going to say that code burnout was the direct cause of that whole ordeal, but it definitely felt like it had a part to play. I felt absolutely physically exhausted because of the burnout, and maybe that had some effect on my immune system? Or maybe I just have a sore lack of understanding of the human body (which I think is true either way).

I'm also going through some personal stuff right now, but a programming-centric blog is no place for that. I think right now what I need to do is just get back programming. I've done almost nothing with my time since coming down with the flu (as I feel I should), and it's time to get back on that figurative horse.

So Hacker School makes you program a lot. Which isn't really a problem, seeing as I really, really love programming. When I say love it, I mean love it. Even if I weren't here I'd probably be programming around this much. The only problem is that I usually program this much in spurts. I'll go on a week-or-two long spree of programming for hours and hours a day. Then... I just kind of stop. It sounds sort of similar to what people describe as 'burnout', but I don't really feel burnt out. I just feel... bored. That's honestly my main motivation for writing this. It's letting me take a break from programming while still feeling productive. I'm creating something, but I don't have to think about much of anything. Not to say that writing has that characteristic universally, merely that my writing has that characteristic.

I suppose I might as well list of what I've been burning out on:

gualy

A majority of the week before last, and a portion of last week, I had been working on a web app named gualy. The idea is that it's a semi-social app that lets you track your and your friends' goals. It's honestly pretty simple in the grand scheme of things, but it was an excellent exercise in learning Javascript full-stack.

One of the best things I learned in that project was using AJAX calls through jQuery to create dynamic pages. It's awfully primitive compared to using reactive components using, say, React or Angular, but it's a great excursion into that world.

whatisthisgame

For a little while -- as in around over a month -- I've had this project somewhere between the back-burner and full throttle. I've had little spurts where I did a bunch, and then stopped for extended periods of time. For quite a while, I was paralyzed by a conceptual wall I couldn't climb. I was facing the problem of spawning new bullets in a world where Signals are supposed to have the property of always existing, from forever ago to forever into the future (that's a little bit of hyperbole). Upon rewriting the module, the problem ended up being much easier than I thought. If you want to look at it, check it out here. Anyways, it's done enough now that I don't really want to keep working on it.

whiskey-bot

So at Hacker School there's this thing where a lot of people go out to a bar on Wednesday nights to hang out and socialize. whiskey-bot is a Zulip bot that I'm actively working on to remind people of Whiskey Wednesdays. It spawned as a joke from a conversation at a Whiskey Wednesday, so I thought I'd go ahead and implement it.

saffron

As is my tendency, here's one of my infrequent Hacker School updates. I spent a good portion of yesterday and today working with a fellow Hacker Schooler on a Tic-Tac-Toe project. Specifically one that runs in a server, and interacts through a web UI. The Tic-Tac-Toe game and server are written in Python, while the UI is written using Javascript & HTML. The project itself isn't really the interesting part of this project. What was is the fact that it was my first experienced with long-term pairing at Hacker School.

Before this experience, most of my pairing happened in around the span of an hour -- max. It's also a completely different experience to pairing for a longer amount of time. On a longer-lived pairing project like this I've found that one of the major differences is the amount of collaboration. We've not only been doing some of the 'driver and passenger' pair-programming, but also a lot of independent work (while conferring with each other) and pushing it to the same GitHub. That is very much so a first for me, whether in the scope of HS or anywhere else in the world.

This past weekend (I guess it's still technically this weekend) I'd been working on a small project to keep track of timing for speedrunning videogames. You can find it on GitHub here. It's written using SDL2. Tonight I also messed around some with SDL2 (specifically the sdl2 library) and Haskell. Specifically how to work very basic examples with it. I feel like I'm missing something, though, because I had to use some FFI (and a lot more if I were to want to continue doing what I'm doing with it) to do some things.

This Week

I'm writing something called Gualy. It's a little (in the grand scheme of things) goal-tracking app. I wanted a couple things from it when I set out to make it:

Let someone track their own goals.

Let people see other people's goals.

Let people choose which goals can be public.

Implementing those three features wouldn't take that long -- maybe a total of a day -- but I wanted more than just a bare minimum product. Websites now-a-days aren't static pieces of HTML that get served to you with a little bit of content. They're much, much more dynamic than that. They have boatloads of Javascript on the client controlling everything from form submissions to message boxes.

I'm not (and was even less so, before I began) a front-end engineer. But I wanted this to be something usable. It's starting to come along. One can register, log in, post their goals. There are just two more features to add before it's 'done'. The done is in quotes because it's still going to be far from done. Right now it's just a hunk of HTML, Javascript, and CSS that's semi-reactive while using dirty hacks like forcing the page to reload (instead of dynamically updating the page).

Okay, I'll come clean. I had written a little Javascript before-hand. But this is my first time really falling down the rabbit-hole (into a world where types aren't static). I really just want to say: this isn't all that bad. I'm not claiming I'm going to suddenly switch sides and scream from the rooftops, "DYNAMIC TYPING IS THE WAY." Because honestly I don't believe that. Rather, I am going to say, it -- and the rest of Javascript -- are not as horrendous as I thought before I started this project.

The Haskell Kool-Aid

That title is a bit hyperbolic. I don't think Haskell itself (or thinking Haskell can be effective at solving a problem) is 'drinking the kool-aid'. What is, though, is believing it's the only way. I had been writing in solely Haskell for a number of months before coming to the Hacker School, and on and off for a little under two years before that. I had used it to write a web application. I had used it to do Project Euler. I had used it to try to write games. I've tried pairing Haskell with everything I've wanted to do. The truth is... it worked. More or less. It may not be the best suited for everything under the sun, but it worked.

And while it worked, it limited me to a solely Haskell & Functional Programming (FP) perspective. It was effective for production, but ineffective for learning. Given that I was far from making money on any of what I was writing, solely production was far less useful than learning. The problem was that, to me, Haskell was the be all and end all. It's still my favorite language, but it's no longer the only one.

Spitting It Out

The kool aid, that is. I think Hacker School -- and the Hacker Schoolers themselves motivated me quite a bit to start expanding my horizons. I was working on implementing a Trie with one of my peers. We came up with a very clever Haskell implementation, but afterwards he made a C implementation that was 21x faster. I wasn't surprised by the performance difference (everyone knows C is ridiculously fast), but I wanted to learn how to do that. So I did.

I realize that since getting to the Hacker School (HS) my updates have been few and far between. It's definitely not for lack of content - but rather that I'm more interested in the content than writing a blog post about it. That being said, I'm currently experiencing a sort of programming overload, and I find myself needing some time to relax. Thus, a blog post... about programming.

My Projects

As of right now I'm concurrently working on a few projects at HS. They are:

whatisthisgame - a small game I'm writing in Haskell to learn about FRP and OpenGL to make games.

treestuff - originally an implementation of tries in a couple of languages (Haskell, C, and Python). In the boggle_solver directory it became more of an exploration of data structures using C++.

gualy - a project I'm writing using Mongo, Express, (possibly Angular, just so I can say I'm using a MEAN stack,) and Node. The idea is a website to keep track of your goals, and look back at goals that you've completed.

Lambda Calculus - my attempt to understand and reason with lambda calculus. I think it might be helpful because of the similarities between it and pure functional programming (such as Haskell - which is where most of my interests lay).

Category Theory - again, me attempting to understand the more theoretical side of things. This time in a more mathy context, but for application to Haskell.

Future Projects?

I'm thinking of looking into using SDL2 and C++ to write some sort of game.

My initial goal of writing another massive update to my library spice is also on the table.

Learning Racket is also something that interests me.

To sum up the experience so far, I can only say: oh my god. I was wondering what it would be like to be in this space with a bunch of people like this. I was hoping that I'd be able to talk to people, collaborate, learn, all of that stuff. I haven't done everything on my mental plate as of yet, but it sure as hell seems like I can.

Yesterday

I spent yesterday working in Haskell. I ported my whatisthisgame app from Elerea over to Netwire 5. I went out to lunch at a place called The Soup Kiosk, which was a very fun experience. I even went to a talk at the eBay head quarters about different styles of programming languages. Over all, a really, really fantastic day.

Today

I've been doing some more Haskell today on the same app. This time trying to get started on implementing some more functionality (namely being able to shoot from your ship). There are a number of people here who are full-stack Javascript developers and have been unintentionally drawing me to their world. I've downloaded Node and have been looking at other technologies for the rest of a possible web app.

I think I'm going to go and try to make something that's almost like IRC with Node. As I understand it, it has a great TCP interface so I thought why the hell not.

The Future

Though not my intent, I realize that it's about to turn into a humble brag: I was accepted into the Hacker School! It's a sort of 'development bootcamp' thing. But it's not really. It's more of a self-driven environment designed to let people explore what they really want to learn. They just provide you with the place to go and the resources to do it.

Upon watching an excellent talk about porting videogames to Linux, I had a thought regarding C and Haskell. I find it very difficult to program in Haskell while I'm tired. Solving problems takes longer and the resulting code often-times doesn't compile. Or at least takes a lot longer to make compile. But I find that I can program in C late at night. The code compiles, but it never does what I want.

This is a blog post on my opinions of Elerea vs. Netwire 5. It is not (in bold instead of just in italics for double the emphasis) me trying to say that one is better than the other. In fact I'm so torn about them that I'm paralyzed on what I which I want to use to write my successor to Spice. This is me talking about the differences I've noticed between them.

Experience

First I'm going to talk about my experience with them. In other words, I'm going to convince you that I'm even marginally qualified to talk on this subject. I have a number of projects written in Netwire (all of those links go to different places!). I don't claim for them to be big enough to call myself an expert on Netwire, but I know something about it. I know how it feels to work with, if that's worth anything.

I'll admit, I have much less experience in Elerea. I have two projects written in Elerea: elerea-pong and Spice. I'll admit neither of those are a fantastic example of Elerea. elerea-pong was never intended to be a reference for anything you should ever do in Elerea (and thus, it's rather messy). Spice, on the other hand, simply doesn't leverage Elerea to a great degree.

Note: Many of the techniques I learned about Functional Reactive Programming (FRP) from Netwire applied very well to Elerea (Spice came before I learned more about FRP, hence its lack of leverage).

Monads... Or Not?

Netwire vs. Elerea -- the not contest. In short: The only situation where I feel as though Netwire will beat out Elerea is in situations where you need to be operating in a Monad that isn't IO. Why is that? Well it's because you can specify the operating Monad in a wire.

data Wire s e m a b = ... -- vs. data SignalGen p a = ... -- Assuming you are using FRP.Elerea.Param

As you'll hopefully note (if not I'd advise going to an eye doctor), in the Wire definition there is a letter named m. That m specifies the operating Monad of the Wire. Why does that matter? Well because Netwire has a function named mkGen (with its sister functions mkGen_ and mkGenN) with type:

mkGen :: (s -> a -> m (Either e b, Wire s e m a b)) -> Wire s e m a b

(I couldn't check that for sure because Hackage is down right now, but I think it's correct). The result type of the function you pass to mkGen operates within the Monad you specify. Say you want to get something from IO? How about a call to randomIO (from the random library)? Well you can do that.

testWire :: Monoid s => Wire s e IO a Int testWire = mkGen_ $ \_ -> do rand <- randomIO return $ Right rand

You're now literally operating within the Monad that you've set for yourself. The best part is that you can do all of that within a Wire and refer to it in the rest of your Netwire network without any fuss. I mentioned earlier that this is where Netwire has the edge, and that's true. In Elerea you have two options: execute, to perform a single IO action, and effectful to perform an IO action on every tick. Notice the difference? You can only work within the IO Monad. Is that really a problem? Well not necessarily. It depends on your application. If you don't need to embed your FRP in a non-IO situation then you'll be fine with either one.

Simplicity

{-# LANGUAGE Arrows #-}

Look forward to putting that on the top of a bunch of your Haskell modules if you're using Netwire. I don't really have anything about language extensions, but honestly ArrowLoop is quite scary the first time you see it. I'm going to recount my experience first learning about it with a little emulated monologue.

Here I am, sitting in my office chair reading ocharles' Getting Started with Netwire and SDL post. In my sleep deprived state, I struggle with converting the Netwire 4 and SDL code over to Netwire 5 and OpenGL. I seem to get the first few sections implemented well enough in a working example. Then comes the heading 'ArrowLoop and Recursion'. I think to myself, "Alright, I don't know what ArrowLoop is, but I know recursion. This should be fine." It's not; nothing is fine. I see lots and lots of strange symbols and words that I haven't seen before. The exact code he had on his website is this:

challenge3 :: (MonadFix m, Monoid e) => Wire e m (Set SDL.Keysym) Double challenge3 = proc keysDown -> do accel <- acceleration -< keysDown rec (position, collisions) <- position -< velocity velocity <- velocity -< (accel, collisions) returnA -< position

I was absolutely baffled; what does proc keysDown -> do mean!? What is this -< symbol. I try to take a break and orient myself. I opened up Google and looked up something along the lines of "proc haskell". After a number of links I came upon the GHC Arrow Notation Documentation. This was majorly helpful for understanding this specific piece of code, and more specifically why it worked.

This specific instance was rather easy to solve. It only took one Google search! That being said, this sort of represents my experience of learning Netwire. There are a lot special pieces of Netwire that are difficult to grasp at first.

I didn't have that experience with Elerea at all. I will admit a large portion of that is probably due to the fact that I already learned a bunch about FRP from Netwire. Even with keeping that in mind, I feel as though Elerea falls a lot more into classical Haskell. You don't specify the input to a SignalGen as a value in the type definition (as is the case with Wires in Netwire), you just pass them to functions as arguments.

doSomethingWithInput :: Wire s e m (Int, String, Bool) String doSomethingWithInput = mkSF $ \(n, s, b) -> ... vs. doSomethingWithInput :: Signal Int -> Signal String -> Signal Bool -> SignalGen p (Signal String) doSomethingWithInput n s b = ...

There's more typing to be done on the Elerea example (and there's a bit more after what I just wrote), but it's simpler in a way. You don't have to understand that the a value in a Wire s e m a b means that there's a piece of input. You just use the intuition you've built up with your use of Haskell for ages.

Age and Stability

If you were paying attention you probably noticed that I was leaning to either network in the above. The first point was pro-Netwire, the second was pro-Elerea. This last point is really one that can go to either depending on what you care about.

I can't check for sure right now (Hackage is down), but I'm pretty sure Elerea hasn't been updated in a long, long time. The other side has Netwire updating relatively often. Even relatively recently, the massive switch from Netwire 4 to Netwire 5. It was a hell of an API-breaking change, but it was a big step in the right direction. To my recollection, the base value Wire, changed its type signature.

-- Netwire 4 version Wire e m a b = ... -- Netwire 5 version Wire s e m a b

I'm not gonna get into the details of the differences between these two. The general idea is that it let you define your own timestep instead of having to refer to the one contained in the library. Instead of looking at the specific change, I'd advise you to step back for a second. Look at the differences in these two philosophies.

Elerea hasn't updated in forever. Netwire would make such an absolutely breaking change to the entire library for the sake of a positive change. Elerea in its current state is more or less static, whereas Netwire will continue to change and adjust to new requirements.

Verdict

The past few days I had been hacking away at a specific facet of an implementation of Snake in Netwire. That specific fact was updating a part of my Netwire network at a specified period instead of real-time. This was used for implementing the movement of the snake itself. I found the process of researching and implementing this difficult enough that I would share it with all of you.

Implementation

Instead of boring you with a story you probably don't care about, let's get straight to the implementation and the ideas behind it. To restate the above, the target functionality was to step any given wire at a specified interval. There was much hacking away at different implementations, but the final result is as follows:

Taking my inspiration the wire in my first post that reacts to input, I created a wire that blocks until the period has been reached. Then it resets the counter to 0 so it'll count up again.

-- | A wire that blocks until the specified time has been met. At that point it -- results in the input type, and sets it counter back to zero. stepper :: (Fractional t, HasTime t s, Monoid e) => t -> t -> Wire s e m a a stepper target t = mkPure $ \ds a -> let dt = realToFrac $ dtime ds t' = t + dt in t' `seq` if t > target then (Right a , stepper target 0 ) else (Left mempty, stepper target t')

That achieves our goal for this part. But that's hardly the most difficult section. Next I constructed a wire from that one which always had a result, and instead would result as False when stepper is blocking, and True when it's producing a result.

-- | A constant version of @'stepper'@ where it never blocks, but rather -- returns @'True'@ when @'stepper'@ ticks. constStepper :: (Fractional t, HasTime t s, Monoid e, Monad m) => t -> t -> Wire s e m a Bool constStepper target t = pure True . stepper target t <|> pure False

Now we're going to skip one piece, but for now let's pretend there's a Wire: stepIf :: (Monoid s, Monoid e, Monad m) => Wire s e m a b -> Wire s e m (a, Bool) b. The general idea of this as-of-yet unimplemented Wire is that it will step a Wire only in the event that its input is true. With this we can implement another Wire, periodicWire, that upates a wire periodically:

periodicWire :: (Fractional t, HasTime t s, Monoid e, Monad m) => t -> Wire s e m a b -> Wire s e m a b periodicWire target wire = stepIf wire . liftA2 (,) mkId (constStepper target 0)

As you can see it makes use (directly or indirectly) of all of the other functions we've made. constStepper for checking if it should update (which uses stepper). stepIf, for stepping only if constStepper has ticked. Then it wraps all of that into a small function.

Finally we're going to revisit stepIf. The reason we didn't implement it above is because it gets into the nitty-gritty of how you update an FRP network. Similar to how you'd run a network from the outside, actually. The idea is that, given a wire, you explicitly call stepWire on it situationally. The specific implementation requires covering some requirements, such as stepping the wire a minimum of once before it responds to Bool inputs determining whether or not it should step. Anyways, here's the specific implementation:

stepIf :: (Monoid s, Monoid e, Monad m) => Wire s e m a b -> Wire s e m (a, Bool) b stepIf initWire = mkGen $ \ds (input, _) -> do (b, wire') <- stepWire initWire ds $ Right input case b of Left b' -> return (Left b', inhibit b') Right b' -> return (Right b', stepIf' b' wire') where stepIf' :: (Monoid s, Monoid e, Monad m) => b -> Wire s e m a b -> Wire s e m (a, Bool) b stepIf' buf wire = mkGen $ \ds (input, step) -> do if not step then return (Right buf, stepIf' buf wire) else do (b, wire') <- stepWire wire ds $ Right input case b of Left b' -> return (Left b', inhibit b') Right b' -> return (Right b', stepIf' b' wire')

As you can see, while it's simple relative to a lot of other systems in programming, it's far less concise than the other functions used here. Something had to do the brunt work, though.