- Hugs-Users - Haskell.org

Datatype (and Newtype) contexts: improvement
by Anthony Clayden 14 Oct '20

14 Oct '20

(For some background to my thinking see here https://mail.haskell.org/pipermail/haskell-cafe/2020-September/132714.html ) There's a part of the spec for DatatypeContexts that's been there since the beginning (1991), but doesn't seem right to me. The effect of the 1999 'clarification' to the spec makes it seem even less right. >From the 1991 memo "each constructor gets a context which is a subset of that given in the @data@ decl, containing all the constraints on the free type variables of the constructor signature, and no others." So we get (example from the 1998 Language Report) data Eq a => Set a = NilSet | ConsSet a (Set a) ===> NilSet :: forall a. Set a ===> ConsSet :: forall a. Eq a => a -> Set a Well, in the type signature for NilSet, `a` _is_ free, why can't it get the constraint? It's easy enough to give a signature with constraint for some appearance of `NilSet` -- except in the one place I desperately want one, that is in patterns. I can define nilSet = NilSet :: Eq a => Set a and use that on rhs of function definitions, etc. The compiler doesn't seem to come crashing down around my ears. Whereas without the `Eq a`, you can write `NilSet :: Set (Int -> Int)` without complaint to produce an unusable value -- something that will cause complaints every other place you try to consume it or Cons to it. Compare emptyS1 NilSet = True -- inferred :: Set a -> Bool emptyS1 _ = False emptyS2 (ConsSet _ _) = False -- inferred :: Eq a => Set a -> Bool emptyS2 _ = True Those two definitions are morally equivalent, but get different types. Note that prior to the 1999 'clarification' GHC would have given them both the same signature without the `Eq a`. The brains trust in 1999 was firmly of the mind the constraint should be exposed everywhere. If they'd been asked about that type for NilSet and how it didn't expose the constraint, I wonder what they'd say? Anyhoo, this note is to say it seems easy enough to modify Hugs to give the full set of constraints for every data constructor (and consequently get those exposed, so the two definitions form `emptyS` above get the same type, with the `Eq a`). Would the concern in the 1991 memo still apply in 1999, or 2006 when Hugs development ceased? "I was persuaded ... by John's comments, and by the fact that many more cases of ambiguity are likely to arise otherwise." John Hughes(?) Anyway I can see no comments on the forum. Would the ambiguities be any worse than those for Numeric Literals being `Num a => a`? Or does the defaulting mechanism rescue those? AntC

1 0

Some idioms for Trex
by Anthony Clayden 06 May '20

06 May '20

Making best use of Trex needs a different mindset vs H98 datatypes with named fields. (Or indeed vs named-fields data structures in many languages) There's some examples around in the Trex/Hugs material, but I've seen nothing showing this: > type WPoint r = (x :: Float, y :: Float | r) -- r extended "with Point" > type WRadius r = (radius :: Float | r) > type WColour r = (colour :: String | r) > type ColouredCircle = Rec( WColour (WRadius (WPoint EmptyRow))) The idea is rather than nest 'Point' as a datatype inside 'Circle' 'plug and play' components (such as Point, Radius) to give a structural type. It's interesting and impressive that the Wxxx synonyms take an argument of kind row, return a result of kind row. `EmptyRow` in the last line is a Hugs-defined Row constant that 'plugs' the end of the composed components, just as `emptyRec` does for Trex Records. I'd love to write that last type as > type MkRec r = Rec( r EmptyRow) > type ColouredCircle = MkRec (WColour . WRadius . WPoint) But of course type synonyms -- even with parameters -- are not functions; can't be composed; can't be passed to higher-order type synonyms. Components like WPoint can be arguments to type-parametric functions for record subtyping: such as a generic routine to 'move' any shape by modifying its x, y coordinates. 'Move' in scare quotes because that's returning a copy of the shape's data structure with modified coordinates, not poking values into an object/reference.

1 0

fun with yacc, and with Trex
by Anthony Clayden 02 May '20

02 May '20

To keep the Hugs community in the loop ... Now that I have a compilable compiler, I'm picking some low-hanging fruit with syntax sugar. * I've taught Trex to support field labels starting upper-case, because, well for me they're more like constructors than variables. Unlike H98, Trex doesn't generate field accessor functions. You get #label -- or rather #Label for that. * I've always wanted records to use syntax with braces { X = 1, Y = 2 } , because, well they're a set of name-value pairs, not a mathematician's sequenced tuple. Indeed the original Gaster & Jones 1996 paper used braces. * A slight compromise: the syntax just above is ambiguous with H98, so you must put a | at the end { X = 1, Y = 2 |}. yacc inserts a `emptyRec` in the end. * And I have a format for building or updating records that uses straight { } rather than suffixing it. Might as well propose it for GHC https://github.com/ghc-proposals/ghc-proposals/issues/328. So H98 syntax, my better syntax and Trex with { ... } are co-existing. * I've added a form of NamedFieldPuns for Trex -- in both expressions and patterns: foo { X = | r } = { Y = ##X, X = | r } Heh heh punning on upper-case field labels gives an upper-case variable name. ##X goes grab the pseudo-variable. * And that's all achieved with yacc (and a bit of lexing). I haven't touched the main compiler code, which gives me good confidence I didn't stuff something up. I'm now looking at stealing some syntax from the Habit language. And syntax for FunDeps more in line with the original Mark Jones 2000 paper. Because in class C a b c | a b -> c where ... `a b` does not mean `a` applied to `b`. Also that arrow is misleading: there's not a function, but a mechanism for unification/type improvement, which is chiefly aimed at improving `c`, but might also improve `{a, b}` at some usage sites. (The original paper used `~>`, in which the tilde nicely echoes GHC's so called 'type equality constraint' -- again that's a two-way unification mechanism, not merely a type-level test.) AntC

1 0

Re: [Hugs-users] compiling hugs
by Anthony Clayden 29 Apr '20

29 Apr '20

The news is improving, I have a working system (on Windows, including WinHugs). Not all of the libraries compiled, and some are bitrotted beyond repair. But I think there's enough for your objective of using Hugs to bootstrap GHC. In particular, you'll need to get working a couple of preprocessors: * hsc2hs -- HSC format is a hybrid Haskell/C; pre-processed to .hs + .c + .h * cpphs -- "a simplified re-implementation" of C++ pre-processor, in Haskell. They're both used extensively in the `make` building libraries/packages. Both of those need a bit of polishing-up, see Franklin's repo. (He was also working on Mac, did you see his homebrew kit?) For the sake of posterity I'll post some notes here with the travails of getting Hugs up and running. Some of the code is very ancient -- pre the C 1999 standard. AntC > Hi Sam, I have some good news, but mostly bad news. > >* Please do let me know if anybody can figure out how to compile the *>* missing library! * >To answer your last point first, Franklin Chen figured out how to compile the library -- it's a two-line fix, that gets three .dlls to compile. See around line 220 in here: https://github.com/FranklinChen/hugs98-plus-Sep2006/blob/master/packages/ba… ; also see the git change history for that header file.

1 0

Re: [Hugs-users] compiling hugs
by Anthony Clayden 22 Apr '20

22 Apr '20

Hi Sam, I have some good news, but mostly bad news. > > Please do let me know if anybody can figure out how to compile the > missing library! To answer your last point first, Franklin Chen figured out how to compile the library -- it's a two-line fix, that gets three .dlls to compile. See around line 220 in here: https://github.com/FranklinChen/hugs98-plus-Sep2006/blob/master/packages/ba… ; also see the git change history for that header file. One piece of bad news is you can't simply apply that patch and continue the make: the make had already got three compile fails: Ptr.dll, Alloc.dll, Error.dll. So the error you report is somewhat later when something tries to grab Ptr.dll and it isn't there. You'd need to compile those three by hand, then restart the make. Given your goals, I think you'd do better to blow away what you have, unzip from the distro and start again. But wait! There are heaps more patches that Franklin applied, including some to other header files that are very similar to the fix to HsBase.h. So I'm nowhere near getting the make to finish. Furthermore I'm getting tripped up by bits of earlier installs hanging around. On Windows, Hugs holds stuff in Registry HKEY_CURRENT_USER. My attempted make keeps picking up directory names from there, then getting banjaxed. I haven't looked at the Mac install process to see if you'd run into that. > I had considered doing that [grabbibg binaries from elsewhere], > but I didn't want to start downloading > binaries because my entire interest in hugs is driven by a compulsion to > be able to bootstrap a Haskell compiler with nothing but a C compiler to > hand and relying on pre-built binaries is as sinful as just using a > pre-built ghc in that frame of mind. Well the make uses a great variety of tools, not just gcc, and including sed, grep and perl (I think). If you're worried about provenance,take a look in the top-level Makefile. It accesses two repos over the interwebs and seems to download stuff from them using 'darcs get'. Clearly a vector to introduce malware. (Not that I'm suggesting anybody's malicious, probably those repos are dead; Joachim was particularly anxious to avoid any chance of Trojans getting into the build.) Please do have another crack. It'll be handy if you can turn up more fails. AntC

1 0

Re: [Hugs-users] compiling hugs
by Anthony Clayden 17 Apr '20

17 Apr '20

Hi again Sam, if you're still listening ... WIth time on my hands during the lockdown, I had a crack at making the libraries, and hit the same error, I think. I'm on Windows, so the build complained about not finding Ptr.dll. Indeed it wasn't created, even though there's a Ptr.c in the same directory. There's 2 other .dll's which give the same error: Alloc.dll, Error.dll; again there are .c files in the same directories. There's other .dll's that got built OK. So seems the make isn't picking up that it needs to compile the .c to .dll. DId you manage to figure out what's going on? I tried reading what the Makefile is doing, but it's too convoluted. To hack my way through it (this eventually worked, but it's very dodgy): I downloaded/unpacked the official Package distribution; found those .dll's in it; copied them into the place the make was looking for them; and restarted the make. There were a few other errors that I hacked through similarly; the make did eventually finish (I won't say OK ;-). So I have a kinda working cobbled-together system. AntC > However, I hit this compilation error and I was hoping somebody could help me to get past it: cd libraries; make all make[1]: Entering directory '/home/fommil/tmp/hugs98-plus-Sep2006/libraries' cd ../cpphs; HUGSFLAGS=-P../libraries/bootlib HUGSDIR=../hugsdir ../src/runhugs -98 ../packages/Cabal/examples/hapax.hs configure --verbose --hugs --prefix='/usr/local' --scratchdir='../hugsdir/packages/cpphs' --with-compiler=../src/ffihugs runhugs: Error occurred ERROR "../libraries/bootlib/Foreign/Ptr.hs" - Error while importing DLL "../libraries/bootlib/Foreign/Ptr.so": ../libraries/bootlib/Foreign/Ptr.so: cannot open shared object file: No such file or directory -- Best regards, Sam

