[ghc-steering-committee] A plea for ForeignFunctionInterface

Fri Dec 18 03:43:01 UTC 2020

In my experience, FFI is the kind of extension that you want to
isolate to a single module, and like Cale (or Iavor with the fancier
type system extensions) I like the indicator at the top of the file
that this module will be dealing with FFI concerns. In that sense,
FFI feels a lot like MagicHash to me, a very important and useful
extension, but one that you don't want (or at least don't *need*)
enabled everywhere. So it's interesting to me that while FFI has
8 votes now, MagicHash (and UnboxedTuples and UnboxedSums) only
has a single vote.

I don't see excluding FFI from GHC2021 as an argument that it should
be avoided or deprecated, just that it's not a part of the every day
Haskell toolkit. I think it deserves to continue to be part of the
Haskell standard, but is also niche enough to warrant selective
enablement where it's needed. In other words, I think it would be
perfectly fine if the Haskell standard mandated FFI as an extension
that could be enabled on demand (in fact this is how I thought it
worked when I first learned that FFI was included in Haskell2010).

That all said, there's clearly nothing wrong with enabling it
universally, it's been the default for a while and hasn't caused
any problems I'm aware of. So if Simon M and others feel strongly
about including FFI, I don't want to stand in the way. But I am
curious why we shouldn't include the other parts of the low-level
Haskell toolkit as well.

Eric

> On Dec 17, 2020, at 11:47, Cale Gibbard <cgibbard at gmail.com> wrote:
> 
> My impression of the GHC2021 thing was that it's an arbitrary
> collection of extensions that would make for a sensible default,
> rather than something that was in any way tied to a standardisation
> process.
> 
> ForeignFunctionInterface is obviously not going anywhere, but also,
> its use is generally confined to particular modules, where the {-#
> Language ForeignFunctionInterface #-} pragma at the top would be good
> documentation for what sort of module we're about to see. I was also
> slightly concerned that switching that on may have an impact on
> overall compiler performance, seeing as it may need to interact with
> the driver in more ways than most extensions, but I don't really know
> and haven't yet done any testing.
> 
> I also had no idea it was turned on by default in Haskell2010, though
> I'm not sure it matters all that much what was turned on in
> Haskell2010 for these purposes either?
> 
> That said, I could go either way on this one.
> 
> If we're going to turn FFI on, why not throw in all the other
> extensions to FFI? Given that they introduce their own bits of syntax,
> so could hardly affect anything by accident, I think it would be
> appropriate.
> 
> 
> 
> On Thu, 17 Dec 2020 at 11:40, Simon Marlow <marlowsd at gmail.com> wrote:
>> 
>> Dear Committee
>> 
>> We're in danger of actually *removing* an extension from the default set of extensions that is enabled in GHC, which is not what I understood GHC2021 was all about. And it's not because anyone (at least as far as I know) actually thinks that ForeignFunctionInterface is a bad idea and should be deprecated or replaced. What other reasons could there be for turning off an extension that has been on by default for so many years?
>> 
>> ForeignFunctionInterface is part of Haskell2010. Are we saying we disagree with the decision to make it a part of the language standard?  I hope not!
>> 
>> Please let's think very hard before doing this!
>> 
>> Cheers
>> Simon
>> 
>> On Mon, 14 Dec 2020 at 22:22, Joachim Breitner <mail at joachim-breitner.de> wrote:
>>> 
>>> Dear Committe,
>>> 
>>> three weeks in, we have all votes. So now things are looking more concrete.
>>> 
>>> As always, the table
>>> https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data
>>> has the current data.
>>> 
>>> Would it be helpful to add columns to that table for each committee
>>> member? So that you can quickly see who voted what?
>>> 
>>> The following in are safely in (= need more than one vote to change to get out):
>>> 
>>> BangPatterns, BinaryLiterals, ConstrainedClassMethods, ConstraintKinds,
>>> DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric,
>>> DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls,
>>> EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances,
>>> GADTSyntax, GeneralisedNewtypeDeriving, HexFloatLiterals,
>>> ImportQualifiedPost, InstanceSigs, KindSignatures,
>>> MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds,
>>> PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType,
>>> TypeApplications, TypeSynonymInstances
>>> 
>>> The following are barely in (exactly 8 votes in favor, and 3 against):
>>> 
>>> ExistentialQuantification, NamedWildCards, StandaloneKindSignatures,
>>> TypeOperators
>>> 
>>> The following are short one vote (7 in favor, 4 against):
>>> 
>>> DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds,
>>> NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections,
>>> TypeFamilies
>>> 
>>> 
>>> I am sure we can have plenty of discussion for each of these. Probably
>>> without end. As Simon says, mailing lists don't scale. So I think we
>>> have two choices:
>>> 
>>> 1. Let the numbers decide, and accept whatever comes out. According to
>>> the process (which we should only follow if we find it helpful) we’d
>>> maybe update our votes, and maybe point out new facets, for one week,
>>> and then just take whatever has 8 votes.
>>> 
>>> or
>>> 
>>> 2. Explore a more efficient discussion format.
>>> 
>>> For the latter I mentioned kialo.com before, and maybe it is worth a
>>> try, so I set up a discussion there:
>>> https://www.kialo.com/which-haskell-extensions-should-go-into-ghc2021-43548?path=43548.0
>>> 
>>> So what do you see there?
>>> 
>>> There is a discussion tree:
>>> 
>>> The root is “what goes in GHC2021”
>>> 
>>> The next layer are all extensions with 7 or 8 votes.
>>> (I assume we should focus on those initially, but feel free to add
>>> more or ask me to.)
>>> For example:  TupleSections
>>> 
>>> And then each of these has a column where we can collect Pros and cons.
>>> For example:
>>> Pro: Opt-in Syntax
>>> Con: Possible clash with extra-comma syntax extensions.
>>> 
>>> So you can treat it like a wiki, but with structure to organize the
>>> discussion.
>>> 
>>> In fact, each pro and con is itself a node where you can add supporting
>>> and disagreeing comments. This means that if you _disagree_ that
>>> TupleSections are actually Opt-in syntax, there is a dedicated place to
>>> raise that point, rather than putting “Not actually opt-in” in the Con
>>> column of TupleSections…
>>> 
>>> A good way to navigate the discussion seems to be the radial icon in
>>> the top left; it opens a radial view of the whole discussion, and you
>>> can read arguments by hovering.
>>> 
>>> 
>>> The site doesn't offer voting, it is only about structuring the
>>> discussion, and it is designed for much larger and much more
>>> contentious debates (e.g. “Brexit”). So we’ll see how well it works for
>>> us and if it’s helpful.
>>> 
>>> Cheers,
>>> Joachim
>>> 
>>> 
>>> --
>>> Joachim Breitner
>>>  mail at joachim-breitner.de
>>>  http://www.joachim-breitner.de/
>>> 
>>> 
>>> _______________________________________________
>>> ghc-steering-committee mailing list
>>> ghc-steering-committee at haskell.org
>>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>> 
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee