From anthony_clayden at clear.net.nz Thu Sep 13 05:32:07 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Thu, 13 Sep 2018 17:32:07 +1200 Subject: [Hugs-users] OpTrex Message-ID: It's always seemed to me that field labels in records are more constructor-like than term-like. And pattern-matching on them is more like using them as (de-)constructors. But H98 records create a selector function named for the field; and because it's a function it must be term-like. TRex field labels don't suffer this restriction: you don't get a selector function; if you want a select by label from a TRex row, use the `#label row` syntax. Then I wondered: TRex labels appear only in a handful of syntax productions. How hard would it be to allow them to look like constructors? The answer is it's dead easy; you need only to change the syntax (in yacc plus a tweak to the lexer); you don't need to change any of the code for building/matching/typing rows. For now, I'm allowing labels to start either upper or lower case. Some example code here https://github.com/ghc-proposals/ghc-proposals/pull/160#issuecomment-420272180 In particular, there's an example defining a Lens `bar` over any Trex row containing a label `Bar`. (The main purpose of that definition is to demonstrate every syntactic construct in which TRex allows labels, so it could be terser.) Note that unlike Lenses over H98 style records, this doesn't need an overloading for each different datatype containing a label of some name. My jazzy name for such Lense is 'OpTRex', as imagined here https://github.com/ghc-proposals/ghc-proposals/pull/158#issuecomment-414060490 AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Fri Sep 28 11:20:27 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Fri, 28 Sep 2018 23:20:27 +1200 Subject: [Hugs-users] Hugging to bits (cont) In-Reply-To: References: Message-ID: On Sat, 28 Jul 2018 at 12:35 PM, Anthony Clayden < anthony_clayden at clear.net.nz> 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 https://ghc.haskell.org/trac/ghc/ticket/15632#comment:2 (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 https://www.haskell.org/hugs/pages/hugsman/exts.html#sect7.1.3 "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony_clayden at clear.net.nz Sun Sep 30 06:17:59 2018 From: anthony_clayden at clear.net.nz (Anthony Clayden) Date: Sun, 30 Sep 2018 19:17:59 +1300 Subject: [Hugs-users] Undocumented featurette: Postfix operators Message-ID: There's an extension to GHC: 'Postfix Operators' . https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/glasgow_exts.html#postfix-operators Turns out Hugs can do that too (in Hugs mode). > (!) :: Num a => a -> a -- note defined as monadic > (!) 0 = 1 -- lhs of equation must use prefix form > (!) n = n * ((n - 1) !) -- but rhs can use postfix So (3 !) returns 6, etc. The parens are needed so that it's parsed as a section. I also took a leaf out of Oleg's book and built a variadic postfix operator http://okmij.org/ftp/Haskell/polyvariadic.html That is, (3 ~- 7) is parsed as 'subtract 3 from 7'. (3 ~-) is parsed as postfix negate 3 aka 'subtract 3 from zero'. It kinda worked, but the terms need a lot of explicit signatures and/or tricky type casting. AntC -------------- next part -------------- An HTML attachment was scrubbed... URL: