[Pyrex] Too much overloading? And other stuff

[Michael JasonSmith]

On Tue, 2003-05-20 at 01:25, Edward C. Jones wrote:
> One of the things in Pyrex that causes confusion for me is the four
>  different meanings of "=".
[snip]
> There is a C assignment, a Python assignment and two conversions.
[snip]
> My conclusion is that "things that are different should look
> different".

\begin{diatribe} % I'm in a LaTeX mood today.
Most of language design comes down to taste.  There are pragmatics
involved, but most of the design is because people like it that way. 
For example, Wirth likes strongly typed languages (probably), so Pascal,
Modula-2, and Oberon are strongly typed; a conscious decision was made
to swap the flexibility you get in languages like Smalltalk for the
safety of compile-time type-checking.  Some languages perform type
inference (Haskell, Mondrian); others only have one type (Tcl, BCPL);
and others have not types [almost] (Smalltalk, Self).  Likewise, some
languages have almost no operator overloading (Pascal\ldots, C Java);
others have operator overloading (Python, C++); finally, other languages
think operator overloading is [insert expletive here] and real languages
should implement parametric-polymorphism (Haskell).

My taste in language design means that I cannot agree with the "things
that are different should look different" sentiment.  Thankfully, few
languages implement this, C included.  Consider, this snippet of C code
{
  float f = 9.5;
  double d = 0.0;
  int i = 7;

  d = f + i;
}
How annoying would it be if you could not use "+" to add a float to an
int.  Likewise, it would be annoying if you had to use a cast to assign
a float to a double.  (As a past user of Modula-2, I can assure you that
this sort of strictness is *very* annoying.)  If you want another
example, consider the "+" operator in Java.  Normally Java considers
operator overloading bad, but in the case of "+" they made an exception
and allowed it to concatenate strings, as well as add numbers.

In my opinion operator overloading is good when it does "the right
thing".  It is the skill of the designer to ensure that this happens.
\end{diatribe}

> Today I Google searched for "programming language design philosophies". 
> I found "Seven Deadly Sins if Introductory Programming Language Design" 
> by Linda McIver and Damian Conway. The URL is 
> "http://www.csse.monash.edu.au/~damian/papers/PDF/SevenDeadlySins.pdf". 
> They call this problem "syntactic homonyms".
Cry "havoc", and let the PDF war begin!

Notes on Postmodern Programming:
    http://makeashorterlink.com/?S32C620A4 [www.mcs.vuw.ac.nz, PDF]

> I suggest that Pyrex be strongly typed. In Python I never make 
> mistakes because of the dynamic typing.
I wish I could say the same.  I personally leave out "()" from the end
of method calls, so I get
    TypeError: unsupported operand types for +: 'instance method' and 
    'int'
Not the easiest error message to explain to a seven year-old :)

> But when C is around, it might be better to consistently use C's 
> strong typing.
C is not "strongly typed".  Observe the use of integer values as
pointers, the ability to add a float and an int, the ability to add an
unsigned int to an int (curse you Modula!) and the ability to cast
anything to anything.

Besides the semantic argument, I disagree that Pyrex should *enforce*
typing.  There are times that I wish I could explicitly declare types
and explicitly cast, but for the most part I want Pyrex to do "the right
thing" so I can get on with creating code and not worry about low-level
things, such as how numbers are internally represented.  Maybe a
compromise can be reached, with optional casts and declarations?

-- 
Michael JasonSmith      http://www.cosc.canterbury.ac.nz/~mpj17/