Trucchi: And a way of matching them up

Bordenkircher: Cough typescript cough

Trucchi: Typescript only solves half the problem though!

Trucchi: But yeah, that’s one area where typescript’s interfaces + generics + overloading can come in handy

Martino: Bertot: how does that “limit the cognitive load for a maintainer” any more than just exposing the data structure and its operations?

Garratt: Because as a maintainer i can just look at the API doc for the module that deals w/ the type and know everything there is to know about it

Trucchi: Well, that you can still do with separated data and operations

Kem: I’m trying to write an infitnite loop that has a delay between each iteration. Previously i did a setTimeout within the function, on itself. Is there a better way to do this without forking?

Cupelli: Bertot: don’t types do the same thing?

Trucchi: Js-csp is a good example of this, actually

Trucchi: The “csp” object contains methods for operating on tables, and you p*** a channel to them when you want to do something

Helf: Dekok: we’re talking about types :

Heffernan: Bertot: how is data Maybe a = Nothing Just a; map f Nothing = Nothing; map f Just a = Just f a any different from cl*** Justa{ mapf = Justfa }; cl*** Nothing { mapf = this }?

Winkels: HowardwLo that’s probably fine

Knewtson: Any different in “maintenance burden”

Morgner: Dekok: you’re ***uming a language that can support this degree of expressiveness :

Trucchi: Dekok: data.maybe would be a better example if the docs for it were more decipherable ;-

Magana: Trucchi: what’s not “decipherable” about them?

Tupy: Enmon: same old, i’m working on a System.js react hot-loader actually :

Bjerken: Bertot: most functional languages allow that.

Chaskey: Enmon: you? still on the angular train?

Barkle: Yeah, it is a comfy train

Schilder: Waiting for the ng2 tunnel

Zeyadeh: That is going to be real fun

Trucchi: Dekok: actually data.maybe itself is fine, but it references the validation stuff, which goes into a bunch of twists and turns

Trucchi: When I was going through folktale I ended up just reading the code

Rotty: I do need to write better docs. And examples.

Leuckel: Might have more time to do that next month

Harrell: Robdubya: is there a better way that doesn’t end up calling a function in a function in a function as many times over as the loop runs?

Almarza: Trucchi: if you could file issues with where you think the do***entation could be improved, it’d help too :

Merkey: HowardwLo: what’s wrong with recursive setTimeout?

Trucchi: Dekok: I guess the main critique isn’t so much that I personally had trouble reading most of the docs except in a few places, but that it ***umes a familiarity with lambda calc and haskell-esque notation on the part of the reader, which isn’t a good thing for a JS lib

Pieretti: Dekok: doesnt it block the first iteration by excuting another function?

Middough: And it just does that over and over

Chislom: I dunno, gut feeling that it isn’t the best way?

Vaughn: HowardwLo: it doesn’t block anything. It just schedules a function to execute after N milliseconds

Solomon: Dekok: oh, is it async?

Schey: Trucchi: hm, yeah. I’ve got some appendices to write on the notation and stuff. And hopefully examples + the introductory book to the concepts used in the library can address the familiarity problem

Cockerill: Then i’ll prboably get rid of my loop

Trucchi: HowardwLo: yeah, setTimeout gets triggered by the eventloop when the callstack clears, the event loops looks at the timeouts and runs any whose interval time has p***ed

Cobetto: Most any other abstraction is gonna be using setTimeout under teh hood anyway