- Hugs-Users - Haskell.org

Pattern Signatures: what can scoped type variables refer to?
by Anthony Clayden 06 Dec '18

06 Dec '18

HugsMode supports signatures in patterns, roughly equivalent to the (now deprecated) `PatternSignatures` GHC extension. Hugs doesn't support GHC's full `ScopedTypeVariables` functionality with the daft/bogus `forall` quantification on stand-alone signatures -- which IMO is a wart. I'm reading the 2018 paper 'Type variables in patterns' Eisenberg/Breitner/Peyton Jones, section 3.1, 3.5 "a scoped type variable may refer only to another type variable". Hugs applies the same rule. I'm persuaded by section 3.5's saying that seems an arbitrary and unnecessary restriction. "We therefore propose to simply drop this restriction." This is github PR #128 in GHC. Done in Hugs: I've just suppressed the error message, is in one validation routine in one module. So this example compiles > prefix :: Int -> [[Int]] -> [[Int]] > prefix (x :: b) yss = map xcons yss -- previously :: b was rejected > where xcons ys = x : ys :: [b] -- now can use b to annotate the rhs It seems to me that inline tyvar bindings/annotations like this is preferable to the `ScopedTypeVariables` explicit `foralls` on a standalone signature signalling some tyvar is being scoped over some declaration/term. See also similar comments in github PR #119 'Resurrect PatternSignatures' (now withdrawn). There were quite a few opinions to the effect that `PatternSignatures` (but not full bore `ScopedTypeVariables`) should always have been part of Haskell; and perhaps that'd be ripe for inclusion in Haskell 2010. AntC

1 0

Trex label names: leaky abstraction
by Anthony Clayden 09 Nov '18

09 Nov '18

Gaster & Jones 1996 says "We consider two rows to be equivalent if they include the same fields regardless of the order in which they are listed." [section 3.2] But this is tricky: Figure 6 shows there is an ordering on labels, so that in effect records are compiled to tuples with left-to-right ordering of label names alphabetically. The User Manual says "The order of fields in a record pattern *is* significant because it determines the order---from left to right---in which they are matched." In particular, a pattern match on a record with a field value `undefined` might succeed if some other field label is mentioned first in the pattern; but throw an error if it's the undefined field's label mentioned first. It's not difficult to expose this behaviour. Consider > import Hugs.Trex > > x5y = (x = 5, y = 'y'); x7y = (x = 7, y = undefined) > z5y = (z = 5, y = 'y'); z7y = (z = 7, y = undefined) > > x5y == x7y -- returns False > z5y == z7y -- throws error Prelude.undefined The tuples with label `z` are compiled to put that field second, regardless of the order of appearing in the expression. Then (==) applies by comparing field values in left-to-right alphabetic ordering. Field `x` is alphabetically before `y`; and the `x` values differ; so the comparison returns False without comparing the `y` values. Then in comparing the field `z` records, the `y` fields are compared first (ignoring that the `z` values differ), exposing that one `y` field is `undefined`. This is similar to comparing tuples > (5, 'y') == (7, undefined) -- returns False > ('y', 5) == (undefined, 7) -- throws error There seems to be some infelicity when building records: > f ... rho ... = (y = 'y' | rho) This throws strange errors depending whether `rho` includes labels that are alphabetically before `y`. Bug report incoming ... AntC

1 0

[haskell-beginners] Lifting over record syntax
by Anthony Clayden 04 Nov '18

04 Nov '18

