[ghc-steering-committee] Status

[Iavor Diatchki]

On Tue, Mar 9, 2021 at 8:11 PM Richard Eisenberg <rae at richarde.dev> wrote:

>
>
> On Mar 9, 2021, at 3:34 PM, Iavor Diatchki <iavor.diatchki at gmail.com>
> wrote:
>
> Well, it sounds like you are saying that to use FFI one would have to buy
> into DH design.  My concern is not about what pragmas the users have to
> write---after all we could make them write no pragams whatsoever.  It is
> about what users would have to understand. For example, why does it matter
> that there is no data constructor `Bool` in scope?   I am passing a type to
> `sizeOf`, why would GHC all of a sudden get confused between the type and
> the value?
>
>
> Just as much as users of arithmetic have to buy into a design using
> type-classes. That is, we're aiming to design a cohesive language, and that
> means that someone trying to understand the design of the language (i.e.
> our FFI user) will have to consider it holistically.
>

I don't see how type-classes are related to the current point. Yes, we want
to consider a cohesive language design, but this doesn't mean that
everything has to depend on everything.  The nice benefit of the extension
system is that it allows us to experiment with language changes modularly.
As I see it, here we have a choice between:
   A. a modular opt-int design that is close to what is already used by a
lot of a projects (i.e., something like `sizeOf @Bool`), and
   B. an alternative design (i..e, `sizeOf Bool`) that depends on an
unrelated feature (dependent types), that we have zero experience with, and
require major changes to how something as basic as name resolution works.

It sounds like #378 is asking us to always make choice B.   I think a
better plan is to prefer option A, as we have been for a long time now.  I
don't think that precludes the work on dependent types in any way
(ergonomic or not, whatever that means).  Once that work is done, it might
subsume some existing extensions, and folks would have a choice to write
things one way or another depending on their needs.  I expect in the long
run, one of the designs might become the common way to do stuff, and
eventually we might depreciate some of the extensions that are not used any
more.     To me, this seems to be the right way to grow a living language
like Haskell.


As for confusion between types and values: this is the heart of the matter.
> I agree that, taking #281 alone, it would make more sense to say sizeOf
> @Bool. But in the context of a design that might support dependent types,
> it makes more sense to say sizeOf Bool, and have name lookup try both
> namespaces (the data constructor namespace first, followed by the type
> namespace). This is why I wrote #378, so that we could decide which design
> is better for #281.
>

I don't see how `sizeOf Bool` makes more sense than `sizeOf @Bool` in a
language with dependent types, this seems purely a matter of taste.  As I
mentioned before, I find `sizeOf @Bool` more readable than `sizeOf Bool`
exactly because I don't need to keep in my head yet another thing (i.e.,
which `Bool` are we talking about here).  By the way, in case the `Bool`
example seems absurd, using `newtype`s is quite common when doing FFI
bindings, and the normal pattern there is to use the same name for the
value and type constructor, so this is something that we should not gloss
over lightly.

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