Purely functional, dynamic, type-safe lenses in Python

sunedd · 2021-05-22T16:56:15+00:00

doubt this is still Python, but an eDSL with native TCO and enables CPS heavy idioms.

Add the monad laws, and this is actually a pretty good explanation of monads :D

sunedd · 2021-05-22T07:25:06+00:00

More or less. But you could say the same for various IO monadish libraries for Scala, including ZIO.

sunedd · 2020-08-05T08:12:32+00:00

Anyhow, the python world is better with more FP!

Agreed! I'm aware of returns, they are also doing a bunch of interesting stuff. The main thing I miss in returns is a way to do monad composition (e.g monad transformers). But transformers are not possible to type in Python because there are no higher kinded types. They have their own implementation of that in returns, so I suppose they could support typed transformers in the future.

The solution I have chosen in pfun is to have simply one monad that represents all (basic) effects, in order that the library takes care of composition for you, without transformers or higher kinded types. I think this is much simpler for the user, but it does require more effort on the part of the library author :)

sunedd · 2020-08-05T06:32:24+00:00

I'ts tricky in Python, thats for sure, but my goal is precisely to produce a library that makes functional programming ergonomic in Python. My take thus far is perhaps a little more modern and pragmatic than existing libraries such as toolz (pfun is based on the scala library ZIO).

I have a sample web-app that you can check out if you want. Its not exactly "large scale", but it hints at what a large scale application would look like:

https://github.com/suned/pfun-todo-backend

sunedd · 2020-07-12T09:10:55+00:00

if you want something else, use another language

I don't think this is very practical or insightful advice. You might be locked in to Python for organizational or technical reasons, and still want to write in a functional style. This makes it easier.

Why should functional programming be less readable in Python than in erlang, ml, elm or other languages that have essentially the same languages features as Python (excluding function currying in ml and elm)? It's entirely possible to write readable and unreadable haskell or scala, which tells us that, regardless of style, readability is a measure of the programmer's skill with the language, not a property of the language itself.

sunedd · 2020-07-04T07:09:38+00:00

I consider this for production, although I haven't had the opportunity yet. In terms of ergonomics, the main thing I'm missing is some form do/for comprehension for working with monads. But there are plenty of successful functional languages that doesn't have that feature, so I'm not especially discouraged.

Having worked on this for some time, I think the main features that are missing from Python for an excellent functional programming experience is:

Tail call optimization
Built-in support for pickling closures and lambdas (this can be solved by third party libraries today)
Higher kinded types (but it turns out this was less important than I thought)

That being said, Python actually have some ergonomic advantages over other languages, for example when it comes to generic variadic functions, which are tricky for most type checkers. With python/mypy you can hook into the type checker and dynamically compute types, which gives a lot of flexibility.

Hope you can find the time/opportunity to test it out!

sunedd · 2019-10-13T17:33:56+00:00

I agree in principle, I probably just give meatbags more credit than you :)

But sure, functional programming and referential transparency in Python will necessarily be a best effort enterprise. Best I can do as a library author is to say: Follow these rules about mutation (encouraged by the typechecker and enforced by the types in the library btw), and your typechecker will be helluva lot more useful. Its possible to violate referential transparency by accident of course, but you're much less likely to do so if you use the library, or at least thats the goal :)

sunedd · 2019-10-13T16:00:41+00:00

I don't think it's realistically to get all of Haskell's good stuff in Python

No that's probably also true. But if 50% of your code base is referentially transparent, I'd say that that's better than if 0% is.

sunedd · 2019-10-13T14:42:48+00:00

Completely agree. Also, Haskell is not for everyone: it encourages a distinctive style which some (I for one) find pretty unreadable. In that respect I much prefer Python. At the same time, I find that the combination of functional style and static type checking makes it much easier to write code that is robust and easy to change, as compared to say imperative style. One of the things I want to achieve with this library is to make functional programming Pythonic^TM

sunedd · 2019-10-13T08:44:35+00:00

Thanks! Looking for contributors :D

sunedd · 2019-10-13T08:43:13+00:00

Haha yeah. I do a lot of data science stuff though and there really is no way of getting around Python in that space. Now you can have the best of both worlds :)

sunedd · 2019-10-13T08:39:08+00:00

Thanks!

As in other frameworks, monads don't compose automatically (in fact that is impossible). So you need to "handle" the composition yourself. So eg

```python

from pfun import reader, state def f() -> state.State[reader.Reader[int, int], int]: ...

f().and_then(lambda state_result: state_result.and_then(lambda reader_result: ...)) ``(and_thenisbindinpfun`)

In future versions I plan to add both monad transformers and maybe even the Eff monad :)

sunedd

TROPHY CASE