2 1

Re: [Hugs-users] compiling hugs
by Anthony Clayden 30 Mar '20

30 Mar '20

> I realise this mailing list is long defunct, ... Hi Sam, defunct but not forgotten. (Sorry I took a while to see your post.) I've been able to compile some of Hugs. That's on a Windows machine with MinGW/MSys. I'll probably not be able to help much with GNU/Linux, but FWIW the bit I couldn't get to compile was exactly the FFI. Also I had quite a bit of trouble backtracking to Win32: mine is a 64-bit machine, but I had to run everything in 32-bit mode, because the config files didn't know anything about 64-bit. Re FFI: do you need to support foreign functions? What I did in the end was just take the FFI objects from the distro, not recompile. (Hack the makefile to make only the /src sub-dir, miss out /libraries, /docs.) I'm interested only in modifying the language/syntax/semantics, not building industrial-strength interfaces. > ... but I am nevertheless interested in compiling hugs on a modern GNU/Linux system, > primarily motivated by thoughts that are along the lines of > http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC Yes, I thought Joachim was both a hero and foolish for trying. At a guess, you don't need FFI to bootstrap enough of the language to get a compiler running with the Prelude(?) By all means I'm happy for you to bounce ideas around. AntC > However, I hit this compilation error and I was hoping somebody could > help me to get past it: cd libraries; make all make[1]: Entering directory '/home/fommil/tmp/hugs98-plus-Sep2006/libraries' cd ../cpphs; HUGSFLAGS=-P../libraries/bootlib HUGSDIR=../hugsdir ../src/runhugs -98 ../packages/Cabal/examples/hapax.hs configure --verbose --hugs --prefix='/usr/local' --scratchdir='../hugsdir/packages/cpphs' --with-compiler=../src/ffihugs runhugs: Error occurred ERROR "../libraries/bootlib/Foreign/Ptr.hs" - Error while importing DLL "../libraries/bootlib/Foreign/Ptr.so": ../libraries/bootlib/Foreign/Ptr.so: cannot open shared object file: No such file or directory

