Re: [stack] Parameters: ordered versus named

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.

> >> 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).

> Don Groves

-Billy