On Fri, Jan 11, 2013 at 11:43:56PM +0100, Bas van Dijk wrote:

On 11 January 2013 21:00, Gregory Collins wrote:

...

First: Bas, would you support making case-insensitive a Haskell platform package?

Yes, I would support that.

...

Assuming you say yes, I'd like to propose it for inclusion in the Haskell platform. The wiki page for this proposal is here:

http://trac.haskell.org/haskell-platform/wiki/Proposals/case-insensitive

Great! I won't object to making minor changes that people would like to see like:

* getting rid of UnicodeSyntax

I would certainly prefer if the code would be ASCII ;) Cheers, Simon

* Henning Thielemann [2013-01-12 11:17:40+0100]

However, if the package is included in the platform I would prefer to have it converted to plain Haskell 98 first, which should not be too hard.

IMO, such requests shouldn't be made on per-package basis. There should be a policy regarding standard compliance of the platform packages. The status quo is that a large part of the platform is not Haskell2010, and converting it to Haskell2010 does not seem feasible. So the policy seems to be that the platform does not require the packages to be H2010 (or H98, for that matter). Roman

* Henning Thielemann [2013-01-12 12:40:22+0100]

On Sat, 12 Jan 2013, Roman Cheplyaka wrote:

...

* Henning Thielemann [2013-01-12 11:17:40+0100]

...

However, if the package is included in the platform I would prefer to have it converted to plain Haskell 98 first, which should not be too hard.

IMO, such requests shouldn't be made on per-package basis.

Ok, I like to request this for the whole platform. :-)

This is easier to say than to do :) E.g. here's the result of a quick grep of the bytestring source code. ./Data/ByteString.hs:import GHC.IO.Handle.Internals ./Data/ByteString.hs:import GHC.IO.Handle.Types ./Data/ByteString.hs:import GHC.IO.Buffer ./Data/ByteString.hs:import GHC.IO.BufferedIO as Buffered ./Data/ByteString.hs:import GHC.IO (unsafePerformIO, unsafeDupablePerformIO) ./Data/ByteString.hs:import GHC.IOBase ./Data/ByteString.hs:import GHC.Handle ./Data/ByteString.hs:import GHC.Prim (Word#) ./Data/ByteString.hs:import GHC.Base (build) ./Data/ByteString.hs:import GHC.Word hiding (Word8) ./Data/ByteString/Unsafe.hs:import GHC.Prim (Addr#) ./Data/ByteString/Unsafe.hs:import GHC.Ptr (Ptr(..)) ./Data/ByteString/Builder/Prim/Internal/UncheckedShifts.hs:import GHC.Base ./Data/ByteString/Builder/Prim/Internal/UncheckedShifts.hs:import GHC.Word (Word32(..),Word16(..),Word64(..)) ./Data/ByteString/Builder/Prim/Internal/UncheckedShifts.hs:import GHC.Word (uncheckedShiftRL64#) ./Data/ByteString/Builder/Internal.hs:import GHC.IO.Buffer (Buffer(..), newByteBuffer) ./Data/ByteString/Builder/Internal.hs:import GHC.IO.Handle.Internals (wantWritableHandle, flushWriteBuffer) ./Data/ByteString/Builder/Internal.hs:import GHC.IO.Handle.Types (Handle__, haByteBuffer, haBufferMode) ./Data/ByteString/Internal.hs:import GHC.Base (realWorld#,unsafeChr) ./Data/ByteString/Internal.hs:import GHC.IO (IO(IO)) ./Data/ByteString/Internal.hs:import GHC.IOBase (IO(IO),RawBuffer) ./Data/ByteString/Internal.hs:import GHC.IO (unsafeDupablePerformIO) ./Data/ByteString/Internal.hs:import GHC.IOBase (unsafeDupablePerformIO) ./Data/ByteString/Internal.hs:import GHC.ForeignPtr (mallocPlainForeignPtrBytes) ./Data/ByteString/Internal.hs:import GHC.ForeignPtr (ForeignPtr(ForeignPtr)) ./Data/ByteString/Internal.hs:import GHC.Base (nullAddr#)

...

There should be a policy regarding standard compliance of the platform packages.

The status quo is that a large part of the platform is not Haskell2010, and converting it to Haskell2010 does not seem feasible.

So the policy seems to be that the platform does not require the packages to be H2010 (or H98, for that matter).

That's sad and if this is wanted by most users, then it should be called GHC platform, not Haskell platform.

