Re: [stack] Parameters: ordered versus named

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

> On 9/8/07, Don Groves <[email protected]> wrote:
>> 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
>
> This is an example of a runtime checked language, also called a
> dynamically typed language, though some theorists object to the term
> dynamic typing. Personally I have no qualms with it.
>
> -D


OK, that's what I thought it was. It seems dynamic typing means two
things: (1) run-time type checking; and (2) data is typed --  
variables are
not. Clearly (1) allows (2) but (2) is not required. Is this part of  
the source
of disagreement over the name?
--
Don