On 06/13/2014 07:33 AM, John Meacham wrote:

On Wed, Jun 4, 2014 at 8:23 AM, Mateusz Kowalczyk wrote:

...

You're correct that there's no such feature at the moment. If you want something, please open an issue on [1]. Note that I have never used JHC or looked into how it works so I will need very careful description of what I need to do to replicate it all, including small test case, any flags that need to be passed in for Haddock to work with JHC, expected behaviour, a small case where there are no recursive modules so I can confirm it works in simple case &c. If it turns out to not be too complicated then you could have it in the next non-minor release (2.15.x).

What would be easiest is to just bypass much of Haddocks middle end, as in, I don't want it to attempt to follow dependencies or figure out types or call ghc by itself at all. rather I want to give it a pre-digested pap of resolved names and types (and whatever else it needs) but let haddock still parse the file and generate the documention with its back end.

GHC does the parsing of stuff for us, as well as module loading, package finding, name resolution, renaming, …. What we do parse is the things that GHC tells us are Haddock comments (the stuff you actually write). What you'd need to produce for us to use XHtml backend is [Interface] where Interface is defined in Haddock.Types. Notably, this involves LHsDecl which is a GHC type which the back-end inspects and decides what to do with. What's more, we use some pretty printing functions from GHC to actually render the stuff. Basically, GHC does the bulk of work and we massage whatever we get back into a friendlier format for humans to read. If you don't want to involve GHC at all then it's not feasible to use Haddock. There *are* plans to splice out the parts that don't need GHC to a separate package (currently unimaginatively called haddock-library) and I have already done so with the comment parser (so you can turn String into Haddock doc type) but there are no plans to just not use GHC all together, it is too much work. We are planning to make writing new back-ends easier but the GHC dependency will not go away. So the short version is, there is no GHC middle-end, it is GHC from the beginning to the end. One way to work around this would be to pre-process what we get out of GHC into Haddock types that no longer refer to the GHC data types that we can expose and back-ends can work with but this is rather a lot of work. It seems like a correct thing to do but I don't think the amount of effort justifies it, at least for me. We just don't have the manpower for this: we're *very* understaffed for such a core project. If you know people who would like to work towards such goal though, I'd love to hear about it.

This would be more generally useful as a haddock feature than trying to have it emulate other compilers as any compiler or tool can output this general metainfo format.

John

-- Mateusz K.

On Thu, Jun 5, 2014 at 2:20 AM, AntC wrote:

(I agree with you [John] in not seeing a great deal of similarity to the OverloadedRecordFields work. My earlier suggestion of not creating Selector functions is exactly to free up the namespace. That suggestion is part of (and largely orthogonal to) an alternative records proposal which also relies heavily on the type system.)

A simple backwards compatible extension would be to just not report an error when there are multiple definitions of the same name when they are all generated selectors. Then let name resolution happen like normal, just reporting an ambiguous name if one is attempted to be used as a selector the same way an ambiguous name is reported when there are multiple definitions in scope for anything. This would just require dropping the unique top level check. This would be useful as the behavior will degrade to the current behavior if no field names happen to overlap. John -- John Meacham - http://notanumber.net/

On Sun, Jun 15, 2014 at 10:10 PM, wrote:

The implementation of unboxed types and defined kinds in JHC appears to be incompatible with GHC (`Int_` instead of `Int#`, `data kind` instead of just `data` and promote every suitable type). Please fix this.

They are different because they are somewhat different things. GHC and jhc have very different intermediate and back end languages, ghc's is based on system F with a backend distantly descended from the G machine and jhc has an intermediate language based on a PTS similar to the lambda-cube* and a backend descended from boquit's GRIN intermediate language and these decisions constrain the semantics of unboxed values for both compilers. Likewise, the type systems are different in some ways, for instance jhc supports polymorphism of unboxed types so there is no need for 1# and 1## being different types. It has a different kind hierarchy because in the back end 'evaluation' and 'case matching' are independent operations which in ghc they are intertwined, so you can directly branch on a value if you know it is already evaluated which is a particularly advantagous. jhc unboxed constructors are normal so no special Hash syntax is needed to denote them. Since jhc has no run-time it's unboxed values need to be at a lower level than GHC's to take advantage of optimizations based on that. For instance, ghc has independent types for unboxed Int's and Word's, however, as far as a CPU is concerned there are only values of a certain bit width and no signendedness information is on the type. Jhc follows CPU operations. It just happens that the instance Num Word in jhc uses unsigned primitives and the instance Num Int uses signed ones but they both are boxed 'Bits32_' underneath. The kind extensions were independently developed hence the different syntax, I am not a fan of eating syntax or filling the data tables with most likely unused kinds automatically... but I may change my mind on that in the future, User defined kinds are still fairly new so I want to see more how they are used in practice for a while, In any case, PolyKinds are next up in the kind system for implementation. *My IL is very similar to and was inspired by Henk actually (http://www.staff.science.uu.nl/~jeuri101/MSc/jwroorda/) -- John Meacham - http://notanumber.net/