Hugging to bits

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Hugging to bits

AntC
Thank you for the encouraging words to my previous thread. I can report Hugs is indeed easy to hack.

Getting to build from source was only mildly painful. (Mostly due to my total ignorance of Unix.)

After being so used to Functional thinking, it is a wrench going back to programming in procedural code (C/C++) with side-effects and global variables. But I'm only tweaking the logic, not building anything from the ground up. (I've not before programmed in earnest in C, but it seems close enough to BCPL from my varsity days.)

Chiefly, as I suspected, Hugs has a very firm foundation to start from. There's a deal of static type/class/instance analysis built up from the program text, which means I can easily detect the conditions under which I want to relax some of Hugs well-principled rules. (I'm implementing well-principled but more subtle rules.)

So I have a modified version of the FD consistency rules, that supports expressing a type-level type equality test, but avoids the bogusness in GHC Trac #10675. With the equality test I can now express all the examples in the HList paper [2004] -- those guys abandoned Hugs.

I have a better version of the instance overlap rules, determined statically from examining instance heads. IMO GHC's deferred checking is far too shonky: you think your instances are OK then many moons later you (or more likely somebody using your library) gets puzzling rejections to do with overlaps.

A quick q in case anybody's listening: Hugs used to have something called 'Multi-instance' overlap resolution. There's references to it in the code and older documentation. But it's broken and was withdrawn. Anybody know what it was trying to do or where I can find docos? It seems it was trying to defer checking much like GHC, in which case I won't pursue it.

I'm now working through an approach for my 'Instance Apartness Guards' proposal

I can express all the examples there, including the very awkward Andy A-M one (using classes/instances with FunDeps rather than type families). But it needs inserting extra instances and lots of instance constraints for type improvement.

So my next hack is to change the rules for overlap resolution where there's also FunDep(s). Again this can all be done at static analysis time: Hugs determines the sequence to try instances as it processes/validates each instance.

It is a joy to work in a version of Haskell that has what I want; and not a load of cruft I don't want, but which causes continual obfuscation. Thank you again to the Hugs team.

AntC

_______________________________________________
Hugs-Users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/hugs-users
Reply | Threaded
Open this post in threaded view
|

Re: Hugging to bits (cont)

AntC


On Sat, 28 Jul 2018 at 12:35 PM, Anthony Clayden <[hidden email]> wrote:
...
So I have a modified version of the FD consistency rules, that supports expressing a type-level type equality test, but avoids the bogusness in GHC Trac #10675. With the equality test I can now express all the examples in the HList paper [2004] -- those guys abandoned Hugs.

I have a better version of the instance overlap rules, determined statically from examining instance heads. IMO GHC's deferred checking is far too shonky: you think your instances are OK then many moons later you (or more likely somebody using your library) gets puzzling rejections to do with overlaps.

Specifically, I've implemented the suggestion here 

(Suggested/implemented after experimenting with some exotic variations; also after ditching the FunDep consistency rule altogether, as an experiment -- which behaved sensibly if you kept your instances sensible, but triggered some truly weird stuff too.)

It seems to be going OK with 'ordinary code'. But overlapping TRex instances with FunDeps are giving indigestion. The trouble seems to be that internally TRex uses polykinds (row variables are Kind row, not `*`; labels seem to be something else again). I'm not sure whether type improvement through FunDeps is able to poke inside row Kinds.



A quick q in case anybody's listening: Hugs used to have something called 'Multi-instance' overlap resolution. There's references to it in the code and older documentation. But it's broken and was withdrawn. Anybody know what it was trying to do or where I can find docos? It seems it was trying to defer checking much like GHC, in which case I won't pursue it.

Some detail in an old version of the Higs manual, section 7.1.3 Overlapping instances, option +m 

"a lazier form of overlapping instances", but no it's not GHC's deferred checking: it's looking at constraints to see if it can disambiguate instance selection by finding an instance for which constraints hold/reject instances whose head matches the wanted but whose constraints don't hold. There's an example. Wow! sounds hairy, although that behaviour is what newbies always think they're getting with constraints. Makes instance selection undecidable, in general. I'm not surprised it's broken, and I'm certainly not going to wade into that swamp.

Note Hugs works hard at instance-processing/validation time (i.e. before it considers wanteds) to join up instances to constraints to instances of the constraint class. It builds a data structure around each instance decl, so the info is at its fingertips for doing "multi-instance resolution".

AntC

_______________________________________________
Hugs-Users mailing list
[hidden email]
http://mail.haskell.org/cgi-bin/mailman/listinfo/hugs-users