Single-compiler vs. multi-compilers (or. implementation-defined vs. standardized) languages

[jaror]

@hasufell

we won’t be able to remove type families and friends from the language ever.

I don’t see why not with a proper deprecation cycle spanning many GHC releases.

But anyways the extensions will fade into obscurity like NPlusKPatterns and DataTypeContexts. Nobody really complains about those extensions cluttering the language any more.

[hasufell]

@jaror

I don’t see why not with a proper deprecation cycle spanning many GHC releases.

That would be a disaster. Are you going to tell companies maintaining millions of lines of proprietary code to “just” migrate to DT?

This is exactly why I hope we will get a conservative GHC fork.

[atravers]

…or maybe just a “partial fork”, by just keeping around a pre-9.0 version front section, which would continue to be compatible with the middle and back sections for version 9.0 and beyond (assuming the Core representation changes less than Glasgow Haskell).

However:

@david-christiansen

Part of it is that GHC got a lot better at the aspects that the other implementations had previously had going for them […]

…something which apparently is still happening:

@jaror

• Standard Chartered is planning to use GHC as a front end for their Mu dialect of Haskell.
• The Asterius and GHCJS compilers are also being integrated into GHC.

This “leave it to GHC” thinking is a problem - if everyone keeps assuming someone else will always volunteer to keep Glasgow Haskell Central up and running, what is the incentive to actually stay around? There’s always more interesting things (e.g. research) to move on with.

(…the HF may soon need to employ many more @chreekat’s! Will there be enough left over from $500k/year to pay for all those extra professionals? But who knows - maybe the advent of dependent [types in] Haskell will result in the programming masses taking fresh interest and joining in, perhaps even starting a new Haskell implementation…hey, it could happen :-)

[AntC2]

@santiweight

[Type Functions ] is an attempt to introduce staged closed evaluation of terms to Haskell’s type system. The feedback is quite positive - the critics of the proposal have even been swayed! There seems to be no resistance…

I’m not going to try to argue against that claim: I haven’t bothered to ‘resist’ because I’ve more or less abandoned GHC post-8.10. And the chief reason for that is because I see no benefit for me in DT: it’s just a burden of complexity.

People often complain about “DT”, but many don’t seem to complain about specific DT features such as visible dependent quantification and type functions

The design for Visible Dependent Quantification seems all wrong — even if I could see a use for the feature, the syntax is un-Haskellish. I said so long and loud. I was ignored. I’ve given up.

Type Functions come with some nasty hidden gremlins. I find I can do just fine with FunDeps.

[AntC2]

@unhammer

the sizeOf Bool (vs sizeOf @Bool) example made it very clear why that proposal would make things more ergonomic – I’ll bet I’m not the only one who found @Bool and Proxy confusing and unaesthetic the first time around,

You’re mixing up several things there; also those docos are fibs: there’s no proposal to change sizeOf from what’s in the Prelude today.

sizeOf never did use Proxy. What we need IMO is a way to say that in sizeOf False or sizeOf (undefined :: Bool) or sizeOf (type Bool), sizeOf is interested only in the type of its argument. The trouble with sizeOf @Bool — which anyway isn’ going to be supported — is the @… is optional: there’s no way to insist a type argument be provided.

If we want a type argument to be always provided, I see no reason for insisting it be the first arg following the function; whereas @… or a visibly dependent type arg must come first. So I find these first exemplars of DT to be just _un_ergonomic, poorly designed and unHaskelly.

Again I’m saying this not to try to reverse those proposals, but to counter the attitude that DT has ‘won’ or has persuaded everybody. What’s worse, DT seems to be the only part of GHC that’s getting any attention (as opposed to, say, providing a records system even as not-totally-embarrassing as purescript‘s). So I see no downside in stopping at GHC 8.10.

[lierdakil]

I see no reason for insisting it be the first arg following the function; whereas @… or a visibly dependent type arg must come first

This is simply not true, consider for instance:

f :: Int -> Int -> forall a. Num a => a
f x y = fromIntegral $ x + y

summ = f 2 3 @Double

Yes, this uses RankNTypes. But the point is, the hard requirement is only that type arguments precede the value arguments that reference them, and to me that seems very reasonable.

[AntC2]

@lierdakil

to me that seems very reasonable.

(It was more VDQ I had in mind, but @int-index said much the same in discussing that proposal.)

So those who like that sort of thing will find that is the sort of thing they like.

I’ll explain my “un-Haskellish”:

• Haskell used to work like lambda-calculus: I can partially apply functions; I can flip arguments; I can define a version of a function with arguments rearranged;
• Type inference used to mean that if a tyvar appeared in multiple places in a signature, unification from terms (including those with a type annotation) would resolve to a single type, without me having to worry about order of appearance.
• Do I have a use-case where I’d prefer the type pseudo-argument after the term? Yes: consider a function with an argument that’s a collection. Usually the collection is non-empty, so the compiler can get the element type from there — then the pseudo-argument can be a dummy. But just in case it’s empty, I want to be able to supply the element type explicitly — in a way that looks more like a type annotation. Using @… — even suffixed as you show — is not a required argument.

I’ll be told that if I don’t want VDQ and friends, I can leave the extension switched off, and my Haskell intuitions still stand. That’s what I’m doing: leave all v9 extensions switched off by sticking at 8.10.