Re: needing some Hugs
Anthony Clayden <[email protected]> Thu, 5 Jul 2018 21:46:23 +1200
| Newsgroups | gmane.comp.lang.haskell.hugs.user |
|---|---|
| Message-ID | <CAM7nRYSBKs9LoZuNsip4KmgyJMXZdmHFJk=wPkZ0swDCJ8Sc3w@mail.gmail.com> |
--===============0318405910035194456== Content-Type: multipart/alternative; boundary="0000000000003ca97805703d6c51" --0000000000003ca97805703d6c51 Content-Type: text/plain; charset="UTF-8" On Thu, 5 Jul 2018 at 8:29 PM, Neil Mitchell wrote: > Hi Ant, > Thanks for replying Neil. > I don't believe anyone still maintains or uses Hugs Yes, that's what I was expecting. - you'd be better off looking at GHC. > Why? I mean seriously: if the docos for TRex are accurate, all that non-maintenance for Hugs has still produced a better records system than GHC has managed, in well over a decade. GHC has some tweaks for records (FieldPuns and DisambiguateRecordFields and friends, also now DuplicateRecordFields). But Trex would appear to have all that covered. Vintage ~2006 Hugs (with extensions) was very comparable to GHC (with glasgow-exts). There are some subtle differences in implementation of FunDeps and overlaps. GHC's implementation is what I'd call wrong/contrary to the literature. (SPJ's word is "bogus".) Hugs' implementation is more along the right lines. GHC's behaviour today is the same as 2006. Clearly it's not going to be fixed. GHC now has Type Families, which sometimes gives prettier code than FunDeps/overlaps. But no more functionality AFAICT. GHC has GADTs -- which I've never felt much use for. GHC has PolyKinds and DataKinds and Type-in-type, whose main effect is to generate impenetrable error messages (even when I didn't think I was using those extensions). (You can achieve DataKinds in Hugs with empty data decls -- see for example the HList paper.) Then I'm struggling to see anything for which I'd be "better off" with GHC. My experience from trying to contribute to the GHC design process is that GHC is becoming more complex, more abstract, more obtuse, its Haskell syntax is uglier (like Perl), and no more useful. The first extension since 2006 for which I see merit is the Quantified constraints. (It's hard to be sure until it's released and I can get my hands on it. I have in mind uses that haven't appeared in the literature or Trac testing. And my questions/suggestions have gone unanswered.) Note all the nutting-out for that was in an SPJ paper in 2000. "unanswered" seems to be a recurring issue with GHC 'maintenance' which is why I'm questioning your "better off". I seldom get answers to Stackoverflow q's or glasgow-users posts or cafe bright ideas. So thank you again for replying here. The features I'm looking for are clearly not going to happen unless I hack them myself. (In particular something that was sketched in a paper in 2002.) Hence my question here: I have a suspicion all that feature-bloat in GHC has made it harder to hack than it was in 2006. (And it seems it was already harder than for Hugs.) AntC > On Thu, Jul 5, 2018 at 12:37 AM Anthony Clayden > <[email protected]> wrote: > > > > Is anybody still listening here? > > > > I see the Hugs source distro is still around - vintage 2006, and there's > somebody curated it on github. > > > > I'm particularly looking for a version with TRex, but the github-curated > version doesn't seem to include that(?) > > > > Can anybody comment on how easy it is to compile Hugs (on Windows), > compared to compiling GHC? The instructions for Hugs make out it's > reasonably easy, whereas the instructions for GHC seem to be fraught with > gotchas. But perhaps Hugs has as many gotchas, just not documented(?) > > > > My impression from discussion forums when Hugs was still active, is that > Hugs source was easier to hack if you wanted to experiment with changes to > the language(?) > > > > What seems sad these days is that GHC is so monstrous and formidable, > hardly anybody builds experimental extensions to Haskell. > > > > Thank you > > AntC > > > > _______________________________________________ > > Hugs-Users mailing list > > [email protected] > > http://mail.haskell.org/cgi-bin/mailman/listinfo/hugs-users > --0000000000003ca97805703d6c51 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><br></div><div><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, 5 J= ul 2018 at 8:29 PM, Neil Mitchell wrote:<br></div><blockquote class=3D"gmai= l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left= :1ex">Hi Ant,<br> </blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">Thanks for reply= ing Neil.</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><= br> I don't believe anyone still maintains or uses Hugs</blockquote><div di= r=3D"auto"><br></div><div dir=3D"auto">Yes, that's what I was expecting= .</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><blockquote = class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid= ;padding-left:1ex"> - you'd be better=C2=A0off looking at GHC.<br> </blockquote><div dir=3D"auto"><br></div><div dir=3D"auto">Why?</div><div d= ir=3D"auto"><br></div><div dir=3D"auto">I mean seriously: if the docos for = TRex are accurate, all that non-maintenance for Hugs has still produced a b= etter records system than GHC has managed, in well over a decade.</div><div= dir=3D"auto">GHC has some tweaks for records (FieldPuns and DisambiguateRe= cordFields and friends, also now DuplicateRecordFields).</div><div dir=3D"a= uto">But Trex would appear to have all that covered.</div><div dir=3D"auto"= ><br></div><div dir=3D"auto">Vintage ~2006 Hugs (with extensions) was very = comparable to GHC (with glasgow-exts).</div><div dir=3D"auto">There are som= e subtle differences in implementation of FunDeps and overlaps.</div><div d= ir=3D"auto">GHC's implementation is what I'd call wrong/contrary to= the literature. (SPJ's word is "bogus".)<br></div><div dir= =3D"auto">Hugs' implementation is more along the right lines.</div><div= dir=3D"auto">GHC's behaviour today is the same as 2006. Clearly it'= ;s not going to be fixed.</div><div dir=3D"auto"><br></div><div dir=3D"auto= ">GHC now has Type Families, which sometimes gives prettier code than FunDe= ps/overlaps.</div><div dir=3D"auto">But no more functionality AFAICT.</div>= <div dir=3D"auto"><br></div><div dir=3D"auto">GHC has GADTs -- which I'= ve never felt much use for.</div><div dir=3D"auto"><br></div><div dir=3D"au= to">GHC has PolyKinds and DataKinds and Type-in-type, whose main effect is = to generate impenetrable error messages (even when I didn't think I was= using those extensions).</div><div dir=3D"auto">(You can achieve DataKinds= in Hugs with empty data decls -- see for example the HList paper.)</div><d= iv dir=3D"auto"><br></div><div dir=3D"auto">Then I'm struggling to see = anything for which I'd be "better off" with GHC.</div><div di= r=3D"auto">My experience from trying to contribute to the GHC design proces= s</div><div dir=3D"auto">is that GHC is becoming more complex, more abstrac= t, more obtuse, its Haskell syntax is uglier (like Perl), and no more usefu= l.</div><div dir=3D"auto"><br></div><div dir=3D"auto">The first extension s= ince 2006 for which I see merit is the Quantified constraints.</div><div di= r=3D"auto">(It's hard to be sure until it's released and I can get = my hands on it.</div><div dir=3D"auto">=C2=A0I have in mind uses that haven= 't appeared in the literature or Trac testing.</div><div dir=3D"auto">= =C2=A0And my questions/suggestions have gone unanswered.)</div><div dir=3D"= auto">Note all the nutting-out for that was in an SPJ paper in 2000.</div><= div dir=3D"auto"><br></div><div dir=3D"auto">"unanswered" seems t= o be a recurring issue with GHC 'maintenance' which is why I'm = questioning your "better off".</div><div dir=3D"auto">I seldom ge= t answers to Stackoverflow q's or glasgow-users posts or cafe bright id= eas.</div><div dir=3D"auto">So thank you again for replying here.</div><div= dir=3D"auto"><br></div><div dir=3D"auto">The features I'm looking for = are clearly not going to happen unless I hack them myself.</div><div dir=3D= "auto">(In particular something that was sketched in a paper in 2002.)</div= ><div dir=3D"auto">Hence my question here: I have a suspicion all that feat= ure-bloat in GHC has made it harder to hack than it was in 2006.=C2=A0</div= ><div dir=3D"auto">(And it seems it was already harder than for Hugs.)</div= ><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div><div dir=3D"auto">= AntC</div><div dir=3D"auto"><br></div><blockquote class=3D"gmail_quote" sty= le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br> On Thu, Jul 5, 2018 at 12:37 AM Anthony Clayden<br> <<a href=3D"mailto:[email protected]" target=3D"_blank">antho= [email protected]</a>> wrote:<br> ><br> > Is anybody still listening here?<br> ><br> > I see the Hugs source distro is still around - vintage 2006, and there= 's somebody curated it on github.<br> ><br> > I'm particularly looking for a version with TRex, but the github-c= urated version doesn't seem to include that(?)<br> ><br> > Can anybody comment on how easy it is to compile Hugs (on Windows), co= mpared to compiling GHC? The instructions for Hugs make out it's reason= ably easy, whereas the instructions for GHC seem to be fraught with gotchas= . But perhaps Hugs has as many gotchas, just not documented(?)<br> ><br> > My impression from discussion forums when Hugs was still active, is th= at Hugs source was easier to hack if you wanted to experiment with changes = to the language(?)<br> ><br> > What seems sad these days is that GHC is so monstrous and formidable, = hardly anybody builds experimental extensions to Haskell.<br> ><br> > Thank you<br> > AntC<br> ><br> > _______________________________________________<br> > Hugs-Users mailing list<br> > <a href=3D"mailto:[email protected]" target=3D"_blank">Hugs-Users= @haskell.org</a><br> > <a href=3D"http://mail.haskell.org/cgi-bin/mailman/listinfo/hugs-users= " rel=3D"noreferrer" target=3D"_blank">http://mail.haskell.org/cgi-bin/mail= man/listinfo/hugs-users</a><br> </blockquote></div></div> --0000000000003ca97805703d6c51-- --===============0318405910035194456== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KSHVncy1Vc2Vy cyBtYWlsaW5nIGxpc3QKSHVncy1Vc2Vyc0BoYXNrZWxsLm9yZwpodHRwOi8vbWFpbC5oYXNrZWxs Lm9yZy9jZ2ktYmluL21haWxtYW4vbGlzdGluZm8vaHVncy11c2Vycwo= --===============0318405910035194456==--