[ghc-steering-committee] A plea for ForeignFunctionInterface

[Simon Marlow]

On Fri, 18 Dec 2020 at 16:44, Eric Seidel <eric at seidel.io> wrote:

>
> 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

>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201231/6a555688/attachment.html>