To be fair, yes, I think this is what is wanted by most user. HP is, by design, something very practical, and in practical terms GHC is *the* Haskell implementation, as of today. (The reasons it's called Haskell platform are also very practical — namely, marketing and newcomer-friendliness.) I agree that this situation is sad, but package authors are the last ones to blame. Instead of needlessly constraining the code we write, it would be much better to update the Haskell standard to reflect the state of modern Haskell. But there doesn't seem to be much interest to work on the new version of Haskell (see the recent thread on the haskell-prime mailing list). Thus, today H98 and H2010 serve not as something that real code should conform to, but rather as baselines to which extensions are applied. Roman

* Henning Thielemann [2013-01-12 13:42:56+0100]

On Sat, 12 Jan 2013, Roman Cheplyaka wrote:

...

* Henning Thielemann [2013-01-12 12:40:22+0100]

...

On Sat, 12 Jan 2013, Roman Cheplyaka wrote:

Ok, I like to request this for the whole platform. :-)

This is easier to say than to do :)

E.g. here's the result of a quick grep of the bytestring source code.

On compilers other than GHC, ByteString could be defined as

newtype ByteString = ByteString (StorableVector Word8)

and StorableVector can be compiled on JHC.

It doesn't make it Haskell2010, though.

...

I agree that this situation is sad, but package authors are the last ones to blame. Instead of needlessly constraining the code we write, it would be much better to update the Haskell standard to reflect the state of modern Haskell.

It's a balance between work for library writers and work for Haskell tool writers. The more time library writers safe by using an extension, the more time Haskell tool developers have to invest in supporting those extensions.

True. That's why I put much hope into the Haskell suite. If your implementation's goal is to provide a different back-end, for example, then you shouldn't need to worry about the surface syntax and the type system. You just use available components for parsing, name resolution, desugaring and type checking, and get most of the extensions for free.

...

But there doesn't seem to be much interest to work on the new version of Haskell (see the recent thread on the haskell-prime mailing list).

Thus, today H98 and H2010 serve not as something that real code should conform to, but rather as baselines to which extensions are applied.

If you can easily avoid using an extension, like in the case of the TypeSynonymInstances and FlexibleInstances in case-insensitive then this seems better to me, than adding FlexibleInstances to all Haskell compilers and Haskell tools (haddock, hlint, etc.), going through a Haskell Prime proposal procedure, etc.

I am not so sure here. That helper method or type class is just an ugly hack to work around a limitation of the type class system. Using it does not improve the code itself. GHC shows that there's a way to lift this limitation (and it's been known for many years). Is that extension controversial in the type systems community? Why?

I also speak in a self-interest: We are developing a kind of Haskell interpreter for the live-sequencer: http://www.youtube.com/watch?v=sXywCHR9WwE

We are far from a complete Haskell 98 implementation and I am not keen on implementing extensions that are not really needed and it seems that the Haskell prime committee also does not have time for it.

I sympathise. But again, if the goal of your implementation is not to experiment with type systems, then (in the long run) you should be able to use the Haskell suite and not to care about these problems. Roman

I think that the Haskell Platform should respond to genuine, rather than theoretical, demand for portability. At the moment it looks like portability is work that no-one would actually benefit from. I don't think other compilers are not forthcoming because GHC dominates the ecosystem. I think GHC dominates the ecosystem because other compilers are not forthcoming. If people who are really developing an alternative compiler come forward and say, "I would like this package to work with my compiler", I say that's worth listening to. If we only hear theorising about the existence of such people, I don't think we should lose any sleep over it. So, Henning, you are the only person so far who has presented a possible concrete need: On Sat, Jan 12, 2013 at 01:42:56PM +0100, Henning Thielemann wrote:

I also speak in a self-interest: We are developing a kind of Haskell interpreter for the live-sequencer: http://www.youtube.com/watch?v=sXywCHR9WwE

We are far from a complete Haskell 98 implementation and I am not keen on implementing extensions that are not really needed and it seems that the Haskell prime committee also does not have time for it.

So even if not all packages in the platform are Haskell 2010, I would prefer that case-insensitive is Haskell 2010 for better portability, like the split package was successfully converted to Haskell 2010 for inclusion in the platform.

