A fun recent experience I had with Claude was I asked it to write a model for PBTs against a complex SUT, and it duplicated the SUT algorithm in the model — not helpful! I had to explicitly prompt it to write the model algorithm in a completely different style.

Ugh, yeah. Duplicating the code under test is a bad habit that Claude has had when writing property-based tests from very early on and has never completely gone away.

Hmm now that you mention it we should add some instructions not to do that in the hegel-skill, though oddly I've not seen it doing it so far.

Hi David, congratulations on the release! I'm excited to play around with Hypothesis's bitstream-based shrinking. As you're aware, prop_flat_map is a pain to deal with, and I'd love to replace some of my proptest-based tests with Hegel.

I spent a little time looking at Hegel last week and it wasn't quite clear to me how I'd go about having something like a canonical generator for a type (similar to proptest's Arbitrary). I've found that to be very helpful while generating large structures to test something like serialization roundtripping against — in particular, the test-strategy library has derive macros that work very well for business logic types with, say, 10-15 enum variants each of which may have 0-10 subfields. I'm curious if that is supported today, or if you have plans to support this kind of composition in the future.

edit: oh I completely missed the macro to derive DefaultGenerator! Whoops

Yep, `#[derive(DefaultGenerator)]` and `generators::default<T>()` are the right tools here.

This is one of the areas we've dogfooded the least, so we'd definitely be happy to get feedback on any sharp corners here!

I think `from_type` is one of Hypothesis's most powerful and ergonomic strategies, and that while we probably can't get quite to that level in rust, we can still get something that's pretty great.

What do you think we're currently missing that Python's `from_type` has? I actually think the auto-deriving stuff we currently have in Rust is as good or better than from_type (e.g. it gets you the builder methods, has support for enums), but I've never been a heavy from_type user.

`from_type` just supports a bunch more things than rust ever can due to the flexibility of python's type system. `from_type(object)` is amazing, for example, and not something we can write in rust.

Yeah, that's true. I was going to say that it's maybe not fair to count things that just don't even make sense in Rust, but I guess the logical analogue is something like `Box<dyn MyTrait>` which it would make sense to have a default generator for but also we're totally not going to support that.

Thank you! I have some particularly annoying proptest-based tests that I'll try porting over to Hegel soon. (Thanks for writing the Claude skill to do this.)

Please let us know how it goes!

As Liam says, the derive generator is not very well dogfooded at present. The claude skill is a bit better, but we've only been through a few iterations of using it and getting Claude to improve it, and porting from proptest is one of the less well tested areas (because we don't use proptest much ourselves).

I expect all of this works, but I'd like to know ways that it works less well than it could. Or, you know, to bask in the glow of praise of it working perfectly if that turns out to be an option.

My understanding is that that is a maximalist position for the avoidance of risk, and is sufficient but probably not necessary.

A very important thing about constraints is that they also liberate. TUIs automatically work over ssh, can be suspended with ctrl-z and such, and the keyboard focus has resulted in helpful conventions like ctrl-R that tend to not be as prominent in GUIs.

What does ctrl-R do?

History search, like in shells. My most used TUI shortcut!

Just dropping this here because I had no idea about/ignored tools like this until recently, in case you weren't aware of them, but it's been a big help in my workflow https://github.com/atuinsh/atuin

I'm not a professional, but to me it's clear that whether i and -i are "the same" or "different" is actually quite important.

I'm a professional mathematician and professor.

This is a very interesting question, and a great motivator for Galois theory, kind of like a Zen koan. (e.g. "What is the sound of one hand clapping?")

But the question is inherently imprecise. As soon as you make a precise question out of it, that question can be answered trivially.

Generally, the nth roots of 1 form a cyclic group (with complex multiplication, i.e. rotation by multiples of 2pi/n).

One of the roots is 1, choosing either adjacent one as a privileged group generator means choosing whether to draw the same complex plane clockwise or counterclockwise.

They would never be the same. It's just that everything still works the same if you switch out every i with -i (and thus every -i with i).

There are ways to build C that result in:

1) Exactly one C

2) Exactly two isomorphic Cs

3) Infinitely many isomorphic Cs

It's not really the question of whether i and -i are the same or not. It's the question of whether this question arises at all and in which form.

The question is meaningless because isomorphic structures should be considered identical. A=A. Unless you happen to be studying the isomorphisms themselves in some broader context, in which case how the structures are identical matters. (For example, the fact that in any expression you can freely switch i with -i is a meaningful claim about how you might work with the complex numbers.)

Homotopy type theory was invented to address this notion of equivalence (eg, under isomorphism) being equivalent to identity; but there’s not a general consensus around the topic — and different formalisms address equivalence versus identity in varied ways.

PP meant automorphisms, which is what the OP article is about.

They're different. Multiplication by i gives a quarter turn counterclockwise. -i gives a quarter turn clockwise.

Opposite quarter turns cancel: (-i)(i) = (-1)(i^2) = +1

Quarter turn twice counterclockwise gives a half turn: (i)(i) = -1

Quarter turn twice clockwise also gives a half turn: (-i)(-i) = -1

Sure. Either that or the reverse. "They're not the same" in the sense that they can't both be clockwise. "They are the same" in the sense that we could make either one clockwise.

A bit like +0 and -0? It makes sense in some contexts, and none in others.

Migrating to a place where people can contribute more to society is both a core tenet of individual liberty and one of the most positive-sum things any human being can do.

But given that you both feign concern over visa holders' working conditions [1], while at the same time advocating for policies that lead to worse working conditions [2], perhaps you just hate freedom and were never acting in good faith in the first place.

[1] https://news.ycombinator.com/item?id=45656527

[2] https://news.ycombinator.com/item?id=45323501

It's just the process of learning the hard way that not heeding the warnings everyone gave is painful.

Now that they're facing consequences which we warned about (and prepped for as a result) they want to ignore it thinking that the monsters under the bed will go away.

Brain drain somewhere is brain gain elsewhere.

Ah yes, the inevitable future where the only way we'll know to interact with the machine is through persuading a capricious LLM. We'll spend our days reciting litanies to the machine spirits like in 40k.

Praise and glory be to the Agentic gods. Accept this markdown file and bless this wretched body of flesh and bone with the light of working code. Long live the OpenssAIah

I talk to one of my doctors over Signal.

Language-specific package managers are a natural outgrowth of wanting portability across platforms.