Issue#157 Add python support

[julian-berbel]

Fixes #157.

We may want to hold on to merge this since the travis build fails because of high build times?

[flbulgarelli]

Why the extra quotes?

[julian-berbel]

The parsed strings include them.
"something" gets parsed to Strings ["\"something\""].

I didn't remove those because the parser makes no distinction between normal strings and multline strings, and in case someone actually wanted a string which starts with quotes. E.g. "\"something\"".

[julian-berbel]

Rethinking that though, if one were to want to parse a string which starts with quotes, this would be parsed as a triple escaped quote.
"\"something\"" would become Strings ["\"\\\"something\\\"\""].

So I guess I could take them out?

Thoughts?

[julian-berbel]

Also, I thought multiline strings got parsed to a list with as many elements as there were lines in the string (that's the why of the intercalate "\n" here), but apparently that's not the case. They also get parsed to a single element list.
So I have no clue as to why they get parsed to a list in the first place.

[flbulgarelli]

@rodri042 could you investigate alternative ways of speeding up the build time? Perhaps improving caching or using docker?

[flbulgarelli]

I have being investigating about the slow build times in python library. This is apparently a problem with GHC itself, which is slowing down happy-generated parsers.

See:

• https://ghc.haskell.org/trac/ghc/ticket/14683#ticket and https://ghc.haskell.org/trac/ghc/ticket/14683#comment:8
• GHC takes a very long time to compile parser generated by Happy 1.19.8 compared to Happy 1.19.5 haskell/happy#109

[flbulgarelli]

Apparently this project has coped with this situation and is actually building things in travis 😮 We should check its https://github.com/diku-dk/futhark/blob/master/.travis.yml

[flbulgarelli]

🆙 Building language-python from source and using resolver: ghc-8.4.1 makes compilation actually end. However, using that resolver is not trivial with mulang.

So, an option could be updating mulang to that - nightly- resolver and pointing language-python to its github's master branch - is that even possible with stack ?.

An other option could be forking it, and applying this patch: antalsz/hs-to-coq@c538e6a

[flbulgarelli]

Also using a more stable lts like 10.2 (ghc 8.2.22), see https://github.com/bjpop/language-python/blob/a5aeabfa58b65a742a6a6745720b4864c0ea770c/stack.yaml#L18, and applying the patch makes language-python compile in good-enough time. But this implies forking, and I'd like to avoid that if possible.

Now - after fixing the travis timeouts with travis_wait - the whole build is taking 25 - 30 minutes, and 6 minutes using travis cache - which is ok. I insist this is not ideal, but it works.

And, in any case, we need to update our lts to be more up-to-date, since both solutions require moving to more recent snapshots. So I will merge this PR by now and then work on the deps update #170