musing on this https://mail.haskell.org/pipermail/beginners/2018-October/018363.html to which my reply talked mainly about Trex. Does it make sense to regard a Trex record (or any free-standing anonymous/extensible record) as a container, with values 'lifted' into the structure, and an interface given by the label names, _not_ by order of fields? That is, "container" in the Monad sense? Does it further make sense if all the values are already lifted into some Functor (like Maybe or (Either e) ) to hoist the Functor out over the record structure? I'm not sure I'm up with the program for Functor/Applicative/Monad everywhere. If a record structure is a Functor, what's the type constructor? `Rec`? If record structure is an Applicative, what's the constructor for `pure` that lifts into `Rec`? The `<*>` aka `ap` or bind for a Monad presumably is to take two records (with disjoint labels) and concatenate them to a single record. Given data Person = Person (Rec( name :: String, age :: Int)) we want, corresponding to the question: Person <?$> (age = 27) <*> (name = "Joe") in which operator <?$> is map-like: it takes a function to its left that expects a record of n fields, then maps over n singleton records with corresponding labels appearing in any order. I might be able to get there by generics/reflection over the field names embedded in data constructor `Person`s type, then overloading <?$> to look for each label. That is, if Hugs had any sort of generics/TypeRep. Label names in Trex are literals; there's no such thing as a label variable. (Which is why it's a tad annoying that they start lower case.) Furthermore the same label name must appear in both terms and types -- in fact labels occupy a namespace separate vs terms or types. So Trex is a long way from from generic record handling like: recAppend :: ( rho'\__x ) => Rec rho' -> Rec ( __x :: a) -> Rec ( __x :: a | rho') recAppend rho ( __x = x ) = ( __x = x | rho ) in which I've used double-underscore prefix to signify a label variable. This is intended to extend a record `rho` with a singleton record. If we try appending a record with more than one field, beware that field order is arbitrary, so this recAppend rho ( __x = x, __y = y) = ... has no principal type (a familiar difficulty). The programmer doesn't care which way round labels `__x, __y` bind, providing they're distinct, but the typing does care. Some sort of generic record extend/concatenate would be great. You might, looking at Trex syntax, think that `|` is it. This is valid: ( x = "x" | (y = 'y' | (z = 3.14))) ( x = "x", y = 'y', z = 3.14 ) -- equivalent I could put any record value in place of `(z = 3.14)`. But not in place of the `x = ..` or `y = ...`: `|` is not an operator, not commutative, not associative. Furthermore this is a place where parentheses make a difference, unlike usually in Haskell. So the following are not equivalent, indeed they're all invalid syntax ( (x = "x") | (y = 'y' | (z = 3.14))) -- x = ... has parens ( x = "x" | (y = 'y' | z = 3.14 )) -- z = ... doesn't have parens ( x = "x" | y = 'y' | (z = 3.14) ) -- z = ... in parens OK, but y = ... is not ( (x = "x") | (y = 'y') | (z = 3.14) ) -- no chance I'd like to write term `( rho1 | rho2 )` to concatenate two records. That's currently unrecognised syntax, so I think could be added as such. What would be its type/is it principal? ( rho1 | rho2 ) :: (rho1' \\ rho2') => Rec( rho1' | rho2' ) -- inventing more syntax in which constraint `(rho1' \\ rho2')` requires the two rows' labels be mutually disjoint -- read "lacks all". Ur/web has something like this. Note I'm not envisaging `|` as a genuine operator: this is still hard-wired syntax; pipe is a reserved symbol in H98 anyway. AntC

1 1

TypeCastery
by Anthony Clayden 09 Oct '18

09 Oct '18