In response to this, I ask you: is compatibility with the platform really a goal for your live-sequencer? Would the live-sequencer benefit particularly from use of the case-insensitive package? Would making the case-insensitive package Haskell2010 enable it to work with your interpreter immediately? If the answer to any of those questions are no, I think portability work now is premature. If the real demand arises, we can always make the alterations necessary in a future version. --- That all said, I do have my own concerns with case-insensitive. Particularly, it provides an instance FoldCase ByteString, implicitly treating ByteStrings as text, which I believe should be discouraged. This is easily fixed, although may be controversial: remove the ByteString instances. This would perhaps be slightly less painful if there was something along the lines of: mkWith :: (s -> s) -> s -> CI s mkWith fc s = CI s (fc s) so that people insistent on using ByteString would be able to do so without risking orphan instances. However, the existence of the above function allows "unsafe" use, comparing values constructed with incompatible case-folding functions, which is probably a bad idea – perhaps ByteString people should stick to newtypes instead.

On 1/12/13 7:08 AM, Roman Cheplyaka wrote:

I agree that this situation is sad, but package authors are the last ones to blame. Instead of needlessly constraining the code we write, it would be much better to update the Haskell standard to reflect the state of modern Haskell.

Indeed. At the very least, age-old things like MPTCs, FlexibleEverything, and RankNTypes should be considered "standard" IMO.

But there doesn't seem to be much interest to work on the new version of Haskell (see the recent thread on the haskell-prime mailing list).

Alas. -- Live well, ~wren

On Sat, Jan 12, 2013 at 8:07 AM, Herbert Valerio Riedel wrote:

| Every package should fulfil the following requirements. Any | requirements that are not met must be clearly explained and justified | in the proposal. | | [...] | | - Compile on all operating systems and compilers that the platform | targets. [rationale-8.4]

But I couldn't find any explictly stated list which compilers beyond GHC (and which version(s) of GHC?) the HP actually wants to target.

As of right now, there is exactly one production-quality Haskell implementation, which is the only one the platform targets, so by definition a library using GHC-specific features is appropriate for inclusion in the platform. An argument can be made to change the definition, but that's what it is right now. A especially strong -1 from me to any effort to enforce Haskell 98 compatibility for Haskell Platform packages: that standard is 15 years old now, and has been superseded by Haskell 2010. At this point I think the argument for standards breaks down altogether because there's only one conformant Haskell 2010 implementation. It's not GHC's fault it doesn't have viable competitors: we shouldn't be making busy-work for package authors to make their code portable to other Haskell implementations that don't exist yet. G -- Gregory Collins

On 1/13/13 8:55 AM, Gregory Collins wrote:

A especially strong -1 from me to any effort to enforce Haskell 98 compatibility for Haskell Platform packages: that standard is 15 years old now, and has been superseded by Haskell 2010.

I think it would be unjust to require H2010 compliance, however I do think it would be good to strongly suggest that people hew closer to the standard than they would in non-platform code. In particular, some extensions have long been widely regarded as "standard Haskell" (e.g., MPTCs, RankNTypes, Flexible...) and I see no reason to preclude them, even if there are concerns about how exactly to codify them in a new Haskell standard. And other extensions are simple syntactic adjustments (e.g., KindSignatures, GADTSyntax) which would be unproblematic to codify, but haven't been for whatever reason; these too have little reason to be excluded from the platform. However, there are other extensions which are unlikely to ever spread beyond GHC (e.g., ImplicitParams) and still others that are still experimental within GHC (e.g., DataKinds, and frankly TypeFamilies). These extensions should, IMO, be looked on with caution. Granted, TFs and fundeps are too useful to exclude from the platform, but they definitely cause issues for other compilers like UHC and jhc. Since the goal of the platform is to provide a common core for Haskell ---not for GHC--- we must be wary of including these things, no matter how desirable they are. While it wouldn't be productive to outright exclude problematic extensions like these, I do think it should be subject of debate when deciding whether to add a new package or not. It's this belief that only GHC matters which is part of the reason why other compilers like UHC and jhc have had such difficulty getting a foothold. I for one welcome competition and was very sad to see Hugs go by the wayside. Competition helps foster creativity and helps keep us from getting stuck in accidental dead ends brought on by monopoly. But supporting UHC and jhc means more than paying lip service to the idea that it'd be nice to have competitors; it means actually making some sacrifices in order to help them along. The H98 and H2010 specifications may be out of date, but the platform should be a reasonable target for any aspiring Haskell compiler to master. Including every research extension GHC has accrued over the years sets the bar too high for any practical team to target. Even with its popularity, I doubt GHC itself would support many of these extensions, were not for the historical accident that they were implemented in GHC the first time around. -- Live well, ~wren

