Re: [stack] Parameters: ordered versus named

On Sep 8, 2007, at 19:18 , William Tanksley, Jr wrote:

> Don Groves <[email protected]> wrote:
>> William Tanksley, Jr wrote:
>>> Don Groves <[email protected]> wrote:
>>>> The price we pay for the
>>>> simplicity of
>>>> concatenative syntax is the amount of parameter checking we must
>>>> do at run-time which other languages to at compile-time.
>
>>> Not true. Concatenative semantics don't require parameter  
>>> passing, so
>>> there is nothing to do to parameters at runtime. There are, of  
>>> course,
>>> other prices we must pay; but that's not one of them.
>
>> While it's true there's nothing to do "to" parameters, we still must
>> check for
>> their existence, yes? If you want to trap stack underflow before it
>> happens,
>> for example. And what do we do when a user enters a string and a  
>> number
>> then types "/"?
>
> If you want to stop it before it happens, you're going to do static
> analysis. That can be done in a concatenative language using a
> linear-time algorithm plus some annotations (and provide typechecking
> as a bonus), or it can be done using type inference (using the same
> algorithms that many modern functional languages use). StrongForth
> uses the former; Cat uses the latter

Just before falling asleep last night, it hit me what has caused my  
confusion
about all this: I've been thinking of the interactive user, not  
running an already
compiled program. Of course, when a program has been fed through the
interpreter without errors, stack- and type checking is no longer  
necessary.
Thanks for you help!


>>>> One beauty of concatenative notation is the hiding of information
>>>> such as described here,
>
>>> Nothing's hidden.
>
>>>> but we all know that hidden info must be dealt with
>>>> eventually,
>>>> unless the language is so primitive as to not care about these
>>>> matters.
>
>>> But this is true. (Well, mostly -- Cat does type inferencing so you
>>> don't always have to describe the types, while Enchilada defines its
>>> semantics so that all its types are compatible.)
>
>> Afraid I'm confused here. You say nothing is hidden, yet you agree  
>> (at
>> least partially) with my next statement.
>
> 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).

Agreed!
--
Don