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

Pavel Kogan pkogan at gmail.com
Thu Aug 6 11:30:59 UTC 2015


If taking this route, how about using unqualified as a keyword? This also
suggests an extension - using qualified to locally "close" a globally
unqualified import.

So, something like this:

html =
    let qualified Prelude
        unqualified HTML
    in head $ ...

This makes it clearer that what's going on is renaming rather than
importing, and avoids implicit name shadowing.

Pavel

On 5 August 2015 at 21:24, Oliver Charles <ollie at ocharles.org.uk> wrote:

> 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.
> <http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe>
>
> *ocharles*
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20150806/a88b06d8/attachment.html>


More information about the Haskell-Cafe mailing list