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

The power of Result types in Swift

swiftbysundell.com

Post reply on HN
Print view View original

51–60 of 77 posts

Re: The power of Result types in Swift

#51

Post by orbifold »

igouy wrote: post #30
drb91 wrote: post #13

Earlier quoted context omitted.

What would a typeless language look like?

"In BCPL,flexibility is retained by eliminating the concept of data types and representing all quantities by bit patterns of the same length. A single vector may, for example, hold bit patterns representing numbers, booleans and pointers to other vectors. Variables are declared before use, but simply as variables, not as variables of any particular type." See chapter 13 example BCPL programs: http://www.cl.cam.ac.uk/…

Sounds like a nightmare, this is basically the type system of vanilla verilog: Everything is just a bitvector of a certain length, each bit can have four states X,Z,0,1, so that it allows you to assign to a 32bit vector a 16bit vector resulting in the upper 16bit to be undefined. System verilog added structs, but if you declare them packed they allow unstructured assignment. Overall it is a complete nightmare given the fact that at the end you will tape out a chip that might cost >1 million to produce.

Re: The power of Result types in Swift

#52

Post by masklinn »

taeric wrote: post #39
wereHamster wrote: post #35

Earlier quoted context omitted.

You can improve that code by having a single error type. Either by returning the same error from both handlers or having an error sum type which contains both errors. You probably don't really care about the exact error that can be thrown by either handler, you just need enough information to display a sensible message to the user. NSError may be just enough for that purpose! After doing that, the type of Handler3 ca…

Didn't the post you are responding to say that? I suspect you didn't read past the example. The problem comes because you have to either use a single error for two parts or deal with a tough explosion of types. No?

There are known solutions to this problem: you can type-erase to a single supertype (e.g. Error/NSError[0]) or convert from the third-party's type to a first-party type[1] for instance.

[0] https://developer.apple.com/documentation/swift/error

[1] https://boats.gitlab.io/failure/

Re: The power of Result types in Swift

#53

Post by pjmlp »

orbifold wrote: post #51
igouy wrote: post #30

Earlier quoted context omitted.

"In BCPL,flexibility is retained by eliminating the concept of data types and representing all quantities by bit patterns of the same length. A single vector may, for example, hold bit patterns representing numbers, booleans and pointers to other vectors. Variables are declared before use, but simply as variables, not as variables of any particular type." See chapter 13 example BCPL programs: http://www.cl.cam.ac.uk/…

Sounds like a nightmare, this is basically the type system of vanilla verilog: Everything is just a bitvector of a certain length, each bit can have four states X,Z,0,1, so that it allows you to assign to a 32bit vector a 16bit vector resulting in the upper 16bit to be undefined. System verilog added structs, but if you declare them packed they allow unstructured assignment. Overall it is a complete nightmare given t…

BCPL main goal was to Bootstrap CPL, but then some people decided to use it on its own, and the rest is history.

Re: The power of Result types in Swift

#55

Post by cousin_it »

KirinDave wrote: post #33

The tricky part of this approach comes when you extend it. Let's say we have two functions and we'd like to combine them and return a third. typealias Handler1 = (Result -> Void) typealias Handler2 = (Result -> Void) func load(addr: Address, then handler: @escaping Handler1) { ... } func lookup(name: string, then handler: @escaping Handler2) { ... } // What would the type of Handler3 be? func loadDefault(then handler…

I think "sum-type errors" are the wrong default. They force you to deal with the bureaucracy of different error types, which is useless because error handling almost never cares about error type. And they don't give you a stack trace, which is a lifesaver for development and debugging. Plain old unchecked exceptions work better. Probably cheaper too, because sum types require wrapping and unwrapping at each step, while exceptions can be very cheap when not thrown.

Re: The power of Result types in Swift

#56

Post by khitchdee »

dagenix wrote: post #29
khitchdee wrote: post #11

While typing is a good way to reduce programmer errors, specially for large scale programs, it's much like autocomplete in a word processor. It's cool to have but also a bad habit to form. The quality of prgrams would improve if such aids were reduced and the programmer was expected to form good programming habits instead.

I've read many people complain about static typing + more advanced type systems making programming too hard. This is the first time I've ever read someone assert that they make programming too easy.

They try to make programming easier but fail at it. Experienced programmers take this change in their stride. New programmers are most effected.

Re: The power of Result types in Swift

#57

Post by javier2 »

solidsnack9000 wrote: post #46
nine_k wrote: post #37

Earlier quoted context omitted.

Also, the idea of mapping and folding, which is now everywhere, and is not limited to traditional collections. (Likely applicatives will take another decade to go mainstream.)

The 4th generic added to Go will be our memorial. Erring[ResultType]

Wouldn't that be the day. The funny part is how they preached 'errors are values', and instead of giving a good error monad, they implement a poor version of it explicitly where they feel like it.

Re: The power of Result types in Swift

#58

Post by _pmf_ »

Smaug123 wrote: post #2

I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…

I refuse to see where the difference to exception handling is. My exceptions bubble up to my "sad path" handler.

Re: The power of Result types in Swift

#59

Post by lmm »

mpweiher wrote: post #4
Smaug123 wrote: post #2

I've seen this referred to as "railway programming", and there's a wealth of explanation over at https://fsharpforfunandprofit.com/rop/ . In particular, the slide deck from the FP eXchange contains a diagram (slide 75 out of 154) with a happy path along the top, and a sad path along the bottom, and at every stage when you `bind` a Result into an existing Result, you have the opportunity to divert into the sad path. N…

What I found interesting is that if you have a pipe/filter architectural style, your happy path stays completely free of error handling, because when a filter doesn't have a good result, it just doesn't pass any data to the next filter in line. Done! You can then centralize the error handling by having a "stderr"-like output on your filters. When you have a call/return architectural style, you need to return somethin…

I find this concept of a "stderr output" far more complicated. What's next, a "controlling terminal"?

Values are much easier to reason about and inspect than functions, so it's better to have simple functions that return complicated values than to complicate the functions themselves.

Post reply on HN