[Nickle] Type flipping or PP flipping bug

[Keith Packard]

Around 14 o'clock on May 13, Bart Massey wrote:

>    > typedef (string[*])(string) bar;
>    > print bar
>    typedef string(string)[*] bar;
>
> Probably an easy fix.

It's "correct", at least as far as our understanding of the language...

Remember what problem we were trying to fix -- to get the type declaration 
and the variable usage in the same order.

Consider:

	int[string][...] x;

Is that an array of hashes or a hash of arrays?  Well, we want the
following to work:

	x["hello"] = (int[...]) {};
	x["hello"][0] = 12;

Any other ordering would be insane.  Now, stir in functions to the mix.  
Again, the current syntax allows for:

	int(string)[*] bar;	/* string function returning array of int */

You get a single int out of this with:

	bar("hello")[0];

In other words, the order of subscripts within the type matches the order 
of subscripts within the expression.  In this case, it's more than a 
little confusing.  So, we fix it with parenthesis:

	(int[*])(string) bar;

This makes a lot more sense if we're actually planning on keeping the
whole array around:

	int[*]	x = bar("hello");

To summerize: subscripts read from the left to the right:

	int(string)(real)[*][bool] q;

q is a function from string to function from real to array of hash from 
bool to int.  It's used like:

	q("hello")(8.5)[9][false]

The "real" fix here would be to move the base type from the left to the 
right:

	(string)(real)[*][bool]int q;

Now the whole type reads from left to right.  But, I suggest we stick with 
our near-C syntax and accept that mixtures of functions and arrays will 
often require parens to get the types to look reasonable.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
Url : /pipermail/nickle/attachments/20040521/507be426/attachment.pgp