[ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules

Tue Jun 2 11:12:55 UTC 2020

I have commented on the main thread, since I have technical questions.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 01 June 2020 19:37
To: Iavor Diatchki <iavor.diatchki at gmail.com>
Cc: ghc-steering-committee <ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] Please review #270: Extend Term-Level Lookup rules

Hi again,
My first message was quite short, and I guess I should explain my rejection a bit further.
Although I am aware that sometime changes can only be made "in bulk", I think that this proposal in particular changes too many things core to the language.
- I am surprised by the complicated way to introduce that "~" and "[]" are built-in to the language, by means of a new "Data.BuiltinTypes" which is always in scope, unless you disable with another extension. I would be very happy to have those are wired-in types in the language, which cannot be overriden.
- The use of ticks in TH have served us well. I think we should not go as far as removing that until we see whether this disambiguation strategy works on simpler cases.

Thereis one thing I like *a lot* from this proposal: the ability to import types and terms under different qualifiers. I could well imagine myself replacing the common

> import Data.ByteString (ByteString)
> import qualified Data.ByteString as B

with

> import Data.ByteString type
> import qualified Data.ByteString as B

To be honest, I was not aware that GHC had 5 different ways to disambiguate the namespace (thanks Richard for the informative message!). In my mind, I've always had sort of the following intuition:
- ' promotes from term to type level, @ demotes (?) from type level to term level *in expressions*
- except in TH, where you need ' to quote a term and '' to quote a type

Regards,
Alejandro

El lun., 1 jun. 2020 a las 19:10, Alejandro Serrano Mena (<trupill at gmail.com<mailto:trupill at gmail.com>>) escribió:
Hi,
My first reaction is also to reject this proposal. I feel it is too invasive.

Regards,
Alejandro

El lun., 1 jun. 2020 a las 18:40, Iavor Diatchki (<iavor.diatchki at gmail.com<mailto:iavor.diatchki at gmail.com>>) escribió:
Hello,

I am the shepherd for proposal #270, and it is time for the committee to review the proposal.  The discussion and the proposal are available here:
https://github.com/ghc-proposals/ghc-proposals/pull/270<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F270&data=02%7C01%7Csimonpj%40microsoft.com%7C28000a66a2fa4bc6d67a08d8065ae201%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637266334693491780&sdata=wKWyyTiEHcFv4XaMW67bQwiCSYp47HYxwfjJtw3W8%2B8%3D&reserved=0>

Here is my summary of the proposal:

The proposal aims to solve the "namespace problem" which appears to largely be related to fact that Haskell has two namespaces, and so types and values may have the same name.

Proposed changes:
   1. Change the scoping rules for the language so that type names are in scope at the value level, but values always shadow types.
   2. Add a new form of import, which can import only the names from a particular names space
   3. Change the way built-in syntax for tuples and lists works and deprecated ' and '' from DataKinds and TH respectively.   This is a bit elaborate, have a look in the proposal for details
   4. Add a bunch of warnings that would trigger if you wrote code that made use of Haskell's different name spaces

My recommendation is that the proposal is rejected, as I don't think that these changes would help Haskell programmers, at least based on the way I use Haskell.  In particular, here are my thoughts on each of the above bullets:

   1. This is mostly about passing type arguments to functions---I would prefer a notation that is more explicit about the fact that we are passing in a type, and not just a normal argument.

   2. When I group things into modules, it is usually because they are intended to be used together.  I think I would rarely want to import only the types or only the values in a module, so I imagine it would be much more common to have to write two imports.

   3. This is quite an intrusive change, that is likely to break code.  I am also not keen to have to use type families, every time I want to use a tuple.

   4. Using the same name for a data constructor and a type is very common in Haskell.  I find it particularly useful when defining records.  I don't need warnings to let me know that I've done it, as it is highly unlikely that I did it on accident.

-Iavor

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=02%7C01%7Csimonpj%40microsoft.com%7C28000a66a2fa4bc6d67a08d8065ae201%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637266334693491780&sdata=QnLr9omXek5L9Cq5rFADTMvy9GStn6GlvEn11cDzGdM%3D&reserved=0>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200602/a9cd8ed8/attachment-0001.html>