- Hugs-Users - Haskell.org

Type Equality `~` constraint implemented for Hugs
by anthony.d.clayden＠gmail.com 15 Sep '26

15 Sep '26

To be precise, I've implemented both a dyadic `~` constraint; and the idea from M.P. Jones & Diatchki 2008, end of §3.3 http://web.cecs.pdx.edu/~mpj/pubs/fundeps-design.html > > f1 :: Bool ~ b => b -> Bool -- dyadic > f2 :: C Int ~ b => b -> Bool -- Class C > > class C a b | a -> b > > class (~) a b | a -> b, b -> a > instance (~) b b > This is not introducing type operators nor class-as-operator in general. The `~` is hard-coded syntax. A constraint `C Int ~ b =>` desugars to plain `C Int b =>` so the syntax is to help the reader. (There's no check whether `C` has a FunDep, nor whether the second param is the dependent.) This does make the syntax ambiguous; the implementation is ugly: dyadic `Maybe Int ~ b =>` is not distinct from a class constraint; the resolution is to look up the LHS's head in known class names. Note the semantics for dyadic `~` is not as convoluted as `TypeCast` from the HList paper [Kiselyov et al 2003, Appendix D] This has needed solving a long-standing limitation with FunDeps https://gitlab.haskell.org/ghc/ghc/-/work_items/9627#note_697088 Upon meeting the equation for `f1, f2` instantiate skolems from the given signatures, as usual; then immediately `improve( )` the type from any classes/their FunDeps _as appear in the given signature_, and only from there. In Hugs terms this is improving the 'Expected type'. (The Trac Issues uses ghc terminology 'Rigid tyvar'.) This improvement also applies for instance decls: if the class has a super-constraint with a FunDep; or the method has a constraint with a FunDep; improve that upon substituting the type(s) from the instance head. Thus can support a constrained Functor/Monad/etc: > > class Funkytor tb where > funkyMap :: t b ~ tb => (a -> b) -> t a -> t b > > instance Ord b => Funkytor (Data.Set.Set b) where > funkyMap f xs = Data.Set.fromList $ fmap f (Data.Set.toList xs) > `Funkytor` like that can't be defined using `TypeCast`: the `t b ~ tb` isn't applied eagerly enough. AntC

1 0