A typical consequence of combining FunDeps + Overlapping instances is that you have to make the result parameter more general than it needs be, then use a TypeCast constraint to improve it. There's a classic example in the HList paper [*], Section 9 'A generic type equality predicate'. > class TypeEq x y b | x y -> b > > instance TypeEq x x HTrue -- HTrue, HFalse are just two datatypes > > instance (TypeCast HFalse b) > => TypeEq x y b -- can't put TypeEq x y HFalse (And really all of the tricky type improvement in that paper boils down to that technique, whether or not there's an explicit TypeEq test.) The paper says the TypeEq solution is GHC-specific. That's true but .... I wonder if they discussed their results with the Hugs team at the time, because it's not needed drastic surgery to make Hugs do that. (Perhaps I broke something, but if so it's going to take a convoluted example to find it. I've built a routine that merges TRex records by matching label names, with horrendous amounts of overlap and typecasting.) The technique relies on TypeCast, which does use FunDeps to mutually improve/unify its two parameters. Nowadays in GHC you'd use the (~) constraint. TypeCast does use a complicated chain of "indirection" superconstraints on instances, but does not use overlaps -- indeed there's only a single instance for each of the classes involved. I'd been happily using the version of TypeCast given in Appendix D 'Generic type unification cont'd'. Then I re-read the paper, which claimed it didn't work in Hugs [Section 9 'Reification of type unification']: "The most generic implementation of TypeCast, which works for both Hugs and GHC, is ... For this implementation to work, we need ... Otherwise, type simplification will ... and thereby inline the unification." IOW unification will be too 'eager'/too smart and see that we're trying to evade the FunDep consistency rule. "Alas, this implementation [Appendix D alternative] is specific to GHC; it does not work in Hugs because of the peculiarities of that system with regard to MPTCs and functional dependencies, ..." I'm experiencing that the Section 9 implementation claimed to work in Hugs, doesn't; and the Appendix D implementation claimed to not work in Hugs, does. That's using the legitimate distro version of Hugs Sep2006. Possibly Hugs changed after 2004 when the HList work was reported. (In Section 6 of the paper "We give up on persuading Hugs." so I guess they didn't explore further.) That is, the Section 9 implementation exhibits the 'eager' type unification, whether or not I declare TypeCast in a separate module and "import it at a higher level in the module hierarchy" [Section 9]. That is, if I'm doing that right: what does "separate compilation" mean in context of Hugs? It's an interpreter not a compiler; it doesn't produce executables/object code. Indeed if you import a library -- even one of the standard Report-defined libraries, it goes and gets the library source and compiles that alongside the client program. There's no Haskell interface/.hi files that I can see(?) Oh, and there's another advantage to avoiding separate compilation: Hugs can see all the instances and their constraints (and instances of the constraint classes) across all the modules. So no 'orphan instances' -- the problems with which were amongst the reasons for Section 6 'Overlapping banned'. "we do not want to depend on the doubtful future of overlapping instances in general ... GHC's instance selection is lazy, whereas Hugs' is eager". This leads the paper on to "what's known as the Data.Typeable approach at the type level". But the cure is worse than the disease! It's just not scalable and not workable. So the version of HList that has persisted to this day does use the combo of Fundeps + Overlaps, and despite the paper's misgivings, that has persistently been stable in GHC. No "doubtful future" after a dozen years. To pick up a misrepresentation: "GHC's instance selection is lazy": no, GHC's validation of overlapping instances is lazy; but its selection is eager, too eager: it commits to an instance inside each module, ignoring the possibility this module is imported into another with an overlapping module which is a better fit. Whereas the alleged "Hugs' is eager" is also opposite to the truth: Hugs' selection of an instance is delayed as much as possible until it's sure there's only one fit (it can see all instances in all imports). Validation of overlap is eager: instances (heads) must be in strict substitution sequence. That's often a nuisance, but a price I'm prepared to pay to get better coherence. 'Orphan instances' (and overlap thereof) are certainly a danger in GHC. Avoiding them was part of the motivation for Closed Type Families to be grouped in a single syntactic unit/in a single module. And yet GHC knows how to defer instance selection if there's no unique/suitable instance visible in a module. Why can't it do that everywhere? Or at least warn if imports contain instances that are overlapped in a different module. Then it seems to me: * not only does GHC have a "bogus" implementation of the FunDep consistency rule; but also * GHC's implementation of Overlaps is broken. Hugs' implementation of both is a lot more restrictive, and more coherent. I'm not finding it prevents any programs. It does require I structure them in specific ways. AntC [*] Strongly Typed Heterogeneous Collections 2004, Oleg Kiselyov, Ralf Lämmel, Keean Schupke

1 1

Re: [Hugs-users] Hugs-Users Digest, Vol 41, Issue 1
by Doug McIlroy 03 Oct '18

03 Oct '18

Sorry for whatever I just posted. It was a slip of the fingers in responding to a completely unrelated email Doug

2 1

Re: [Hugs-users] Hugs-Users Digest, Vol 41, Issue 1
by Doug McIlroy 03 Oct '18

03 Oct '18

!e dead*

1 0

Undocumented featurette: Postfix operators
by Anthony Clayden 30 Sep '18

30 Sep '18

There's an extension to GHC: 'Postfix Operators' . https://downloads.haskell.org/~ghc/8.6.1/docs/html/users_guide/glasgow_exts… 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

1 0

Hugging to bits
by Anthony Clayden 28 Sep '18

28 Sep '18

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 https://github.com/AntC2/ghc-proposals/blob/instance-apartness-guards/propo… 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

1 1

OpTrex
by Anthony Clayden 13 Sep '18

13 Sep '18

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-420272… 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-414060… AntC

1 0

Re: [Hugs-users] needing some Hugs
by Doug McIlroy 07 Jul '18

07 Jul '18

I have little constructive to say on the topic, except that I typically use hugs in preference to "monstrous" ghc/ghci. It's lightweight and its language is properly documented (in the Haskell 98 report), neither of which can be said of ghc. Its rudimentary instrumentation (:set +s) is more useful than ghc's equivalent, though admittedly ghc has many debugging features I haven't explored. That said, it should be noted that I do not use Haskell (nor, nowadays, any other language) for writing production code. Apropos of language, a couple of years ago I noted that ghc implements 2^99 languages, not one. (There were 99 non-antonymous language pragmas; there may be more now.) Who can know what terrors lurk there. My first attempt to investigate the field (turn on all 99) caused a compiler panic, since fixed. Early on, I encountered a hugs bug: garbage collection in the middle of a bignum operation caused havoc. Having never looked at the hugs source before, I was able quite quickly pinpoint the offending code; the maintainers corrected it almost overnight. That heart-warming experience hasn't worn off, even though the maintainers have moved on. Doug

3 2