I know lots of people still using HUGS. The question was not whether people use HUGS, but whether HUGS uses this code. This is not the same thing. According to HUGS homepage last release was 7 years ago - does it rely on current versions of base et al. or does it ship with its own?

Janek

Hugs ships it's own base; hugs98-plus-Sep2006 has libraries that roughly match GHC 6.6 (base, QuickCheck, X11, HGL, OpenGL etc - those were the days!) Frankly I'd be extremely surprised if anyone using Hugs was using a modern copy of base. If they are, either it's all perfect and nobody is complaining, but I honestly find this quite unlikely considering we don't see patches *ever*. In fact, I just looked through the Git history, and I can't seem to find anything relevant here. The code has been shuffled around some (people don't just delete it,) but none really added, fixed, or brought up to date. For years and years. I'm voting we delete it. In fact: I say if nobody pipes up and is *committed* to maintaining it, we delete it, oh, two weeks. That's standard library-proposal timeframe. (And I do mean maintenance - not "drop barely enough work to get it into shape and then leave it alone for 5+ more years.") CC'd: Edward, do you have any thoughts? Perhaps this should go to libraries@ ? If not, I'd even say we should go ahead and just get rid of it sooner (like, next week) rather than later, when we're this far into the release window. On Wed, Sep 11, 2013 at 11:30 AM, Johan Tibell wrote:

I think we should delete the code.

It most likely doesn't work anymore due to bitrot (i.e. no one has tested the other side of the #fidef in years) so it adds clutter without value. If someone feels strongly about keeping it I think they should

* fix it and * set up a buildbot so we know when we break it in the future.

On Wed, Sep 11, 2013 at 7:22 AM, Jan Stolarek wrote:

...

...

I know lots of people still using HUGS. The question was not whether people use HUGS, but whether HUGS uses this code. This is not the same thing. According to HUGS homepage last release was 7 years ago - does it rely on current versions of base et al. or does it ship with its own?

Janek _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

-- Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Herbert, Yes, you are right. It was my experience when compiling base with haskell-names' hs-gen-iface that, unless __GLASGOW_HASKELL__ is defined, many functions (including H2010) would simply not be defined, and some code wouldn't even be well-formed Haskell. First I tried to fix that on the spot, but there were so many cases that I gave up and made hs-gen-iface define __GLASGOW_HASKELL__ despite not being one. I'm not sure these ifdefs nowadays have any value whatsoever. Roman On Sun, Sep 15, 2013 at 1:09 PM, Herbert Valerio Riedel wrote:

Hi,

On 2013-09-15 at 09:06:13 +0200, Austin Seipp wrote:

...

I'm voting we delete it. In fact: I say if nobody pipes up and is *committed* to maintaining it, we delete it, oh, two weeks. That's standard library-proposal timeframe. (And I do mean maintenance - not "drop barely enough work to get it into shape and then leave it alone for 5+ more years.")

Fyi, I've gone ahead and started preparing validate-checked removal commits for two of the affected packages:

- https://github.com/hvr/packages-base/compare/kill-hugs-support

- https://github.com/hvr/packages-array/compare/kill-hugs-support

...while going through the #ifdef's and playing human CPP I couldn't help but wonder whether the `#if(n)def __GLASGOW_HASKELL__` are worth it: Some places didn't look as if they would compile if `__GLASGOW_HASKELL__` wasn't defined.

Cheers, hvr _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs