[Haskell-cafe] Re: A better syntax for qualified operators?

[Brian Hulley]

Benjamin Franksen wrote:
> Brian Hulley wrote:
>>         ith = Data.Array.IArray.(!)
>
> Sorry, but I can't see the problem here. Why can't the editor offer
> the operator as '!' in the list of options, and if the user selects
> it insert both '(' and ')' at the right places (i.e. before the
> module name and after the operator)? Is there some unwritten law that
> forbids editors or IDEs to insert stuff at positions other than the
> current cursor position?

I hadn't thought of that - I've now decided to just use the existing syntax 
here.

>
> Generally speaking, I would always hesitate to change the language so
> it better suits programming tools(*). It is the tools which should
> adapt to the language, even if that means the programmer has to find
> new ways of suporting the user (and the language). The most important
> reason being that code is more often read than written.

My motivation for the change was that it would better suit the human user of 
the programming tool, though in this particular instance you and Henning 
have convinced me that the original syntax was better after all.

>
> At the danger of becoming completely off-topic now (sorry!), I have
> to say that I find /both/ versions ugly and unnecessarily hard to
> read. My personal solution is to generally avoid qualified imports.

How does this solution scale? Surely it's only lucky if people happen to 
choose names that don't clash with those of other modules?

> I use it only if absolutely necessary to disambiguate some symbol, and
> then just for that symbol. I am aware that there is an opposing
> faction here, who tries to convinve everyone that qualified import
> should be the standard (and the actual exported symbols --at least
> some of them-- meaningless, such as 'C' or 'T').

Although C and T are in themselves meaningless, the name of the module 
itself is not. As I understand it, this convention makes the module name 
carry the meaning so you use Set.T instead of Set.Set where the meaning is 
duplicated (a rather uneasy situation) in both the module name and type 
name.

> I think such a
> convention is inappropriate for a functional language (especially one
> with user defined operators). There simply is no natural 1:1
> correspondence between data type declaration and functions acting on
> that data built into the language, as opposed to e.g. OO languages.
> Extensibility in the functional dimension, i.e. the ability to
> arbitrarily add functions that operate on some data without having to
> change the code (module) that defines the data, is one of the
> hallmarks of functional programming, as opposed to OO
> programming.

If you have an abstract data type then it *is* like an object (though in a 
potentially more powerful way than in OOP) because there is no other way to 
manipulate values of that type.
If the type is not abstract, the advantage of calling it T is just that it 
avoids naming it twice (by type name and module name) in the situation where 
you want to not worry about name clashes with constructors of other types.

> However, nothing prevents us from offering two
> interfaces (visible modules), one where the data type is abstract ("client
> interface") and a different one where it is concrete ("extension
> interface")

You can still call both types T... :-)

Regards, Brian.
-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com