Field names starting Upper [Was: [haskell-cafe/ghc-proposals] Allow reserved identifiers as fields ...
by Anthony Clayden 30 Dec '24

30 Dec '24

I said ( https://mail.haskell.org/pipermail/haskell-cafe/2024-December/136986.html) On Wed, 25 Dec 2024 at 16:49, Anthony Clayden <anthony.d.clayden(a)gmail.com> wrote: > ... > > [**] I'm particularly keen on field names starting upper case, because > they're injective/part of the structure, like data constructors. > > > And previously with Hugs ( https://mail.haskell.org/pipermail/hugs-users/2020-May/000927.html) > * I've taught Trex to support field labels starting upper-case, because, > well for me they're more like constructors than variables. > > So can I combine that work? Yes, providing I use Upper-case labels only within `{ ... }`. These can combine lower with Upper field names within the same data type; can pun on the lower. > > data Upup a = MkUp{ down :: a, Up :: Int } deriving (Eq, Show) > > anUp = MkUp{ down = 'a', Up = 5 } -- build > recUp = anUp{ Up = 7 } -- field update by Up label, record syntax > > succUp (MkUp {down, Up = u} ) = MkUp{ down = succ down, Up = succ u } > You can't use a field selection function: 'ERROR - "Up" is not a data constructor'. (It looks like Hugs does generate such a function; this error is a syntax rejection in trying to use it.)

1 0

[ANN] - Hugs for MacOS (x86) - via Nix Flakes
by Justin Bailey 23 Oct '22

23 Oct '22

I spent some time with the last public release of the Hugs sources, making them compile on a modern Mac (x86 chipset). I used Nix's flakes feature to manage the build and install. If you'd like to run the hugs interpreter directly using the flake, just type: `nix run github:m4dc4p/hugs#hugs` If you'd like to execute a Haskell file, try: `nix run github:m4dc4p/hugs <file.hs>` Or alternately: `nix run github:m4dc4p/hugs#runhugs <file.hs>` (That is, `runhugs` is the default app provided by the flake.) See the README at https://github.com/m4dc4p/hugs for more details (including other binaries available). I don't have much of a use case for Hugs, so I got the flake to the point where I could start the interpreter and run simple programs. I'm glad to accept pull requests or bug reports. You can find the source and submit any issues at https://github.com/m4dc4p/hugs. Note: I don't have access to Apple silicon, so this build has only been tested under x86. If it works for M1 please let me know, or if you are able to submit a PR I'd welcome it! Enjoy! Justin

2 2

Hugs/Trex and Overlapping Instances and FunDeps
by Anthony Clayden 27 Sep '22

27 Sep '22

I decided this could usefully be a feature, rather than a bug: https://mail.haskell.org/pipermail/hugs-bugs/2022-September/001929.html So I meshed it with work-in-progress on overlaps; and on allowing instances inconsistent with FunDeps providing an overlap is strictly more specific; and in looking to FunDep's determining positions only for detecting overlap. So this now is accepted (`trexRemv` returns its first argument, removing any fields whose labels are common with its second arg): > > import Hugs.Trex > > class TrexRemv r1 r2 rr | r1 r2 -> rr where > trexRemv :: Rec r1 -> Rec r2 -> Rec rr > > instance TrexRemv EmptyRow r2 EmptyRow where > trexRemv _empty _r2 = emptyRec > > instance (r1'\x, r2'\x, TrexRemv r1' ( x :: _b | r2') rr', rr'\x ) > => TrexRemv ( x :: a | r1') ( x :: _b | r2') rr' > where > trexRemv ( x = x | r1') r2 = trexRemv r1' r2 > > instance (r1'\x, r2\x, TrexRemv r1' r2 rr', rr'\x ) > => TrexRemv ( x :: a | r1') r2 ( x :: a | rr' ) > where > trexRemv ( x = x | r1') r2 = ( x = x | trexRemv r1' r2 ) > > instance (r1'\y, r2'\y, TrexRemv r1' ( y :: _b | r2') rr', rr'\y ) > => TrexRemv ( y :: a | r1') ( y :: _b | r2') rr' > where > trexRemv ( y = y | r1') r2 = trexRemv r1' r2 > > instance (r1'\y, r2\y, TrexRemv r1' r2 rr', rr'\y ) > => TrexRemv ( y :: a | r1') r2 ( y :: a | rr' ) > where > trexRemv ( y = y | r1') r2 = ( y = y | trexRemv r1' r2 ) > For each specific label, the instance heads overall are in no substitution ordering -- because the label appears in the result just in case it _doesn't_ appear in the second arg. The new rule is to consider only the argument (first two) positions. For each distinct label, the heads unify: the common instance has both labels. The new rule is that if heads differ in having distinct labels in corresponding positions, treat them as apart. (Or equivalently treat them as overlapping in strict alphabetic order of labels. So you can write instances in any sequence; they'll get loaded to alpha seq.) As I said in that maybe-bug report >> >> it's Trex where records are considered isomorphic up to permutation of labels; >> and because each instance has an `EqRecRow b` constraint for the rest of the row; >> it doesn't matter how Hugs resolves the wanted to the instances >> [s/EqRecRow/TrexRemv/] Similar to `remv` there's classes for `proj`(ect) and `app`(end) of rows with distinct labels, needing these overlap rules. So along with the Trex syntax for rows, I now have an expressively complete set of operations. Nice-to-have would be generating these instances on-the-fly -- as Hugs does for `Eq, Show`. That looks hard. AntC

1 0

Re: [Hugs-users] FunDeps: divergent improvement from overlapping instances
by Anthony Clayden 22 Aug '22

22 Aug '22

> I'm now working on the instance sequencing routines, to ignore those > divergent Dependent positions when deciding overlap ordering. Ok. Done. So this works: >* class TypeEq a b e | a b -> e *>* instance TypeEq a a TTrue *>* instance TypeEq a b TFalse* In case of multiple FunDeps for an instance, improvement must use all FunDeps for a given instance, but not go on to improve from a less specific instance -- if one of the FunDeps is Full. Note a Full FunDep needn't actually deliver any improvement (change of types) for this 'don't go on' to apply -- it's sufficient if some other improvement has already got the Wanted to match the instance. (In effect this is selecting the instance -- although Hugs doesn't 'officially' do so until a later step.) Getting the preference sequence of instances was tricky -- especially in case of multiple FunDeps: in comparing two instance heads, they might be apart going by some FunDeps, but overlapping going by others.

1 0

FunDeps: divergent improvement from overlapping instances
by Anthony Clayden 12 Aug '22

12 Aug '22

The HList project (~2004) had to abandon Hugs because (for example) they couldn't express a type-level type equality test. Hugs rejects any attempt 'Instances are not consistent with Functional Dependencies'. Here's the equivalent that works in GHC. > class TypeEq a b e | a b -> e > instance TypeEq a a TTrue > instance {#- OVERLAPPABLE -#} (e ~ TFalse) => TypeEq a b e Hugs rejects the equivalent of these instances because it can unify the instance heads' determining positions (as TypeEq a a e0) but the improvement diverges. Hugs always treats a wildcard e0 as apart from any specific type or from any other wildcard; whereas GHC treats them as unifiable, so accepts the instances. The instances (whole heads) are overlappable, so GHC's overlapping instances mechanism will improve e ~ TFalse only on condition it can't unify types a, b at some usage site. SPJ points out https://gitlab.haskell.org/ghc/ghc/-/wikis/Functional-dependencies-in-GHC/K… that using an instance head to improve under a FunDep is a separate step and proceeds first vs selecting an instance. So this form for the second instance won't work in GHC: > instance TypeEq a b TFalse (Also the instance heads are not overlapping.) In case of TypeEq a a e0, instance improvement will find both instances match and improve e0 ~ TTrue, e0 ~ TFalse, then reject as inconsistent, same as Hugs. But notice this FunDep is 'Full' -- that is, mentions all of the classes, parameters. ('Full' FunDep is introduced in the 2008 'via CHRs' paper.) If improvement can use a Full FunDep matching to an instance head, it has in effect selected that instance. This is really using the instance as a _candidate_ for improvement -- it might be the Dependent types are already improved as far as possible before looking at this instance. (That is, if we already have [W] TypeEq Int Int TTrue, looking to the instance heads won't improve further; but Hugs is not smart enough to shortcut that TTrue can't be improved.) Hugs' type routines at this step of compilation are very much focussed on improving types, not selecting instances. And in case of a class with multiple FunDeps, the routines should 'fire' all possible FunDeps for each instance. However it's only a small mod in routine instImprove to say: upon matching to a Full FunDep for an instance, stop looking at other instances for improvement. A precondition is that it scans instances in most-specific-first sequence -- which Hugs is already doing. So I can write these instances > class TypeEq a b e | a b -> e > instance TypeEq a a TTrue > instance TypeEq a b TFalse Without needing to clutter the instances by deferring improvement to constraints. (This also makes type inference error messages less cluttered.) I'm now working on the instance sequencing routines, to ignore those divergent Dependent positions when deciding overlap ordering. AntC

1 1

Datatype contexts considered not so harmful
by Anthony Clayden 28 Jul '22

28 Jul '22

There's a discussion in May 1999 pointing out the H98 Report is "inexplicit" wrt the semantics of pattern matching on datatypes with a context. http://web.archive.org/web/20151208175102/http://code.haskell.org/~dons/has…, 'Contexts on datatype declarations', starting at SPJ's opener. The Report has this example, section 4.2.1: > data Eq a => Set a = NilSet | ConsSet a (Set a) -- with inferred types > -- NilSet :: forall a. Set a > -- ConsSet :: forall a. Eq a => a -> Set a -> a (If, per Wadler's response, he thinks "a type will make no sense without the constraints", what sense is there in having a `NilSet` without constraints?) Ref the q SPJ poses, it's _not_ the case that a selector function always gets the constraint inferred. (As of Hugs 2006 and GHC 8.10.) If a selector function pattern matches on `ConsSet`, `Eq a =>` is indeed inferred. But if matching on only `NilSet`, or only on a bare var/wildcard pattern, no constraint. (In practice of course you would be matching on `ConsSet`, so this point is purely academic.) Anyhoo, this behaviour doesn't deliver Wadler's objective. And I find it weird you have to look at the term level to explain the type. Since `data Eq a => ...` prefixes the type and constructors, I'd expect the behaviour to apply at _type_ level. If I bend Hugs to behave same as-was GHC (no constraint inferred if purely matching), I get the benefit I can declare instances for constructor classes (including Foldable) over type constructor `Set`. Whereas the post-May 199 behaviour disallows this: pattern matching in the method decls wants an `Eq a =>`, but there's no means to pass in a dictionary. I can't declare a Functor instance, because building the result applies the data constructors, so does want a dictionary; again there's no means to pass one in. I can simulate `fmap` via Foldable's `foldMap`, because that wants a Monoid instance for the builder, and that does see the element type as well as the constructor. (The builder can squish out resulting duplicates, so preserving the invariant of `Set`.) Not being able to declare `Set` an instance of Functor is a Good Thing. Nor of Monad https://mail.haskell.org/pipermail/haskell-cafe/2004-March/005995.html As SPJ points out later in the 1999 thread > But when you take a constructor *apart*, the invariant must hold > by construction: you couldn't have built the thing you are taking > apart unless invariant held. So enforcing the invariant again is > redundant; and in addition it pollutes the type of selectors. (I note GHC's Pattern Synonyms seem to have fallen into the same hephalump trap of polluting constraints for matching with constraints needed only for building.) If you're thinking "but hasn't GHC solved all this with GADTs?" I say no: their sweet spot is where there's different constraints down the structure; you can't help but hold a different dictionary at each node and 'Provide' it on pattern matching. Whereas for `Set` it's crucial you have exactly the same constraint 'all the way down', and all nodes type `Set a`. I can (just about) see use cases for datatypes that both have global contexts and GADT constructors. AntC

1 1

NamedFieldPuns in HugsMode
by Anthony Clayden 17 May '22

17 May '22

There's an (AFAICT) undocumented feature in Hugs, which behaves the same as GHC -XNamedFieldPuns > data Thing a = MkThing {field :: a} > foo MkThing{ field } = field > -- ^^^^ shorthand for { field = field } AntC

1 0

Re: [Hugs-users] [Haskell-cafe] Prolog-style list syntax?
by Anthony Clayden 07 Jul '21

07 Jul '21

Ok so I implemented both ideas: > elem2 _ [] = False > elem2 x [y,: ys] = x == y || elem2 x ys > let [x,y,z,w,: ws] = "hello there" in ws -- yields "o there" In fact it was easier to implement both ideas than make a special case of `(:)`. So these work > let [x,:+ xs] = [1,2,3,:+ Nily] in xs > let [x,`ConsSet` xs] = [1,2,3,`ConsSet` NilSet] in xs with decls > infixr 5 :+ > data Listy a = Nily | a :+ (Listy a) deriving (Eq, Show, Read) > infixr 5 `ConsSet` > data Set a = NilSet | ConsSet a (Set a) deriving (Eq, Show, Read) On Wed, 30 Jun 2021 at 19:00, Anthony Clayden <anthony.d.clayden(a)gmail.com> wrote: > Ok thank you for the feedback, I get the message not to re-purpose > currently valid syntax. > > > > [x, y ,: ys ] -- ? not currently valid > > We could make list syntax work harder > > > [x, y ,:+ ys ] > > Means desugar the commas by applying constructor `:+` instead of `:`. That > could be in general any constructor starting `:`. > > Or indeed could be a pattern synonym starting `:`, which is a 'smart > constructor' to build the list maintaining some invariant. > > >

1 0

Type Arguments in Hugs
by Anthony Clayden 05 Jun '21

05 Jun '21

I'm looking on bemused as the Visible `forall` aka RequiredTypeArguments proposal goes through GHC Committee discussion. I sympathise with Simon M's alarm at the namespacing effects needed. SPJ's attempt at softening the blow: https://mail.haskell.org/pipermail/ghc-steering-committee/2021-June/002463.… > Like Simon [M], I'm sad that I have to write > f (List Int) > or > f (type [Int]) > but I think the alternative (of requiring the reader to know > the type of the function in order to resolve the binding of names > in its argument) is much, much worse. If a `type` herald is supposed to emolliate me, I have Hugs accepting this: Hugs> sizeOf (:: Int) 4 Hugs> typeOf (:: [Int]) TypeRep 3 ... * `(:: t)` -- the parens are required -- is a lot less cluttered than Proxy; * It's a little less cluttered than the proposed `type`; * More importantly, it heralds much better to my eye 'here comes a type'. I'm curious why so much of the proposal uses the `sizeOf` example. Its type currently is `Sized a => a -> Int`. It seems to me quite useful I can supply a term as argument -- I might well have in scope a (term) var of the required type. I haven't needed to change the type of `sizeOf` for the Hugs heralded syntax. The syntax is sugar for `(termType :: Int)`, in which `termType` is in effect the same as `undefined`, but with a name more revealing for diagnostics. Whereas the proposal won't actually help with `sizeOf`, until/unless the library changes its signature -- thereby breaking a load of code and dependencies. Or introduce a different-named function? The other Motivation from the proposal is to fix an inconsistency with DataKinds. It seems to me there's another way to fix such an inconsistency: change the design for DataKinds -- which to me has always been a bit of a kludge. There's also some interaction in the ugliness with `ScopedTypeVariables` -- which, with the benefit of hindsight, is increasingly getting regarded as a mis-feature. Hugs has always had the `PatternSignatures` feature, and indeed `FunctionSignatures`. It seems to me that erasure/pi-types is an implementation detail that should be kept out of the surface syntax. If the programmer wants to signal that it's the type of a term that's of concern (such that the term can be erased as well as -- ultimately -- its type), annotate the terms' position in the signature (something like with strictness), rather than banjaxing familiar syntax. Behind the scenes translate to a pi-types implementation. AntC

1 0