are you even playing a deckbuilder roguelike if you're not one-shotting the final boss

Wrote a little #haskell quiz doscienceto.it/extension-or... Can you tell the valid Haskell Language Extensions (based on the GHC docs), from the Impostors?

Inlining: the hard parts bernsteinbear.com/blog/inlinin...

what is happening. apparently the time to compile this code is exponential in the number of ArrayList.push calls (every call ~quadruples it) but the weird part is that my debug output for everything is there in <1s so apparently this time is all spent in LLVM??

i can't believe vega is getting resizable arrays before haskell

The rainbow is here all year long, so we don't need to change the profile for June. But it is a good time to remind everyone that LGBTQIA+ rights are under attack all year long as well. And to steal @haskell.org's message: there would be no Gleam without trans people 🩵🩷🤍

i think the biggest mistake a lot of haskell devs make is thinking that removing mutation means getting rid of state

The past years have seen horrendous attacks towards trans people. We have a duty to protect the most vulnerable members of our communities. There is no Haskell without the trans people who have shaped it through the years. This June is a month of celebrations, but the struggle continues. ✊🏳️‍⚧️λ

oh this is fun. i got a consistent, deterministic segfault in llvm, tried a small fix in my bindings and changed the git dependency in vega to a local file path and it actually made the segfault go away! except i never updated the commit hash, so it was still using the exact same code as before lol

i wonder what the most misunderstsnd/misused theorems are. rice's theorem has got to be number 1 right?

i really don't like how a lot of rust people talk about memory safety. like, I saw something earlier about use od c/c++ being irresponsible because memory unsafe languages are "fundamentally insecure by design".

Serokell’s Work on GHC: Dependent Types, Part 5 serokell.io/blog/serokel... #Haskell #DependentTyples

if only there were a way to achieve memory safety without a borrow checker. someone should really invent that

i think it's kind of interesting that rust has this reputation for choosing efficient memory layouts because it does more than nothing (unlike C/C++), but aside from niche filling and very simple reordering it really can't do a whole lot because it has to maintain contiguous layouts

i'm really not super happy about how i'm exposing sum tags as ints in my MIR. the way i currently have it, a match on a sum is essentially compiled to tag = loadSumTag sum switchInt tag [...] but the problem with this is that it massively limits how smart my layout generation can be

“why is there a Ribosome.hs in the reliability codebase” do not worry about it. it batches www.iankduncan.com/engineering/...

This whole issue seems like a broken system we’ve built where everyone ignores licenses completely.

i really don't think this should be a hot take but providing a library that you made, on your own, for free, telling everyone not to use it with LLMs and implementing something that triggers only if they do it anyway and that only sabotages this library and nothing else is not "malware"

thisisfine.jpg

ughh my implementation of non-contiguous layouts has way too much freedom to work well for sums... back to the drawing board

i'm slowly drifting towards the idea that algebraic data types are Bad Actually and that the OO people were right. i'm not quite there yet but i'm getting closer

one feature I would love to see in a language that actually tries to be low level (i.e. probably not vega) is control over the representation of values in-flight. all modern "low-level" languages really pretend we're on a basic stack machine where every value is always stored in memory

i'm reworking vega's layout generation code right now (non-contiguous layouts yay) and every few functions a little @waffle.pet pops up in my mind and tells me that what i just called 'size' was actually the stride

oh god I'm going to need higher-rank polymorphic type constructors aren't i?

in today's installment of "i wish this haskell code were vega": god i hate hs-boot files

"i couldn't decide which of the 7 existing libraries to contribute my change to so i made another one" never change, haskell ecosystem

this post but s/type safety/memory safety/ and s/newtypes/unsafe blocks/ lexi-lambda.github.io/blog/2020/11...

i'm scaring the rust programmers (writing a doubly linked list)

it's so cool to think of a clever data structure and then get to write `O(1)`, `O(1) amortized` on every function

i git pulled vega's repo on a different machine after ~2 weeks and got a little surprised for a second lol (i renamed the test directory)

in general what i think is soo cool about fil-c is that it stays memory safe even with adversial inputs. like, how many languages even support that? javascript, properly sandboxed lua... i guess dhall? but none of those are even remotely similar to C lol

has someone run FilPizlonator (the fil-c pass) on rust code to make rust actually memory safe?

New blog post: "Erasing Existentials" https://wolfgirl.dev/blog/2026-05-20-erasing-existentials/ #programming #rust

canonical class Functor[*(rf : Rep :-> Rep)](*f : forall *(r : Rep). Type(r) :-> Type(rf(r))) declarations dreamed up by the utterly deranged

i just spent ~an hour of my life debugging a segfault only to find out that LLVMGetParam gives you a garbage value if you give it an index that is out of bounds. this could have been 30 seconds if c++ programmers could just get off their high horse and include a fucking bounds check

um

is there any literature on like, event based constraint solvers for type checkers? as in, "if this unification variable is bound, all the constraints that depend on it are unblocked" this seems like a pretty natural approach to me but i've never actually seen it anywhere else

writing tests for a compiler is fun because you'll come up with all these pieces of code that literally noone will ever write

okay, i think this should work!! the overhead is now: - nothing for calls to pure functions - 1 register for calls to functions with the same effect set as the caller - 1 register + O(|e|) memory accesses for calls to functions with an effect set e that differs from the active effect set

ugh, tail calls suck

vega is now officially HTTP-server-complete!! github.com/Innf107/meri...

just saw a guy in a hoodie that said (and this is not a typo) "all lifes matter" which, first of all ew but also you're not beating any stereotypes lol

i might add a construct loop f(x = 5) = ... that desugars to let f(x) = ... f(5) because the number of times i've written a tail recursive loop like that and then forgotten to actually call it is higher than i'd like to admit ^^ (and it's also much less awkward that way if f is long)

haskell: the only language where turning something `unsafe` into something `safe` can introduce segfaults

Since neither Rust nor zig have a specification of their semantics the translation is semantic preserving

this is fun, if i dump the resulting MIR, i get different debug logs (it's because if i don't dump the MIR, the value that fails here (from a pure computation) isn't actually forced until after all declarations have been at least partially compiled already)

why does my array have a length of 93824993214529...

one common mistake people make with voice training is that they put way too much emphasis on pitch. pitch isn't completely unimportant, but you also really need to make sure to work on your roll and yaw!

so, in rust `dyn Trait` means `exists s. Trait(s) /\ s` and `fn f() -> impl Trait` means `f : exists s. Trait(s) /\ (() -> s)` but what if i want an existential over something other than the Self parameter? like, what if i have Trait<B> and i want an `exists s b. Trait(s, b) /\ s`?

how would you do this in rust? let's say you have some type `Blah<T>` with a type parameter and you want to define an instance of Blurg for Blah<i64>, but you also want this to be the only possible instance for Blah (disallowing e.g. one for Blah<f32>) so that instance resolution is never ambiguous