Re: [stack] Parameters: ordered versus named

On Sep 8, 2007, at 19:08 , Christopher Diggins wrote:

>> That's because concatenative languages, in general, don't hide
>> information; but I agree that if you do hide information, you have to
>> pay the price. I was also illustrating that the price to be paid
>> wasn't what you thought it was -- Cat pays the price not by being  
>> more
>> primitive, but by having a sophisticated static type inference system
>> (which can, of course, slow some things down, but is undeniably NOT
>> primitive and is a desirable feature for many purposes).
>
> A static type inference system certainly slows down compilation, but
> all things given equal should speed up runtime execution because it
> removes the need for runtime checks. Furthermore a static type
> inference system makes it easier to optimize code, because you can
> take advantage of properties that you have elucidated about the
> runtime behaviour. However, every implementation is different.
>
> A simple static type system has the disadvantage that typed terms will
> disallow unbalanced stacks. You can't say things like:
>
> if_tuesday [1] [1 2] ifte // does stack have one or two elements?
>
> - Christopher

Clearly, I need to learn more about type systems. Here's the Catenate
code implementing ifte, what kind of type system does this represent?


int ifte_() {	 // [f1] [f2] T|F ifte => (results of f1 if T)
		 //          		   => (results of f2 if F)
	if (depth < 3) {
		StackError("ifte", "underflow");
		return OK;
		}
	if (!islist(Y)) {
		printf("\nifte: Y must be a list\n");
		return UNKNOWN;
		}
	if (!islist(Z)) {
		printf("\nifte: Z must be a list\n");
		return UNKNOWN;
		}
	if (X == TRUE) {				// T|F = true?
		drop_(); drop_();			// (y) drop T and 'else' part (f2)
		id_();					//     execute 'then' part
		}
	else {					// (n) false
		drop_(); swap_(); drop_();	//     drop F and 'then' part (f1)
		id_();					//     execute 'else' part
		}
	return OK;
	}
--
Don