[Haskell-cafe] Syntax extension - adding import support to let/where bindings
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
So, something like this:
let qualified Prelude
in head $ ...
This makes it clearer that what's going on is renaming rather than
importing, and avoids implicit name shadowing.
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:
>> let open List in ...
>> They even have a weird concise version of the syntax:
>> 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.
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Haskell-Cafe