- Hugs-Users - Haskell.org

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

Re: [Hugs-users] Datatype (and Newtype) contexts: improvement
by Anthony Clayden 15 Oct '20

15 Oct '20

Thanks Sam, apologies if I'm being dumb, but I'm not seeing the relevance of 'boilerplate'. I'm not trying to implement other compilers' language extensions (as would be clear from my occasional posts on the Hugs list). If you want GHC extensions, use GHC. There's no hope of writing stock H98 or even H2010 code. The last Hugs release (2006, used in HugsMode) has extensions way beyond the H2010 standard. I'm not trying to write code that's portable between GHC/Hugs. I'm tinkering with Hugs to give it semantics that GHC doesn't support/not even with all its extensions switched on. I'm tinkering in Hugs because it seems to be achievable whereas I just have no idea how to build GHC; and I suspect that even if I figured that out, tinkering inside GHC would be orders of magnitude more complex, because I'd keep running into all sorts of type-acrobat stuff from all of GHC's extensions. And I say "more complex" even though GHC is written in Haskell, and Hugs is written in C++ and I'd never programmed in C++ before working on Hugs; and even though C++ is imperative code, not functional. Hugs mostly uses vanilla C, with the ++ providing sourcecode edit directives -- so it goes some way towards the macro-generator of 'boilerplate' anyway. Realistically for 'industrial strength' applications like Cabal, GHC is the only game in town. Cabal should be conservative and not try to use 'bleeding edge' GHC extensions, but things like MultiParam TypeClasses, FlexibleInstances are very hard to do without (Hugs supports both). What's more, I don't see how a macro-generator like 'boilerplate' is going to help. It's not like you can macro-'translate' code using MPTCs back to H98. AntC On Thu, 15 Oct 2020 at 02:48, Sam Halliday <sam.halliday(a)gmail.com> wrote: > > Sorry, I should have started a fresh email instead of responding to the > mailing list. > > I just meant generally this might be of interest to you. The ability to > generate the code that many language extensions are generating, > therefore no need to add support in hugs. Making it easier for people to > write portable stock Haskell98 code. Maybe even things like Cabal could > be rewritten to use less extensions. > > Anthony Clayden wrote: > > Hi Sam, > > > > I'm not seeing what relevance `boilerplate` has to anything I wrote. > > > > The compiler is generating the type for the constructors within a > datatype > > (whether or not the decl gives a context). > > > > On Wed, 14 Oct 2020 at 18:55, Sam Halliday <sam.halliday(a)gmail.com> > wrote: > > > >> > >> Hi Anthony, > >> > >> Did you see this? > >> > >> http://hackage.haskell.org/package/boilerplate > >> > >> > >> > > -- > Best regards, > Sam >

1 0