[Pyrex] Too much overloading? And other stuff

[Greg Ewing]

"Edward C. Jones" <edcjones at erols.com> wrote:

> One of the things in Pyrex 
> that causes confusion for me is the four different meanings of "=".

That's rather a strange way of looking at it. A more helpful way would
be that there is only one meaning of assignment, but that various
automatic conversions are performed so as to make the thing being
assigned compatible with the thing being assigned to.

> Why were the C "*" (*p is the thing p is pointing at) 
> and "->" operators eliminated?

The '->' operator seems redundant to me, even in C, and even more so
in Pyrex. The design philosophy of Pyrex is that the syntax is
basically Python syntax, with as few extensions as possible to enable
dealing with C data types. The '->' operator is not needed to achieve
this, so it's not included.

I'll concede that the workaround for the lack of unary '*' is a bit
strained, but if I included '*' as a unary operator it would conflict
with the Python usage of '*' in argument lists. Rather than make up
a new operator, I chose to recommend using something else that is
already legal syntax and has the same effect.

> My conclusion is that "things that are different should look different".

I do agree that it can be tricky at times keeping track of which
things are Python objects and which aren't, perhaps trickier than I
had anticipated when I started working on Pyrex.

Perhaps it would have been better to start out with a clearer division
between Python things and C things, but it's hard to see how that
could have been achieved consistently without making the language very
unwieldy. Python and C already share a lot of syntax for things like
assignment, arithmetic, array indexing and procedure calling. To make
a syntactic distinction between all of those I would have had to
invent a lot of new syntax that was neither Python nor C, and I doubt
anyone would have thanked me for making them learn it.

> I suggest that Pyrex be strongly typed.

If you mean statically typed, it already is -- it's just that one of
the static types available is "Python object".

If you mean that there should be less automatic conversions, I'm far
from convinced. One of the design goals of Pyrex is that you should be
able to intermix Python and C values whenever it's obvious what should
be done. You shouldn't have to care about the distinction until you're
concerned with efficiency.

It might be useful to be able to explicitly convert when you want to,
but it shouldn't be required.

> Here is a C macro that is difficult to wrap with Pyrex:
> One of the macro variables is a type. It is feasible to eventually 
> include some sort of C++ style templates in Pyrex?

I can't see it happening any time soon. It would add a huge amount of
complexity to a program that is already straining my ability to keep
track of its workings. I hesitate to rule it out completely, but I
wouldn't hold my breath.

I agree that C macros of that sort are an extreme nuisance, but I
can't see any reasonable solution yet. They just go to show that
Macros Are Evil. :-)

> Buglet: Line 1980 of ExprNodes.py is
> 
>    error(self.pos, "Cannot take sizeof incomplete type '%s'" % arg_code)
> 
> The "arg_code" probably should be "arg_type".

You may be right, but I'm fairly sure I've tested that and it prints
the right thing -- probably because arg_code contains the C code for
the type at that point.  Anyway, I'll check it out, thanks.

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg at cosc.canterbury.ac.nz	   +--------------------------------------+