Re: [OT] PostLisp, a language experiment

From: Ed Beroset (beroset_at_mindspring.com)
Date: 03/13/05 

Date: Sun, 13 Mar 2005 14:50:51 GMT

Duane Rettig wrote:
> "Elizabeth D Rather" <eratherXXX@forth.com> writes:
>
>
>>"Duane Rettig" <duane@franz.com> wrote in message
>>news:4ll8szw8p.fsf@franz.com...
>>>
>>>I count 4 characters in the first (or 5, if you include whitespace)
>>>and 7 in the second.
>>
>>So? Counting characters in the name is utterly unrelated to runtime
>>efficiency.
[...]
>>so that's maybe not the best example. But my point is that the length
>>of the name is really irrelevant to any discussion of efficiency. As
>>others have observed, in an embedded system the names might be
>>stripped anyway.
>
>
> Why are we still talking about runtime efficiency? I answered one
> article about that, and finished by saying that that was not what we
> were talking about.

The styles of the two languages are very different, and I think that's
where the confusion lies. For example, let's look at this exchange:

> For all of those who answered tangentially, I will
> not reply to each post, but let me say here once what my point is,
> based on my original conversation with John Doty:
>
> DR: ... the user stack will end up growing or shrinking incorrectly
> if there is a mismatch.
>
> JD: ... write short definitions ...
>
> DR: What if I wanted to write longer definitions?
>
> JD: Why, to make your code unreadable?
>
> Originally, my discussion with John Doty was based on stack
> mismatch issues, and nothing else. John's answer included a
> maxim to write short definitions. But I don't like that maxim,
> so I'm asking what I could do in Forth in order not to be
> bound by that rule.

If I may supply some of the subtext for the exchange from the Forth
point of view, it might be this: "If you are concerned about stack
mismatches, the way to avoid them in Forth is to use definitions which
don't have too many things on the stack." That's what "short
definitions" implies in this context. Your question about long
definitions is kind of strange from the Forther's view. It's as though
someone had claimed that language X was a way to write bug-free code and
you'd written, "but what if I wanted to write buggy code?" It's not
that the question doesn't make literal sense, but that it's not clear
why anyone would want to do that.

One presumption about why one MIGHT want to do that was to gain presumed
efficiency, hence the nature of the replies that you received.

> The responses I've received (as well as my
> experiences) lead me to conclude that if I want to write long
> definitions, I should not be using Forth. That's alright,
> though; I already have a language in which I can write long
> definitions without loss of cognitive simplicity.

So this leads me to ask, what advantage do you find in writing long
definitions? In other words, why would one want long definitions
instead of compounds of shorter ones? I find that I tend to use the
latter method in Lisp, and C and many other languages so that the code
is easier to understand and maintain; I haven't encountered a compelling
need to write long definitions.

> Correct. But there are times when a large function can indeed be used
> without any loss of readability. Table-based code is one such example;
> in Lisp a case statement might even span many pages, but to break it
> up would not necessarily increase the readability or any reusability.

My Lisp is extremely rusty, but it strikes me that a large case
statement would tend to have short, repetitive actions for each case.
That is, you wouldn't have extremely long actions for each case. Just
as in Forth, you'd break things up into named function.

>>As various of us have said, the length of the name(s) is irrelevant
>>except in source.
>
> We're talking precisely and only about source. Since there are
> apparently no runtime checks for stack mismatches, they are not caught
> or introduced at compile-time, but instead they become directly dependent
> on source only.

That's correct, and since they're in source only, this leads directly to
the maxim of keeping definitions short, with the understanding that the
relevant implication isn't the number of characters typed in but the
complexity and number of stack items for each definition.

> Yes, but even this gets away from my question about what to do with these
> pesky stack mismatches.

The obvious answer is "avoid them!" The other respondents have been
trying to give a more detailed and useful answer, but it boils down to
just that.

> It is one of the reasons why I did not stop
> looking for a better language, even after I had found Forth. At that
> time, I was awed by its simplicity and power, including its extensibility.
> Now, I work in a language that gives me all that, including stack
> safety, and other things as well.

As you may recall from looking at Forth, an extremely common idiom is to
have stack comments next to each word. Paul Bennett's earlier example:

> : SQUARED (S n -- n^2)
> (G n^2 is the resultant of the number n multiplied by itself. )
> ( Limitations: the number n can be no larger than the square )
> ( root of an n^2 which occupies all the bits of a cell).
> DUP * ;

As you will recall (but for the benefit of Lispers who might not know),
the stack comment is the (S n -- n^2) part and it indicates that one
number n is the input on the stack and one number n^2 is the output.
You might not know that although these are comment lines, Paul's use of
(S and (G in the line below are actually intended for machine
interpretation. In other words, a Forth program reads those comments
and can product documentation from them. I don't know if he uses such a
tool, but it would certainly be possible to chain stack comments
together to check for stack mismatches.

He probably doesn't have or use such a tool because the idiomatic use of
the stack is such a basic part of Forth. It would be like writing a
Lisp program to track the use of car and cdr and make sure that the
correct one was used each time. It might be possible, but it would be
useless to any experienced Lisp programmer.

I hope that helps. Also keep in mind that I'm not, and I don't think
anybody else here, is trying to convince you to use Forth if you have
already found that Lisp matches your needs better (or for that matter,
Lisp if you prefer Forth). A comparitive look at the features of
different languages is often interesting, but it's helped considerably
if we consider them in the context of the idiomatic use of the language.
  This is similar to the study of human languages -- you probably
wouldn't study the Navajo language without also learning something
about Navajo culture.

Ed

Relevant Pages

  • Re: [OT] PostLisp, a language experiment
    ... >>latter method in Lisp, and C and many other languages so that the code ... >>the complexity and number of stack items for each definition. ... I do the same thing with my assembly language code, my Java code, my C++ ... >>useless to any experienced Lisp programmer. ...
    (comp.lang.lisp)
  • Re: [OT] PostLisp, a language experiment
    ... But if your language ... On the Lisp side, we have our dogmatists as well, but Common Lisp ... value from the user stack. ...
    (comp.lang.lisp)
  • Re: Is C99 the final C? (some suggestions)
    ... You mean vague terminologies like "stack"? ... wrap whatever "spawn" mechanism you have in your language (or use some ... >> and because of Java's bignum class, it meant that exposing a widening multiply ... >> you use to determine this is just related to examining the carry flag. ...
    (comp.lang.c)
  • Re: The Promise of Forth
    ... Do you think Ada and PL/1 would be as high as they are ... They can keep a language alive at the fringes. ... still another bunch of complications when the stack holds mixed types. ... For a different data type it would have to be *completely* rewritten: ...
    (comp.lang.forth)
  • Re: [OT] PostLisp, a language experiment
    ... > erradication of stack mis-matching. ... >> apparently no runtime checks for stack mismatches, ... I consider that any decent development process should be easy to keep ... > language advocates seem to imply are necessary. ...
    (comp.lang.lisp)