Skip to content
Hallway
0:00 / 0:00

#rust#phantomtypes#ats

Boston Haskell Lightning talks - Dec. 2014

Boston Haskell

1.1K subscribers • 18 videos on Hallway

YouTube
  • Recommended by 2 people: 2 in engineering communities.

Intermediate. Assumes working knowledge.

6K views11 years ago2 recommendations

Programming languagesSystems programmingHaskellRustLanguage design and type systems

A collection of lightning talks covering Rust for Haskellers, phantom types, debugging with ATS, freezing mutable data, and encapsulation versus code reuse.

Darius Jahandarie - Rust for Haskellers youtu.be/yFXzuCFeRGM?t=1s Elliot Stern - Fun with Phantoms youtu.be/yFXzuCFeRGM?t=14m58s William Blair - Debugging with types in ATS youtu.be/yFXzuCFeRGM?t=31m30s Kenny Foner - Ice, Ice, Data (Freezing mutable data structures with Midas) youtu.be/yFXzuCFeRGM?t=50m52s Tom Titchener - Building a real simple music generator to parameterize canons. youtu.be/yFXzuCFeRGM?t=1h12m53s Edward Kmett - Encapsulation vs. Code Reuse youtu.be/yFXzuCFeRGM?t=1h34m55s

Why it's here

2 people recommend this

What people say. Recommended for its diverse set of short talks, particularly Edward Kmett's segment on encapsulation versus code reuse.

Moments people linked to

u/chrisdonerin r/haskell • Recommends

Edward Kmett - Encapsulation vs. Code Reuse
64View on Reddit

u/imalsogregin r/haskell • Recommends

Boston Haskell lightning talks: Rust, Phantoms, ATS, Freezing, Music, and Code reuse Our December meetup's lightning talks are up on youtube. The individual breakdown: Darius Jahandarie - Rust for Haskellers Elliot Stern - Fun with Phantoms William Blair - Debugging with types in ATS Kenny Foner - Ice, Ice, Data (Freezing mutable data structures with Midas) Tom Titchener - Building a real simple music generator to parameterize canons Edward Kmett - Encapsulation vs. Code Reuse Enjoy!
54View on Reddit

u/mightybytein r/haskell • Mentions

On “Haskell Design Patterns: .Extended Modules”

> I actually dislike Types modules, or at least I don't see the point in separating type definitions from the functions that use them. As I said above, I do it because it seems like almost every time I don't do it, I end up having cyclic dependency problems with those modules somewhere down the road. Yes, I know it's sometimes possible to get GHC to build cyclic dependencies, but that never seemed like a good solution to me. And frankly, cyclic dependencies seem like a symptom of poor organization. Maybe my experience is too limited to a narrow application domain, but this seems like a pretty fundamental emergent property of Haskell. > In fact, if you use a separate Types module, you are…
8View on Reddit

u/edwardkmettin r/haskell • Mentions

On “(current) Hidden Modules Considered Harmful?”

I did a mini-rant on this topic a couple of years back: link to this video
3View on Reddit

u/phischuin r/haskell • Mentions

On “Test non public functions”

Yes, also see Edward Kmett - Encapsulation vs. Code Reuse.
2View on Reddit

u/phischuin r/ProgrammingLanguages • Mentions

On “Modularity - the most missing PL feature”

Strongly disagree. I reject the idea of interfaces. They are _always_ either too big or too small. It took us two decades to drive this obsession with "programming against an interface" out of people, so please don't try to put it back. It just obfuscates programs without any benefit. The running example of data structures like stacks is particularly hilarious because it falls apart instantly. There is only one correct implementation of a stack because as you point out the time complexity as well as the effects are very important. I remember how refreshing it was learning about Haskell's `containers`. A type and useful functions using it. No nonsense. Also see Kmett's classical rant [Enc…
-7View on Reddit