1 0

compiling hugs
by Sam Halliday 22 Mar '20

22 Mar '20

Hi all, I realise this mailing list is long defunct, but I am nevertheless interested in compiling hugs on a modern GNU/Linux system, primarily motivated by thoughts that are along the lines of http://www.joachim-breitner.de/blog/748-Thoughts_on_bootstrapping_GHC However, I hit this compilation error and I was hoping somebody could help me to get past it: cd libraries; make all make[1]: Entering directory '/home/fommil/tmp/hugs98-plus-Sep2006/libraries' cd ../cpphs; HUGSFLAGS=-P../libraries/bootlib HUGSDIR=../hugsdir ../src/runhugs -98 ../packages/Cabal/examples/hapax.hs configure --verbose --hugs --prefix='/usr/local' --scratchdir='../hugsdir/packages/cpphs' --with-compiler=../src/ffihugs runhugs: Error occurred ERROR "../libraries/bootlib/Foreign/Ptr.hs" - Error while importing DLL "../libraries/bootlib/Foreign/Ptr.so": ../libraries/bootlib/Foreign/Ptr.so: cannot open shared object file: No such file or directory -- Best regards, Sam

1 0

props for Hugs over System FC
by Anthony Clayden 25 Mar '19

25 Mar '19

heh heh. I've got to record this for posterity. I've never known an example before. Some code that compiles in Hugs and works fine; but GHC (8.6.4) can't typecheck so rejects. It's an example in the 2011 'System F with Type Equality Coercions', section 2.3 discussing FunDeps; and used to justify the extra power of type inference in Type Families as opposed to FunDeps. Full details discussed here: https://gitlab.haskell.org/ghc/ghc/issues/16430#note_189393 class F a b | a -> b instance F Int Bool class D a where { op :: F a b => a -> b } instance D Int where { op _ = True } True that doesn't compile as given. Hugs says: 'Inferred type is not general enough'. GHC says 'Couldn't match expected type `b' with actual type `Bool''/ '`b' is a rigid type variable'. (So essentially the same failure of typechecking.) With a little help for the type inference, this compiles in Hugs. class F a b | a -> b instance F Int Bool class D a where { op :: (F a b) => a -> b } instance (TypeCast Bool b') => D Int where { op _ = typeCast True } With `TypeCast` defined as for HList. That dangling type variable `b'` in the constraint is weird. But GHC still rejects it; and rejects a version with a `(~)` constraint instead of the `TypeCast`. AntC

1 0

Explain typeclass instance resolution
by Anthony Clayden 06 Dec '18

06 Dec '18

He he, while I was poking about in the type inference code ... There's an experimental command `:xplain` instance resolution. The code to implement it needs switching on with a preprocessor flag set in options.h.in then ./configure and recompile Hugs. Use it by giving a constraint to be explained: Hugs> :x Show (Maybe [Int]) (It seems a bit temperamental, fair enough for a hidden feature: if it can't resolve an instance, it'll say so, but also give some misleading messages with fragments of code leftover from previous uses.) AntC

1 0