<div dir="ltr"><div dir="ltr">On Fri, 18 Dec 2020 at 16:44, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
I think LANGUAGE pragmas serve two separate purposes, which is the source of the confusion.<br>
<br>
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.<br>
<br>
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. <br>
<br>
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<br>
<br>
{-# LANGUAGE GHC2021 #-}<br>
{-# LANGUAGE FFI #-}<br>
{-# LANGUAGE UnboxedSums #-}<br>
{-# LANGUAGE UnboxedTuples #-}<br>
...<br>
<br>
we would write<br>
<br>
{-# LANGUAGE GHC2021 #-}<br>
{-# LANGUAGE LowLevelHaskell #-}<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div>Simon</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>