I want to produce revised, fresh versions of this diagram, which appears in the Haskell98 standard:
In 2019 I will do this by generating a description of the graph I want, and feeding it to Graphviz. A proof-of-concept implementation I did yesterday, told only that there is something called Monad, can automatically produce this diagram:
The proof-of-concept program is rather awful, because the way it traverses the graph is by sending :info commands to GHCi and attempting to parse the output. I am not interested in pushing this approach any further.
The right way to do this is to figure out how GHC represents the class and instance information internally, then use its API to interrogate those data structures directly.
I have spent quite some time looking around in the GHC API documents but I have not found the entry points I need.
I think I want to ask GHC for a list of the names of all the typeclass and instance information currently in scope, and for a description of the constraints for each one.
What are good ways to proceed with this? Where should I be looking?
Thanks.
I'd start by looking at template Haskell for this. The various reify functions let you extract information from the compiler environment. I don't have a proof of concept around for this, but it looks like it should be doable.
Related
Is this the documentation I should use for learning about the various haskell functions: https://www.haskell.org/platform/doc/2013.2.0.0/ghc-api/GHC.html ?
Can search from here or other Haskell doc for how each type should be used? For example if I wanted to learn more about the Int type (without tying :t on command line) can this be searched upon ?
If above is the API it seems much more minimalist that say a Java/Scala API. But perhaps this is one of the strong points of Haskell provide a succinct, yet very powerful set of base functions to build my abstractions upon ?
ghc-api is the API for interacting with the GHC compiler. The "standard library" is documented at http://hackage.haskell.org/package/base.
Can search from here or other Haskell doc for how each type should be
used?
In Haskel you usually think functions first, i.e. you may want to know what functions are available, what input they accept and what output they produce. This is typically expressed by class constraints ("must be a list of something") and sometimes as concrete types.
If you want to find particular functions, then try Hoogle. If you enter Prelude into the search field, you will find module Prelude among the answers. You may see the Prelude as the "Haskell API", i.e. the functions which are always available.
Then there is the base package, which consists of a number of additional modules (as already pointed out by Rein Henrichs), which are also widely used.
Finally there is all the rest, i.e. special purpose modules. Many of the can also be found on Hoogle.
But frankly, I don't think that "learning the API" is a good way to approach Haskell. This may work in Java, where you're dealing with Classes, Object and Methods all the time.
In Haskell you are at a much higher level of abstaction. In Haskell you may find ways to implement Classes, Objects and Methods as one example showcase for a certain abstraction. However, it would not be abvious from reading the API that you can simulate OOP with it.
Hoogle is a Haskell API search engine, which allows you to search many standard Haskell libraries by either function name, or by approximate type signature. The Hoogle manual contains more details, including further details on search queries, how to install Hoogle as a command line application and how to integrate Hoogle with Firefox/Emacs/Vim etc.
Thanks,
http://www.thecheesyanimation.com/3d-home-interior-design.html
Suppose the following:
I have a type called World representing some simulation state. I also have this type synonym:
type Update = World -> World
Is Haskell capable of serializing the Update type such that it can be passed over the network? Or is there any other means of doing so? Maybe I'm not looking for a serialization of the code's logic so much, as some kind of pointer or identifier that can be read on the other end. Both the sending and receiving process are running the same Haskell program.
The distributed-process package is exactly what you described. Since each program already has the same set of functions a pointer to the function is passed from one process to another. There has been mentioned serialization of the function as a potential future goal but is sound like it might take a change to GHC. The github page is a good resource for what backends exist. The github-pages look very nice with some examples, but I did not know about it until a moment ago.
The few Haskell Parallel digests around issue 11 is where I remember learning the most. Definitely take some time to explore github-pages I know I will be.
If I remember correctly there are simple examples in the hackage package or on the github repo exploring work stealing vs work sharing and similar strategies.
I suggest making a DSL data structure. Sadly Haskell does not have lisp's runtime compilation features, but it should be sufficient.
I just started to look into haskelldb as a more powerful companion to persistent, as I need a more powerful tool to query the database. Almost immediately I ran into difficulties with datatypes; in particular, I am using Data.Text quite extensively, UTCTime too and some custom datatypes as well. Unfortunately, although HDBC seems to support these datatypes quite well, haskelldb hides all of this and you have to write your own conversions starting from String input.
I don't want to duplicate the work already done for HDBC; what do you suggest to do in this case?
I think I will probably add an attribute getHdbcValue into the GetInstances class, so that I can write simple GetValue instances that would leverage the HDBC infrastructure; are there any better ideas? Am I missing something obvious?
(BTW: it seems to me that this library is - maybe from historical reasons - a little over-generalized; couldn't it just support hdbc..? )
I really love PostgreSQL and its rich type collection, particularly arrays. Most used of the extra PG types across projects outside Haskell is [int4], typical array of ints. Bringing the support for it to HaskellDB became one of the most exciting challenges I've had on my road to understanding Haskell, especially type-level programming (and TH/QQ too). Adding a new type to support looks kinda easy as long as it is supported by HDBC.
Hope this little patch could show how to add support for a new type. Here's the pull request for that, almost all changes needed covered here(all that is left is FlexibleInstances):
Pull Request
Main Changeset
I have a cabal package that exports a type NBT which might be useful for other developers. I've gone through the trouble of defining an Arbitrary instance for my type, and it would be a shame to not offer it to other developers for testing their code that integrates my work.
However, I want to avoid situations where my instance might get in the way. Perhaps the other developer has a different idea for what the Arbitrary instance should be. Perhaps my package's dependency on a particular version of QuickCheck might interfere with or be unwanted in the dependencies of the client project.
My ideas, in no particular order, are:
Leave the Arbitrary instance next to the definition of the type, and let clients deal with shadowing the instance or overriding the QuickCheck version number.
Make the Arbitrary instance an orphan instance in a separate module within the same package, say Data.NBT.Arbitrary. The dependency on QuickCheck for the overall package remains.
Offer the Arbitrary instance in a totally separate package, so that it can be listed as a separate test dependency for client projects.
Conditionally include both the Arbitrary instance and the QuickCheck dependency in the main package, but only if a flag like -ftest is set.
I've seen combinations of all of these used in other libraries, but haven't found any consensus on which works best. I want to try and get it right before uploading to Hackage.
On the basis of not much specific experience, but a general desire for robustness, the guiding principle for package dependencies should perhaps be
From each according to their ability; to each according to their need.
It's good to keep the dependencies of a package to the minimum needed for its essential functionality. That suggests option 3 or option 4 to me. Of course, it's a pain to chop the package up so much. If options are capable of expressing the conditionality involved, then option 4 sounds like a sensible approach, based on using language effectively to say what you mean.
It would be really good if a consensus emerged about which one switch we need to flick to get the testing kit as well as the basic functionality.
It's also clear that there's room for refinement here. It's amazing that Cabal works as well as it does, but it could allow for more sophisticated notions of "package", perhaps after the manner of the SML module system. Translating dependencies into function types, we basically get to write
simplePackage :: (Dependency1, .., Dependencyn) -> Deliverable
but one could imagine more elaborate combinations of products and functions, like
fancyPackage :: BasicDependency -> (BasicDeliverable, HelpfulExtras -> Gravy)
Until then, pick the option that most accurately reflects the actual deal. And tell us about it, so we can build that consensus.
The problem comes down to: how likely is it that someone using your library will be wanting to run QuickCheck tests using your NBT type?
If it is likely, and the Arbitrary instance is detailed (and thus not likely to change for different people), it would probably be best to ship it with your package, especially if you're going to make sure you keep updating the package (as for using a flag or not, that comes down to a bit of personal preference). If the instance is relatively simple however (and thus more likely that people would want to customise it), then it might be an idea to just provide a sample instance in the documentation.
If the type is primarily internal in nature and not likely to be used by others wanting to run tests, then using a flag to conditionally bring in QuickCheck is probably the best way to go to avoid unnecessary dependencies (i.e. the test suite is there just so you can test the package).
I'm not a fan of having QuickCheck-only packages in general, though it might be useful in some situations.
The closest-related implementation in Haskell I have seen is the forward mode at http://hackage.haskell.org/packages/archive/fad/1.0/doc/html/Numeric-FAD.html.
The closest related related research appears to be reverse mode for another functional language related to Scheme at http://www.bcl.hamilton.ie/~qobi/stalingrad/.
I see reverse mode in Haskell as kind of a holy grail for a lot of tasks, with the hopes that it could use Haskell's nested data parallelism to gain a nice speedup in heavy numerical optimization.
In response to this question, I've uploaded a package named ad to Hackage for handling reverse-mode automatic differentiation in Haskell.
Internally, it leverages a trick from Andy Gill's Kansas Lava to observe sharing in the tape it records for back propagation purposes, and uses type level branding to avoid confusing sensitivities.
I've tried to keep the API relatively close to that of Barak Pearlmutter and Jeffrey Mark Siskind's fad package, but I couldn't resist making a couple of minor tweaks here and there for generality.
I still need to go through and finish up the remaining unimplemented fad combinators, figure out a nice way to build a reverse-mode AD tower, validate that I didn't screw up my recollection of basic calculus, and provide a nice API for using this approach to get local reverse mode checkpoints in an otherwise forward mode AD program, but I am quite happy with how things have progressed thus far.
We have a bunch of forward mode AD implementations (I even have one in my monoids library!), but reverse mode AD for all of Haskell seems to be intractable.
Sadly while Pearlmutter and Siskind give a translation for a lambda calculus, it doesn't map into something you can do for arbitrary Haskell lambdas, you don't get the right introspection properties and given the way the shape of the types change in the translation you don't get something that is amenable to being packed into a monad, arrow, or other control structure.
I had a go at it via a series of email exchanges with Pearlmutter, but ultimately the best I was able to obtain was a reverse mode AD solution for a small EDSL in Haskell, and not a solution for Haskell itself.
Not that I'm aware of. I do know that some Haskell folks are interested in automatic differentiation, but some quick digging found little more than short asides mentioning the reverse mode; I expect you already found the same material I did.
I also note that the fad package and Stalingrad project you found are in fact the work of the same two people, and that at least Prof. Pearlmutter has posted to the haskell-cafe mailing list. You may want to consider contacting him directly about his work--it's possible he has something in progress, or hit serious obstacles while attempting to implement reverse-mode AD.
Sorry I couldn't turn up anything more useful; if someone else wants to dig further, at least the links above are a starting point.
I think forward is the way to go in Haskell. You shouldn't be able to do reverse mode on arbitrary functions, as Edward pointed out. But you responded that you should be able to do it on certain constrained functions. And said constraints can lead readily to forward mode. Eg. if you have a function:
foo :: Num a => a -> a -> a
Then you can instantiate a with a differentiable type, and thus differentiate foo in forward mode.
See the vector-space library on Hackage for very elegant forward mode automatic differentiation. It might not be entirely clear how to use it at first. Read the paper about it, Beautiful Differentiation by Conal Elliott.