3 ms·

How would you define f in a different language such that f(g()) worked? You couldn’t do that in Go, for instance.

by rcme 3y ago

titzer 3y ago
There's at least one language, Koka (https://koka-lang.github.io/koka/doc/book.html https://koka-lang.github.io/koka/doc/book.html) that has effects in its type system. There are probably others. If you don't have effects, you could use union types.
- rogerkeays 3y ago
  This language looks really cool. Thanks for sharing.
clhodapp 3y ago
Simple! You just make f take in g's result type.
- rogerkeays 3y ago
  ... not sure if serious or not
  - clhodapp 3y ago
    I'm completely serious in the sense that you could do that and really would in some situations. You might do it because you want to factor the handling of the different result cases out to another function.
    - rogerkeays 3y ago
      You don't think it would limit the independent use of f()?
      - masklinn 3y ago
        No? Surely if f() takes a full result (including error condition) it's because there's something it wants to do with that?
  - EspressoGPT 3y ago
    Very serious. https://pkg.go.dev/text/template#Must https://pkg.go.dev/text/template#Must
hedora 3y ago
In rust, you write "f(g()?)", and make sure that your function body returns a Result<> with an error type that g()'s error type can be converted to. It works great. Also, note that f() doesn't care about the type of error returned by g(), and that it will be a compilation error if g()'s error type turns into something incompatible. Sadly, there are proposals to add exceptions to rust, and it seems likely they will be accepted, breaking error handling semantics across the entire ecosystem (even in new code, since exceptions are too hard to use correctly).
- rcme 3y ago
  What's the rationale behind adding exceptions?
  - emi2k01 3y ago
    I'm not sure what they mean by adding exceptions. AFAIK, the only proposal related to exceptions is adding a `try` block that would scope the `?` operator to that block instead of the current function.
masklinn 3y ago
You could actually, iirc if f takes as many parameters as g returns it works out. In a better langage f would take a Result, and then it can manipulate that however it wants. Obviously you can also plug in adapters if you need some other composition e.g. g().map(f), g().and_then(f), …
EspressoGPT 3y ago
> You couldn’t do that in Go, for instance. You can – by making f accept g's return types, including the error. This is even being done in the Go standard library: https://pkg.go.dev/text/template#Must https://pkg.go.dev/text/template#Must
- rcme 3y ago
  That’s interesting, but consider two functions like func ParseInt(string) (int, error) and func Abs(int) int. You lose some composability when using errors over exceptions. The Rust solution mentioned elsewhere seems elegant.

How would you define f in a different language such that f(g()) worked? You couldn’t do that in Go, for instance.

by rcme 3y ago

How would you define f in a different language such that f(g()) worked? You couldn’t do that in Go, for instance.

There's at least one language, Koka (https://koka-lang.github.io/koka/doc/book.html https://koka-lang.github.io/koka/doc/book.html) that has effects in its type system. There are probably others. If you don't have effects, you could use union types.

rogerkeays 3y ago
This language looks really cool. Thanks for sharing.

clhodapp 3y ago

Simple! You just make f take in g's result type.

rogerkeays 3y ago
... not sure if serious or not
- clhodapp 3y ago
  I'm completely serious in the sense that you could do that and really would in some situations. You might do it because you want to factor the handling of the different result cases out to another function.
  - rogerkeays 3y ago
    You don't think it would limit the independent use of f()?
    - masklinn 3y ago
      No? Surely if f() takes a full result (including error condition) it's because there's something it wants to do with that?
- EspressoGPT 3y ago
  Very serious. https://pkg.go.dev/text/template#Must https://pkg.go.dev/text/template#Must

hedora 3y ago

In rust, you write "f(g()?)", and make sure that your function body returns a Result<> with an error type that g()'s error type can be converted to. It works great. Also, note that f() doesn't care about the type of error returned by g(), and that it will be a compilation error if g()'s error type turns into something incompatible. Sadly, there are proposals to add exceptions to rust, and it seems likely they will be accepted, breaking error handling semantics across the entire ecosystem (even in new code, since exceptions are too hard to use correctly).

rcme 3y ago
What's the rationale behind adding exceptions?
- emi2k01 3y ago
  I'm not sure what they mean by adding exceptions. AFAIK, the only proposal related to exceptions is adding a `try` block that would scope the `?` operator to that block instead of the current function.

masklinn 3y ago

You could actually, iirc if f takes as many parameters as g returns it works out. In a better langage f would take a Result, and then it can manipulate that however it wants. Obviously you can also plug in adapters if you need some other composition e.g. g().map(f), g().and_then(f), …

EspressoGPT 3y ago

> You couldn’t do that in Go, for instance. You can – by making f accept g's return types, including the error. This is even being done in the Go standard library: https://pkg.go.dev/text/template#Must https://pkg.go.dev/text/template#Must

rcme 3y ago
That’s interesting, but consider two functions like func ParseInt(string) (int, error) and func Abs(int) int. You lose some composability when using errors over exceptions. The Rust solution mentioned elsewhere seems elegant.