+1 on the idea. I wonder if full-blown “import” is overkill for the desired effect. Many languages simply allow you to de-qualify a namespace within a smaller scope. I’m thinking of C++ at the moment: { using namespace std; … } I think this would be preferable because it would still require that a module declare its “import dependencies” in a known place. I’m imagining chaos from large source files with several dozen import dependencies, but only a few of them defined in the “normal” place. That said, there is syntactical boon from re-using the “import” keyword. Yet I don’t think it’s a stretch to make inlined imports be constrained by the module’s imports. It’s a simple compiler error: “Foo cannot be imported inline because it is not imported by the module”. With or without the constraint, this would be an excellent feature. Elliot P.S. Now, about placing multiple modules in the same file…. From: Haskell-Cafe [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of Oliver Charles Sent: Wednesday, August 5, 2015 10:16 AM To: Moritz Kiefer; Haskell-cafe Cc: Haskell Cafe Subject: Re: [Haskell-cafe] Syntax extension - adding import support to let/where bindings On Wed, Aug 5, 2015 at 3:12 PM Moritz Kiefer mailto:moritz.kiefer@gmail.com> wrote: Am Mittwoch, 5. August 2015 14:59:54 UTC+2 schrieb Mike Ledger: This would be really handy to have. You could also have import "blocks", like import Foo in { ... } Where {...} is a new layout block, I guess. Is let not exactly this block feature? Indeed, in my post I use let bindings to achieve this: let import CSS in [ width (px 50) ] You could also add other local bindings to your scope: let import CSS sizeInPx = px 50 in [ width sizePx, height sizeInPx ] (Note that just like let the other bindings have access to the symbols that were imported) ocharles