2013/1/13 wren ng thornton :

On 1/13/13 8:55 AM, Gregory Collins wrote:

...

A especially strong -1 from me to any effort to enforce Haskell 98 compatibility for Haskell Platform packages: that standard is 15 years old now, and has been superseded by Haskell 2010.

I think it would be unjust to require H2010 compliance, however I do think it would be good to strongly suggest that people hew closer to the standard than they would in non-platform code.

This is reasonable on its face; but the motivation of supporting research implementations is perhaps less than practical. Is the platform, as a "batteries included" environment, really intended to support compiler writers and researchers? In practice, production code is written for GHC and likely even relies on it for performance, syntax features and type system extensions. Many production languages are in practice defined by a leading implementation, the one used in production, even if they have a few research implementations. (The varied JVMs, Rubies and Pythons of the world come to mind.) Perhaps "production Haskell" has to be understood as a distinctive line of development of the language, marked out and maintained in a way compatible with its needs. -- Jason Dusek pgp // solidsnack // C1EBC57DC55144F35460C8DF1FD4C6C1FED18A2B

On 1/20/13 12:03 PM, Mark Lentczner wrote:

I believe the point of the Platform is so that the vast majority of developers have a stable, full featured Haskell environment to work from, and can mostly just use and depend on it.

Agreed.

It is not an aim that the platform's library set should be a "super-Prelude" that works multiple Haskell Implementations. That isn't to say we shouldn't be cautious about admitting packages using more exotic features of GHC: we should. But our caution should stem from concern about how they will impact user's code, and likely longevity and popularity of such extensions.

Which is exactly the point I was trying to make. As outdated as it is for a standard, Haskell2010 compliant code has the distinct benefit that it doesn't rely on anything that's liable to change in the foreseeable future. Certainly, one can go beyond H2010 and still be confident in portability to the future. But the further one strays, the more likely they are to run into things which will not survive the test of time. True, supporting research compilers is a personal goal of mine. However, the dictum to hew as close to H2010 as reasonable is something that stems from purely pragmatic concerns. Even if one is only interested in GHC, porting programs from one *version* of GHC to another can take a considerable amount of work when using advanced/experimental extensions to the language. If the goal is to provide a stable set of batteries, then the goal necessarily precludes advanced type hackery, since GHC's ability to infer types varies significantly from version to version. Of course, recognizing this point requires admitting to the fact that not all uses of a given extension are created equal. You can use type families in simple and straightforward ways which are unlikely to break, just as you can use fundeps in complex ways to forge type equality or force the compiler to solve Peano arithmetic. One of these is appropriate for the HP; one of them is not. The reason I brought up other compilers is that, if your code can be compiled on multiple compilers, then there's a very good chance that code will survive bitrot long enough to make it to the next upgrade, even in environments that can't afford to buy new equipment annually. Whereas, if your code broke anywhere in the transition from GHC 6.12 to GHC 7.4, then it's already demonstrated its instability. -- Live well, ~wren

On 22 January 2013 02:00, Gregory Collins wrote:

On Fri, Jan 11, 2013 at 9:00 PM, Gregory Collins wrote:

...

Any proposals for deadlines? Mark?

P.S. all: I've set the review deadline to Feb 10.

Is there any particular reason for this library to be in the Platform?

G -- Gregory Collins

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

-- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com http://IvanMiljenovic.wordpress.com

Adding the following rewrite rule makes the "case-insensitve" benchmark as fast as the "no-class" benchmark: {-# RULES "mk/ByteString" forall (bs :: B.ByteString). mk bs = CI bs (foldCaseBS bs) #-} foldCaseBS :: B.ByteString -> B.ByteString foldCaseBS bs = B.map toLower8' bs where toLower8' :: Word8 -> Word8 toLower8' w | 65 <= w && w <= 90 || 192 <= w && w <= 214 || 216 <= w && w <= 222 = w + 32 | otherwise = w Strangely, using the existing foldCase method or the toLower8 function makes the code slow again. I committed[1] this to the "hp" branch. Bas [1] https://github.com/basvandijk/case-insensitive/commit/158e0f02a7832ebe7e46f5...

On 1/30/13 6:36 PM, Bas van Dijk wrote:

I just realized one complication: case-insensitive depends on hashable which is not in the HP.

I think hashable should also be proposed for the HP:

I agree. Should we make this a separate proposal, or just keep it as a subproposal of adding case-insensitive? -- Live well, ~wren