- Hugs-Bugs - Haskell.org

Re: Broken link on download page
by Anthony Clayden 18 Oct '25

18 Oct '25

(refreshing a message from 2018, that might have got lost in the mailman list updates) The Hugs download page here:https://www.haskell.org/hugs/pages/downloading.htm Has broken links for the latest (Sept 2006) downloads of Hugs for Windows. Should be: * WinHugs-Sep2006.exehttps://www.haskell.org/hugs/downloads/2006-09/WinHugs-S… * MinHugs-Sep2006.exehttps://www.haskell.org/hugs/downloads/2006-09/MinHugs-S… (Those links currently point to Neil Mitchell's repositories, which have ceased to be.) Links to downloads for other platforms look OK. (I haven't tried them all.) Hugs and WinHugs still run fine, even on a 64-bit Windows machine, by the way. And Trex just works like it says on the tin. AntC

1 0

None
by None 06 Sep '25

06 Sep '25

Perhaps we could put a bandaid on it with a #define of MAXPATHLEN as suggested in the Debian bug report: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=101506 Hurd could use some Hugs after all :) peace, isaac

1 0

None
by None 06 Sep '25

06 Sep '25

static Void local addScriptName(s,sch) /* Add script to list of scripts */ String s; /* to be read in ... */ Bool sch; { /* TRUE => requires pathname search*/ if (namesUpto>=NUM_SCRIPTS) { ERRMSG(0) "Too many module files (maximum of %d allowed)", NUM_SCRIPTS EEND; } else scriptName[namesUpto] = strCopy(sch ? findPathname(NULL,s) : s); scriptReal[namesUpto] = strCopy(RealPath(scriptName[namesUpto])); namesUpto++; }

1 0

None
by None 06 Sep '25

06 Sep '25

[1.5, 1.6..] and [1.5, 1.6..2.0] (i.e. enumFromThen and enumFromThenTo) but enumFrom and enumFromTo making list of rounded integers seems strange to me. It seems to me that enumFromThen and -To could be implemented something like: enumFromThen beg next = beg : enumFromThen next (next+delta) where delta = next-beg similarly for enumFromThenTo, of course. i.e. depending only on functionality found in Num. Why not put these functions there, and remove Float and Double as Enum instances? What am I missing? -kzm -- If I haven't seen further, it is by standing in the footprints of giants

1 0

None
by None 06 Sep '25

06 Sep '25

when called thus: select 0 [ ] Hugs gives the error message: ERROR - Unresolved overloading *** Type : Eq a => [a] *** Expression : select 0 [ ] Surely Haskell should be able to just return [ ] in both cases. Thanks ahead for your response. Prof Ernest Paquet Walsh University 2020 Easton St. N.W. Canton, OH, 44720 (USA) Phone voice: 330-490-7229 fax: 330-490-7165

1 0

None
by None 06 Sep '25

06 Sep '25

gives error message: ERROR - Cannot find "show" function for: *** Expression : take 1 [ ] *** Of type : [a]

1 0

None
by None 06 Sep '25

06 Sep '25

should also do the job, but it gives the same error message: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ module BUG2C where import Prelude () import BUG2A ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Is this a known problem? Cheers -Peter

1 0

[hugs-bugs] Trex illegal? overlapping instances for derived classes -- is this intended?
by Anthony Clayden 26 Jun '25

26 Jun '25

> > ... decls that aren't allowed if I try to put them explicitly. > They're rejected as overlapping, and in no substitution ordering. > Ah, I see this limitation is acknowledged in SPJ&MPJ 1999 'Lightweight Extensible Records for Haskell' proposal. https://www.microsoft.com/en-us/research/wp-content/uploads/1999/01/recpro.… Section 5.3 Instances: > instance D {r|x::a} where ... -- INSTANCES > instance D {r|y::b} where ... -- OVERLAP! (Note under that proposal the `r` representing the 'tail' of the record is prefixed.) For the record, I amended Hugs/Trex such that those instances do not overlap, provided each instance head mentions only a single label, and the labels are distinct. (Or depending on your point of view: they do overlap, but in a strictly-more-specific ordering given by the canonical ordering of labels.)

1 0

Trex illegal? overlapping instances for derived classes -- is this intended?
by Anthony Clayden 19 Sep '22

19 Sep '22

For derived instances I'm getting decls that aren't allowed if I try to put them explicitly. They're rejected as overlapping, and in no substitution ordering. > import Hugs.Trex > > type UserId = Int > type EventId = Int > > data Message > = SendChat (Rec ( message :: String, user :: UserId )) > | Signup (Rec ( eventId :: EventId, user :: UserId )) > deriving (Eq) > There's an `instance Eq Message` -- fine. >From Hugs.Trex I get (and these are fine) > instance EqRecRow a => Eq (Rec a) -- pass through to a specialised class > instance EqRecRow EmptyRow These are generated by the `deriving`; note they're not specialised to the field's type, nor for rows with combinations of labels: > instance (Eq a, b\eventId, EqRecRow b) => EqRecRow (eventId :: a | b) > instance (Eq a, b\user, EqRecRow b) => EqRecRow (user :: a | b) > instance (Eq a, b\message, EqRecRow b) => EqRecRow (message :: a | b) Not specialising and not combining labels makes sense: then no clash if I also had: > data Probe a b c > = MkProbe (Rec (user :: a, message :: b, eventId :: c)) > deriving (Eq) But those generated instances for `EqRecRow` overlap in no substitution ordering -- as Hugs tells me if I try to declare them explicitly. How does a wanted for `(MkProbe x) == (MkProbe y)` resolve to the wanted instances? There's no preference ordering -- or is there? Precisely because 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: it'll get to the same answer. But I don't see how this fits with Hugs usual approach for overlaps. AntC

1 0

Trex-generated Show instances dodgy
by Anthony Clayden 25 Aug '22

25 Aug '22

Strange: on loading this module, Hugs complains (this is standard-issue Sep 2006 Hugs in Hugsmode) > - An instance of ShowRecRow (x :: a, y :: a) is required to derive Show (NPoint a) Just loading it again and the complaint disappears. > module NPoint where > > import Hugs.Trex > > newtype Num a => NPoint a = MkNPoint ( Rec( x :: a, y :: a)) deriving (Eq, Show) > If I ask for :info ShowRecRow after the failed load, I see an instance each for label x, y -- as well as the EmptyRow instance (standard with Hugs.Trex). If I :load Hugs.Trex after the failed load, those two instances have gone; I can load NPoint ok. On firing up Hugs, if I :load Hugs.Trex before :load NPoint, the error still happens. But if I >print (z = 5) -- some arbitrary label then :load NPrint, all is fine. (And there's no ghost ShowRecRow instance for z.) If I 'clear modules' after the failed load; then :load NPoint, no error. Same for an ordinary data decl wrapping a Trex record, with deriving. Same if I include some arbitrary `silly = show (silly = "shilly")`. AntC

1 0