On Wed, Jul 05, 2006 at 01:03:01AM +0100, Brian Hulley wrote:
Simon Peyton-Jones wrote:
Concerning other mail on this subject, which has been v useful, I've revised the Wiki page (substantially) to take it into account. http://hackage.haskell.org/trac/ghc/wiki/GhcPackages
Further input (either by email or by adding material to the Wiki) would be welcome. (No guarantee Simon M agrees with what I've written... I'm at home this afternoon :-)
I think the following is a non-question:
An open question: if A.B.C is in the package being compiled, and in an exposed package, and you say import A.B.C, do you get an error ("ambiguous import"), or does the current package override.
because if the suggested syntax is used, import directives come in two flavours: ones that use "from" to import from a different package and ones that don't use "from" and therefore must refer to the current package.
FWIW this isn't what I actually intended when I was talking about using "from". I was imagining it would work similar to how "foo" unqualified can refer to either an imported variable or a variable in the current package, but we can still qualify "Foo.foo" should we wish to be explicit. So you can "import" from any package, including the current one, but qualify "from package import" should you wish to be explicit.
(modified to use quotes):
from "base"
I think I missed where the plan to use quotes came from. What's the purpose? Package names already have a well-defined syntax with no spaces or other confusing characters in them, so why do we need the quotes? Or is it just so we can have packages with the same name as keywords? (if so I think personally I'd prefer a slightly more context-sensitive grammar, not entirely unlike the as/qualified/hiding semi-keywords in import statements).
import Predude hiding(length) import Control.Exception import qualified Data.List as List
since otherwise it would soon become a bit of a pain to have to type 'from "base"' everywhere (esp if the package name was some long URL). It would also make it easier to quickly change to a different package without having to modify multiple import directives, which might be especially useful in the context of using a debug or release version of a package by putting C pre-processor directives around the "from" part.
There is a minor open question about the exact indentation rule for the above syntax since "base" is not a keyword and it would seem strange to desugar it into from {"base"; import ... } so it looks like it would need a special layout rule that would give a desugaring into from "base" {import ...}
It would only be slightly different to the current rules (it would be if the second lexeme after "from" was not '{', rather than the first), although now you mention it this would be an alternative possibility: from "base" import Prelude hiding (length) Control.Exception qualified Data.List as List where "import" behaves much like "of" as far as the layout rule is concerned. Thanks Ian