FP-Go: Functional programming library for Golang • Hacker News Board

Re: FP-Go: Functional programming library for Golang

#181

Post by cleue » Tue, Aug 22, 2023, 9:19 PM UTC

zelphirkalt wrote: post #157

mc10 wrote: post #49

Earlier quoted context omitted.

data := F.Pipe3( T.MakeTuple2("https://jsonplaceholder.typicode.com/posts/1", "https://catfact.ninja/fact"), T.Map2(H.MakeGetRequest, H.MakeGetRequest), R.TraverseTuple2( readSinglePost, readSingleCatFact, ), R.ChainFirstIOK(IO.Logf[T.Tuple2[PostItem, CatFact]]("Log Result: %v")), ) This looks like a pain to modify if you're not intimately familiar with the fp-go library and are just trying to insert a debug statemen…

Is there no way to access all arguments or rest arguments in Go? Why limit map and traverse tuple to 2?

Unfortunately there is no way to use variadic arguments in a type safe way in go (yet) - except for the special case that all arguments are of the same type.

This is why some of the functions that work with many arguments (such as `Pipe`, `Flow`, `Traverse` ...) carry their cardinality as a suffix. Their shapes are then auto-generated up to a max cardinality that seems to make sense in practice.

So the traverse tuple function does not only exist for cardinality 2 but also for higher ones. But unfortunately you have to specify it explicitly.

Re: FP-Go: Functional programming library for Golang

#182

Post by cleue » Tue, Aug 22, 2023, 9:23 PM UTC

Spiwux wrote: post #41

Go is not a functional language and its generic type system is very restrictive. Why not use a functional language to begin with?

Because in some cases the aspect whether or not the language is functional is not the only decision criteria for the choice of language. If it was, I would absolutely recommend to consider a language than go. But if go is selected because of different criteria (i.e. interoperability with an existing eco-system, cross compilation support, FIPS compliance, ...) then this library can help to apply fp paradigms in you go code. Hopefully to make it readable and testable.

Re: FP-Go: Functional programming library for Golang

#183

Post by cleue » Tue, Aug 22, 2023, 9:35 PM UTC

beltsazar wrote: post #79

As much as I like the functional paradigm, I don't think it will work well on Go due to two simple reasons: 1) Go doesn't have a concise lambda expression. This makes the functional approach in Go will be more verbose and less readable than the traditional imperative approach. 2) Go's type inference is not sophisticated enough. Most of the time you will still need to explicitly annotate the types, which, again, makes…

1) I would argue that with fp style you might want to structure your code into small, pure functions, anyway, for testability reasons. Also many functions from the go library are already pure functions with one input and one output, so they can be used right way, e.g. `Atoi` from `strcov` or `ToUpper` from `strings`. Also go has the nice feature that you can pass methods on structs (member functions) from their instance as functions (the instance reference is bound in a closure). So lambda functions are not really needed that much

2) I absolutely agree, type inference could be better. However this has improved over time and go1.21 has also made good progress. I would expect that type inference will continue to improve in the future. This library tries to easy the pain of having to specify types redundantly by carefully choosing the order of type parameters. Those parameters that can be inferred (e.g. because they are part of the immediate function argument) come last, whereas the parameters that cannot be inferred come first, so you only have to specify those. This compromizes on a consistent type ordering, preferring useability over (internal) consistency. Examples are `Left` and `Right` of the `either` package. The order of type parameters is reversed between the two to avoid excessibe typing.

Re: FP-Go: Functional programming library for Golang

#184

Post by cleue » Tue, Aug 22, 2023, 9:42 PM UTC

Spiwux wrote: post #44

I_am_tiberius wrote: post #35

Was just scrolling through the docs. Does anyone feel comfortable with all these generic type annotations? I'm not expert programmer but this looks overkill to me.

Why, what's wrong with func TraverseParTuple10[F1 ~func(A1) ReaderIOEither[T1], F2 ~func(A2) ReaderIOEither[T2], F3 ~func(A3) ReaderIOEither[T3], F4 ~func(A4) ReaderIOEither[T4], F5 ~func(A5) ReaderIOEither[T5], F6 ~func(A6) ReaderIOEither[T6], F7 ~func(A7) ReaderIOEither[T7], F8 ~func(A8) ReaderIOEither[T8], F9 ~func(A9) ReaderIOEither[T9], F10 ~func(A10) ReaderIOEither[T10], A1, T1, A2, T2, A3, T3, A4, T4, A5, T5,…

This is also one of my favorites, but it can get even more verbose. However this is how the go type system is designed to work with covariance. Without the `~` operator these functions could only be used for a much smaller range of inputs.

But this complexity is an implementation detail of the library, you do not have to understand it as a user of these functions. From my perspective it is a valid approach to move complexity from use application layer into the library layer, so it can be hidden there and tested once.

Re: FP-Go: Functional programming library for Golang

#185

Post by eweise » Thu, Aug 24, 2023, 3:37 PM UTC

sambeau wrote: post #149

eweise wrote: post #120

Earlier quoted context omitted.

To me, the problem is that Go returns two values which makes it hard to compose functions.

That's deliberate to stop you trying to compose functions that return errors. You should be explicitly handling the errors before you compose.

great, except 99% of the time I want to handle the error by bubbling it up to a top level routine.

From my experience, "handling" the error means wrapping it in another error and returning, which is what you get from other languages for free.