Proposal: Add &&& and *** to Data.Tuple
lemming at henning-thielemann.de
Thu Sep 20 13:01:09 EDT 2007
On Thu, 20 Sep 2007, Jon Fairbairn wrote:
> Henning Thielemann <lemming at henning-thielemann.de> writes:
>> On Mon, 17 Sep 2007, Jon Fairbairn wrote:
>>> instance Arrow (->) where
>>> (***) = (Data.Tuple.***)
>>> (&&&) = (Data.Tuple.&&&)
>>> and modules that imported only Arrow (not Tuple) would see
>>> no difference from the present state of affairs. Where
>>> things would be different would be if a module imported both
>>> Tuple and Arrow, when, instead of a name clash, *** and &&&
>>> would get their Arrow meanings (albeit with a specialised
>>> instance for ->).
>> If you import Tuple and Arrow, why not just import Arrow?
> Presumably because there are functions in Tuple that aren't
> in Arrow (if that isn't the case, this just means that
> Tuple/Arrow isn't a very good example).
I would certainly import Arrow unqualified, and Tuple qualified. Or I
would import the infix operators of Tuple, that do not interfer with
Arrow, explicitly but unqualified. I think many problems arise from a
dislike against both qualified and explicit imports. In the Modula
languages only the latter two options exists and it works.
Actually, one of my points is that specialised functions even shall have
special names in order to signal to the reader which concrete data type is
processed. I think most people agree, that infix operators shall be used
unqualified. Since unqualified usage means automatic resolution of the
particular implementation, they are predestinated for class methods. That
is, (+) is polymorphic and this is fine, and (++) should also be
polymorphic, maybe replacing 'mplus'. The specialised functions should
have alphanumeric identifiers, say List.append, Int.add. Whenever I read
in a program
List.map (Int.add 1) (List.append a b)
I'm confident, that a and b are lists, not just any possible monads, and
that the lists contain Ints.
More information about the Libraries