Import / Export

[john peterson <peterson-john@cs.yale.edu>]

Original-Via: uk.ac.nsf; Thu, 6 Sep 90 17:08:59 BST
Date: Thu, 6 Sep 90 11:48:25 EDT
From: john peterson <peterson-john@cs.yale.edu>
To: Haskell@cs.yale.edu
Subject: Import / Export
Sender: haskell-request@cs.glasgow.ac.uk

Now that I've finished wallowing in the import / export code, I'll
throw out some suggestions for the committee to consider.

The problem with the (..) in the presence of multiple names is the
most serious.  Although Simon suggests disallowing this in an export
spec when multiple names exist, it was just as easy to implement this
exporting all names for a constructor.  I feel this is more intuitive
and avoids yet another restriction in the language.  Note that using
(..) on an import also has the same problem: if C and C' are two names
for the same constructor, exporting both T(C) and T(C') should be
legal and importing T(..) should bring in both C and C'.  The only
alternative is to eliminate (..) on both import and export lists when a
constructor has multiple names, but this seems overly restrictive.

The `hiding' construct could use additional explanation.  When hiding
an algdata (or class) with named constituants, as in "hiding (T(C))",
this also suppresses any other renamings of C.  Every hiding is thus
identical to the (..) form.

Syntax allowing multiple modules for a import would be nice and should
present no problems.  Something like "import Mod1,Mod2".

No mention of error conditions is made in the report.  We should
standardize the behavior for situations where a named import is not
found or a hidden import was not not defined.  I suggest adding
something along the lines of "It is an error to refer to a
non-existent entity in any part of an import or export declaration."


That's all for now.  If the Haskell language can be considered a
temple for the worshipers of functional programming, then this import
/ export stuff is definitely the sewer underneath it!


           John