I think LANGUAGE pragmas serve two separate purposes, which is the source of the confusion.
1. They can guard new and experimental extensions that aren't ready for inclusion into a standard. This seems to be an uncontroversial use of LANGUAGE.
2. They can also act as a sort of language level in the style of Racket. This is the purpose of extension bundles like Haskell2010 and GHC2021.
I think when people say they like the LANGUAGE pragmas at the top of a module, they're referring to use case (2). To be fair, we have very few language extensions currently that act in this way, and FFI is not one of them. But what I think people really want when they make this argument is to have *more* category (2) extensions. So rather than writing
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE FFI #-}
{-# LANGUAGE UnboxedSums #-}
{-# LANGUAGE UnboxedTuples #-}
...
we would write
{-# LANGUAGE GHC2021 #-}
{-# LANGUAGE LowLevelHaskell #-}
where LowLevelHaskell implies a coherent set of extensions for dealing with low-level details, and also signifies (much better than the individual extensions) that we should adopt a different mindset when working in this module.
Hi Eric - thanks for the clarification. I'm not against category (2) in general, in fact I think having a LowLevelHaskell category that enables all the unboxed/unlifted-types-related extensions would be a good idea. However, I don't think such a category should include the FFI, because the FFI was designed to be cross-platform, implementation-independent, and to coexist smoothly with the rest of Haskell. I can't see any compelling reason to make it an optional extension.
I'm also not a fan of endorsing the idea of multiple languages. In my view we should be converging on a single language - every extension is destined to either be in a future GHC20xx or to be deprecated. That said, we do have quite a few notable exceptions currently, e.g. CPP, TemplateHaskell, PackageImports, Safe, and a few more. We could reasonably consider these to be special cases, though.
Cheers
Simon