Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parse, Don't Validate and Type-Driven Design in Rust

harudagondi.space

Post reply on HN
Print view View original

61–70 of 89 posts

Re: Parse, Don't Validate and Type-Driven Design in Rust

#61

Post by barnacs »

Every time you introduce a type for a "value invariant" you lose compatibility and force others to make cumbersome type conversions.

To me, invalid values are best expressed with optional error returns along with the value that are part of the function signature. Types are best used to only encode information about the hierarchy of structures composed of primitive types. They help define and navigate the representation of composite things as opposed to just having dynamic nested maps of arbitrary strings.

Re: Parse, Don't Validate and Type-Driven Design in Rust

#62

Post by sbszllr »

unixpickle wrote: post #40

The `try_roots` example here is actually a _counterexample_ to the author's main argument. They explicitly ignore the "negative discriminant" case. What happens if we consider it? If we take their "parse" approach, then the types of the arguments a, b, and c have to somehow encode the constraint `b^2 - 4 a c >= 0`. This would be a total mess--I can't think of any clean way to do this in Rust. It makes _much_ more sen…

I was thinking a similar thing when reading the article. Often, the validity of the input depends on the interaction between some of them.

Sure, we can follow the advice of creating types that represent only valid states but then we end up with `fn(a: A, b: B, c: C) transformed into `fn(abc: ValidABC)`

Re: Parse, Don't Validate and Type-Driven Design in Rust

#63

Post by mrkeen »

barnacs wrote: post #61

Every time you introduce a type for a "value invariant" you lose compatibility and force others to make cumbersome type conversions. To me, invalid values are best expressed with optional error returns along with the value that are part of the function signature. Types are best used to only encode information about the hierarchy of structures composed of primitive types. They help define and navigate the representati…

> They help define and navigate the representation of composite things as opposed to just having dynamic nested maps of arbitrary strings.

What would you say to someone who thinks that nested maps of arbitrary strings have maximum compatibility, and using types forces others to make cumbersome type conversions?

Re: Parse, Don't Validate and Type-Driven Design in Rust

#64

Post by ubixar »

C# gets close to this with records + pattern matching, F# discriminated unions are even better for this with algebraic data types built right in. A Result makes invalid states unrepresentable without any ceremony. C# records/matching works for now, but native DUs will make it even nicer.

Re: Parse, Don't Validate and Type-Driven Design in Rust

#66

Post by barnacs »

mrkeen wrote: post #63
barnacs wrote: post #61

Every time you introduce a type for a "value invariant" you lose compatibility and force others to make cumbersome type conversions. To me, invalid values are best expressed with optional error returns along with the value that are part of the function signature. Types are best used to only encode information about the hierarchy of structures composed of primitive types. They help define and navigate the representati…

> They help define and navigate the representation of composite things as opposed to just having dynamic nested maps of arbitrary strings. What would you say to someone who thinks that nested maps of arbitrary strings have maximum compatibility, and using types forces others to make cumbersome type conversions?

If the fields of a structure or the string keys of an untyped map don't match then you don't have compatibility either way. The same is not true for restricting the set of valid values.

edit: To put it differently: To possibly be compatible with the nested "Circle" map, you need to know it is supposed to have a "Radius" key that is supposed to be a float. Type definitions just make this explicit. But just because your "Radius" can't be 0, you shouldn't make it incompatible with everything else operating on floats in general.

Re: Parse, Don't Validate and Type-Driven Design in Rust

#67

Post by codethief »

throw_await wrote: post #60
spockz wrote: post #53

Earlier quoted context omitted.

Coming from Haskell, I loved Agda 2 as a dependent type language. Is there any newer or more mainstream language that has added dependent types?

Typescript has something that can be used as dependent types, but it wasn't intended as a language feature, so the Syntax is not as ergonomic as Agda: https://www.hacklewayne.com/dependent-types-in-typescript-se...

That whole blog is one big and fascinating rabbit hole into type theory! Thanks for the link!

Re: Parse, Don't Validate and Type-Driven Design in Rust

#70

Post by fspeech »

hutao wrote: post #23

Note that the division-by-zero example used in this article is not the best example to demonstrate "Parse, Don't Validate," because it relies on encapsulation. The principle of "Parse, Don't Validate" is best embodied by functions that transform untrusted data into some data type which is correct by construction . Alexis King, the author of the original "Parse, Don't Validate" article, also published a follow-up, "Na…

Yes division is a poor example. It's a poor separation of concerns to try to wrap at this level without usage context. To see the point try to wrap overflows on arithmetic functions.
Post reply on HN