[Haskell-cafe] Syntax extension - adding import support to let/where bindings

[Oliver Charles]

On Wed, Aug 5, 2015 at 3:38 PM <amindfv at gmail.com> wrote:

> A couple syntactic concerns (assuming there's a sane semantics with eg
> typeclass instances):
>
>  - This seems essentially like name shadowing, which is a source of
> confusion and therefore bugs (-Wall warns about it)
>

It would be the same as normal name resolution. For example, right now you
can do

foo = id True
  where id a = a

foo.hs:2:9: Warning:
    This binding for ‘id’ shadows the existing binding
      imported from ‘Prelude’ at foo.hs:1:1
      (and originally defined in ‘GHC.Base’)

Prelude.id was introduced in a higher scope, so the definition shadows it.

If you do this

foo = id True
  where import Prelude (id)
        id a = a

Then that should fail with "Ambiguous occurrence 'id'".

If importing would shadow a top-level definition, then that should probably
trigger a warning. E.g.,

import Prelude hiding (id)

id a = a

foo = id True
  where import Prelude (id)

Would warn that the import shadows the top-level definition of id (which is
the same behavior as if you declared another id in the where clauses for
foo).


>  - This makes me unable to see what a module imports by looking at the
> import statements at the top of a file
>

Correct. But it does not make it impossible for a tool to determine what
imports are available. This is also proposed as an extension, so of course
if you don't want to use it, you wouldn't have to.


>  - It seems like using "H.width" and "C.width" isn't very costly
>

In practice I use a lot more than just two symbols. The point is the
repeated qualification quickly introduces more noise and obscures the
intent of the code. It also introduces a disconnect in the code - where did
H come from? Time to jump all the way to the top of the file to find out.
Of course, under my proposal it *could* be even harder to find out where H
came from, but that is a decision that the (code) author decided on - and
there are already many ways we *could* make Haskell unreadable.

*ocharles*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150805/924b31a4/attachment.html>