I started Pydhall as an educational project to explore both Dhall and functional programing paradigms in depth. It got a bit out of control and it’s now very close to be a working 16.0.0 compliant implementation, so I decided to make this formal annoucement.
Here’s a summary of the README:
Since yesterday Pydhall can compute an erroneous hash of the Prelude (well… you have to comment out an assert in
Text/show for this to happen). It correctly computes the hash of all modules except for JSON and Natural.
- envvar and local files imports
- semantic hash
Most of the spec tests pass:
62 failed, 1249 passed, 77 xfailed failures are in the not implemented binary-decode tests.
What doesn’t work yet
- HTTP imports
What’s not even clearly designed:
At the moment there is no clear python API to use the generated data structures. A few of them implement an
as_python() method. I think we need a pythonic way to describe a dhall schema.
Thoughts / AMA prompts
The technical details and features are described in the readme. This post is a better place to discuss the Dhall ecosystem implications.
Of course, I’m aware of @SupraSummus work on a python implementation and I acknowledge that pydhall splits the effort, that’s why I was reluctant to talk about the project, before. I’m open to discuss the technically comparison between the projects.
The second hard question is what if pydhall becomes an official implementation ? I’m new to Dhall and I don’t even use it professionaly. I have the feeling that @SupraSummus is both more legitimate and insightful than I am to give their voice in the specification process, even if the dhall-python project is somewhat stale. I guess this two-implementations-for-one-language type of situation is new, and we will have to sort it out when/if Pydhall claims the official implementation status.
Pydhall is a port of dhall-golang. It’s not clear at a first glance, because Pydhall uses the OOP/Python style (methods on terms and values) whereas dhall-golang uses the procedural/golang style (big fat typeswitches). Also, Pydhall has a PEG definition that is heavily inspired by (read copy-pasted from) dhall-golang’s.
This decision is based on the fact that I can read Go more fluently than any other language implementing Dhall. I believe it’s the case for most python developer potentially interested in contributing to Pydhall. Also, the process of porting from golang to python is pretty straightforward.
It was a good decision that eased the bootstrapping of the project a lot. I have no idea if Pydhall will stick to dhall-golang’s design, but I hope that when Pydhall catch up with the standard, the two projects could fuel each other if they don’t diverge dramatically in design. I’ve already spotted and reported bugs in dhall-golang. More eyeballs, less bugs :).
When all the spec tests pass we have to design the python API, for injecting dhall computed values into the python code, defining Dhall types in python, at higher level than the internal type Values and defining custom builtins. I project to battle-test the design by implementing a dhall front-head to either
ansible (maybe re-using @tristanC’s work).
I’m a dhall implementer, now. AMA.