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

[Alejandro Serrano Mena]

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>)
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>) 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
>>
>> 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
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20200601/b3106c8f/attachment.html>