Haskell language features and standard libraries in pure Python

by asib • 6 years ago

136 32 6 years ago

tingletech• 6 years ago

no commits in 5 years, from reading the issues, this seems like a more maintained alternative https://github.com/evhub/coconut

phonebucket• 6 years ago

While coconut looks very cool, does it include a Hindley-Milner type system and type classes?

Those are big features of Haskell that I see implemented in this repo that I couldn't see in Coconut.

But I could be mistaken. I don't know much about Coconut.

ben509• 6 years ago

From the FAQ[1]:

Does Coconut support static type checking?
Yes! Coconut compiles the newest, fanciest type annotation syntax into version-independent type comments which can then by checked using Coconut’s built-in MyPy Integration.

So it uses MyPy. I've never seen documentation on what overall algorithm they use, and the code[2] is not an easy read.

[1] https://coconut.readthedocs.io/en/master/FAQ.html#does-cocon...

[2] https://github.com/python/mypy/blob/master/mypy/typeanal.py

ivan_ah• 6 years ago

this fork has a working py3 version https://github.com/mvaled/hask

prionassembly• 6 years ago

More, not entirely related projects

https://github.com/vindarel/languages-that-compile-to-python

anentropic2• 6 years ago

Quite an epic effort, but (I'm guessing, due to the age of it) none of the type system stuff is checkable via mypy etc

it seems like instead there's a bunch of runtime type-checking going on (or at least... "at import time", i.e. runtime but as early as possible)

zitterbewegung• 6 years ago

README says Python 3.x support in the future and others have stated the library is inactive for five years .

zanellia2• 6 years ago

Indeed, I guess much of the type annotation stuff would be much easier with type hints from Python 3.6+ (https://docs.python.org/3/library/typing.html), plus it might add some level of compatibility with recently developed static analysis tools like mypy, pyright, pyre.

anentropic2• 6 years ago

I have seen various efforts to do this stuff in a way that is checkable via mypy (i.e. using Python's own type system + as much dynamism is still type-able) and so far it looks like it's a much harder task

These folks have several excellent projects in that direction though: https://github.com/dry-python/

amelius• 6 years ago

Sadly, creating decent-looking multi-line lambda functions is not really possible in Python, afaik.

klipt• 6 years ago

Why does it need to be anonymous if it's multi line? You can just do a local 'def'.

rowanG0772• 6 years ago

You cannot use def within function call parenthesis.

rudolph94• 6 years ago

Lazy evaluation lists is nice.

Strongly typed and purely functional are very appealing, but lazy evaluation is what really differentiates Haskell in my opinion. `take 5 (repeat 0) —- [0,0,0,0,0]` and equivalent in hask `take(5, L[0, 0, ...])`

I wonder how ubiquitous lazy evaluation is?

scns• 6 years ago

Simon Peyton Jones said that lazy evaluation was a mistake.

MycroftJones• 6 years ago

Glad to hear he said that. He is right.

rudolph94• 6 years ago

When did he say that?

From what I have read he has stated that it forced purity and I’d be interested to see the context where he calls it a “mistake”.

rudolph94• 6 years ago

Host: How did laziness and purity come together?

Simon Peyton Jones: So, Haskell’s initial defining characteristic was that it was a lazy language. That’s what brought that particular group of people together, what we thought was exciting and cool. But in retrospect, I now think what was much more important was that laziness forced Haskell to be a pure language. By which I mean, in a call-by value functional language like ML or Lisp, if you wanted to print something it was too tempting to have a function, in quotes, which, when you call it, would print something as a side effect. That is, it wouldn’t just return well what would print return? Unit or 3 or something. But it would print something on the side. So, we couldn’t do that in a lazy language because we couldn’t predict the evaluation order well enough. So, laziness kept us pure. And purity was embarrassing for a long time, because you couldn’t really do much by way of input/output. You couldn’t print things or open files or launch missiles or sail the boat. So that forced us to invent what came to be called monadic input/output. And there was another classic example which Phil Wadler, my colleague at Glasgow, took ideas from the logic world. The theory of monads developed by various people. But he was particularly drawn on the work of Eugenio Moggi, who was very much a theorist. Phil Wadler wrote this wonderful paper comprehending monads in which he described monads as a programming idiom. And then he and I subsequently wrote a paper called ‘Imperative Functional Programming’ which showed how you can apply monadic programming to do input/output to affect the world. And that idea has been wildly infectious. That’s spread to all sorts of places. So, people now use the monadic thought pattern as a design idea for designing their programming languages or ways to… you could see it all over the place now. But it only happened because we were stuck with purity because we had laziness. It was another place where the sort of theory both helped the practice and also almost forced the practice, because we would have had to break with our principles too much to just have side effects. So, we were stuck with no side effects and were forced to invent this alternative way of going about things.

https://www.microsoft.com/en-us/research/podcast/functional-...

wqsz7xn2• 6 years ago

Applicative : minimally complete definition: pure

Huh? Where's (<*>) or liftA2? It's nice having all those types and everything to work over but if the applicative instance is wrong then the monad instance is wrong and then there isn't really a point in using the library? The nice thing about haskell is that all of the laws can be covered by quickcheck. Would be cool if there was something similar here!

asib2• 6 years ago

Aha yes interesting. I would say that I think this is a minor issue in the grand scheme. The meat of this library is, to my eyes, the type system and language features. More concretely, if the implementation of typeclasses is correct, I'm less concerned that the definition of Applicative is not (although I recognise that it doesn't necessarily inspire confidence). Fixing that definition is relatively straightforward.

wqsz7xn2• 6 years ago

Yeah I get that, but then again the Semigroup, Monoid, Functor, Applicative and Monad classes should aim to be correct because they form the base of a lot of other typeclasss. Maybe this project is something that I can contribute to in my free time :). I was missing a lot of the functional language features in python. It's a shame that it's still so clunky to work with lambdas etc.

asib2• 6 years ago

I posted this because, frankly, I was pretty amazed that someone managed to reproduce these features in Python and lose almost none of the ergonomics of Haskell. So from a purely academic perspective, I think this is a very impressive feat.

Having said that, whenever I consider using something like this - language features of language A ported to language B - I always conclude that it doesn't make sense. If I want those features, I might as well just use language A. Trying to shoehorn them into language B is just going to make it difficult for newcomers to the codebase. That's not even mentioning the fact that these libraries inevitably have "blind spots" in terms of what's been (re)implemented. I'll probably realise hours or days in that that one language feature I need to implement something doesn't work correctly and now I've got to write some ugly workaround (which defeats the point of using the library for cleaner code), or scrap the work I've done and return to using vanilla language B.

abalaji• 6 years ago

One reason might be to leverage the Python package ecosystem while not missing some features of Haskell that you might like. Though, on the whole completely agree.

blinkenlights20• 6 years ago

Really impressive to pull this off!

I think it's great to see more fp inspired libraries popping up in a lot of places, especially for languages that are "known to ship" and where you can apply fp programming patterns in an incremental style instead of going "all in" with a pure fp language.

The more I'm exposed to fp concepts, the more I think we have a lot to win with exposing more and potential alien programmers to the subject to pick up the good parts.

I can recommend fp-ts in case you're doing web stuff, their either implementation looks nicer and it's in active support.

type Either<E, A> = Left<E> | Right<A>

cwhy2• 6 years ago

This is also a nice recent attempt on utilizing Python ecosystem and FP features of Haskell(Purescript):https://github.com/purescript-python/purescript-python/blob/...

Haskell language features and standard libraries in pure Python

Related Stories