Haskell programmer since 2012; GHC contributor since 2018.
Joined April 2012
- Tweets2.7K
- Following257
- Followers2.1K
- Likes4.7K
Pinned Tweet
A blood-black terminal began to scroll.
A system of nodes interlinked
within nodes interlinked
within nodes interlinked
within one AST.
And dreadfully distinct against the dark, a long typechecking trace was displayed.
Vladislav Zavialov retweeted
somewhere on a C++ team, one engineer is weakening atomic memory orderings to save nanoseconds.
another is converting an object to JSON so it can travel over HTTP to a different process on the same machine.
the first engineer needs three approvals.
Vladislav Zavialov retweeted
It's funny how we sometimes don't realize how some things can be confusing to students. Today, I got an email from someone enrolled in the compilers module asking: "How come we access local variables in the stack by their slot number (like LOAD_L 4)? Doesn't that break stack LIFO philosophy? Isn't that just random memory access?"
And honestly, that's a great catch! I never stopped to think that this could trip people, but after his email I get it.
I have added a small text note in that chapter to clarify things. Hopefully it helps others too.
The answer is that there are, indeed, two terminologies in conflict here:
1. We have a stack as this abstract data type that we study in computer science/data structures, which is strict LIFO.
2. But we also have the stack as a "memory region" in systems programming, which is a bit different. Even though we call this memory region a stack, the slots inside each frame are randomly addressable.
TL;DR: the stack (memory region) uses a proper LIFO philosophy when it's stacking (pushing/popping) entire frames. But within a frame, slots are randomly addressable.
Vladislav Zavialov retweeted
If you make something go 20% faster, you did something smart. If you made it go 10x faster, you stopped doing something stupid
Vladislav Zavialov retweeted
using Megaparsec.choice instead of alternative (<|>) helps GHC compile parsers faster. If this were a paper, it would be called “Choice is better than the alternative”
Vladislav Zavialov retweeted
Serokell’s GHC team continues sharing progress on Dependent Haskell.
@int_index presents three major contributions and a host of smaller improvements that push Dependent Haskell closer to becoming a practical reality.
serokell.io/blog/serokell-s-…
Vladislav Zavialov retweeted
I'm so specialized that I had to invent a new word to describe what I do in Icelandic. I might be the only Icelander doing "forritaskáldun" (e. program synthesis)! – at Mölndal, Sverige
"You'll own nothing and be happy" is what a garbage-collected language feels like after using Rust's ownership system.
Did you know these type signatures are not equivalent in Haskell?
f :: forall a b. a -> b -> a
g :: (forall a b. a -> b -> a)
ScopedTypeVariables are a joke.
Just found out that the 45 nm, 32 nm, 28 nm processes, etc., are all marketing terms unrelated to actual gate length. And it's been this way since 1997.
LLM-generated code is embarrassingly bad. I end up rewriting most of it.
However, this was also the case with some developers I used to work with, so I guess LLMs are replacing some of you after all, hug?
MuniHac starts in a week, and I’m going to attend. Train tickets bought, room booked — see you there!