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

Oliver Charles ollie at ocharles.org.uk
Wed Aug 5 20:24:37 UTC 2015

On Wed, Aug 5, 2015 at 7:12 PM Tikhon Jelvis <tikhon at jelv.is> wrote:

> If you want a direct experience report, I've written a fair amount of
> OCaml which supports pretty much exactly this feature[1]:
>     let open List in ...
> They even have a weird concise version of the syntax:
>     List.(...)
> This is quite useful in practice, and doesn't seem to cause any problems.
> However, OCaml has different norms around external modules, so it might not
> translate to Haskell the same way.
> In OCaml, every module is automatically imported qualified. There's no
> list of import statements at the top. Importing ("opening") a module is
> equivalent to an *unqualified* import in Haskell and happens rarely.
> Moreover, it can appear in any part of the file. In practice this doesn't
> seem to be a problem, but that could be because nobody's depending on
> having all the imports conveniently declared up-front. Personally, I think
> this trade-off is perfectly acceptable: I'd rather have life be better for
> programmers and worse for tools than vice-versa.
> OCaml also doesn't have typeclasses or the open world assumption which
> would lead to confusing behavior one way or another.

Thanks for providing another perspective! It's good to hear other languages
are successfully employing this idea.

With all that in mind, OCaml's feature feels closer to Elliot's suggestion:
> it's more about locally *dequalifying* a module than importing it. Doing
> just that also fits better with Haskell's current import and typeclass
> system. However, I'm not sure how to design a local dequalifying statement
> in a way that's not confusing.

Indeed, having import stay at the top level to always bring type class
instances in followed by the option of "opening" an import later is
certainly more elegant and less hacky than what I'm proposing. I think this
route will have to require a new keyword though, but we can establish those
details later. I'm leaning more towards this idea now. Let's see what
others think.

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

More information about the Haskell-Cafe mailing list