Re: [OT] PostLisp, a language experiment

From: Duane Rettig (duane_at_franz.com)
Date: 03/13/05 

Date: 13 Mar 2005 00:50:40 -0800

"Elizabeth D Rather" <eratherXXX@forth.com> writes:

> "Duane Rettig" <duane@franz.com> wrote in message
> news:4ll8szw8p.fsf@franz.com...
>
> > "Paul E. Bennett" <peb@amleth.demon.co.uk> writes:
> >
> ...
> > So which is longer: "DUP *", or "SQUARED"?
> >
> > 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. A compiled reference to DUP and * might involve two
> calls, and a reference to SQUARED only one, so the latter would be
> shorter. On the other hand, some compilers might compile the
> instructions in line for really low-level primitives like DUP and *,
> 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. 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. 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.

> > And yet, which is more complex cognitively? If you are an experienced
> > Forther, you might answer the first, because you've seen it so often
> > and it becomes second nature to you (plus it uses standard words that
> > you can trust to do what you expect them to do). But to anyone not quite
> > as familiar with a DUP and * combination, some thought must be put into
> > play as to what occurs on the stack, whereas the very word SQUARED is
> > self-documenting, and becomes the more readable version.
>
> Agreed, that would be a good argument for doing it. And it also
> emphasizes the fact that making smaller components can enhance
> readability.

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.

> > You apparently didn't count your characters very well. You (and other
> > Forthers) are advocating combining common cliches into single words,
> > but when the words are longer than their cliches, do you advocate
> > going back to the cliche? In other words, if John Doty was correct
> > in his advocacy of short definitions to long ones, then DUP * should
> > win, by his standard. That certainly wouldn't be my position. Give
> > me a longer, more descriptive name to call any day, rather than its
> > guts that are short.
>
> 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.

> To me, counting characters in source is one of the
> less important issues in writing efficient code. What John is talking
> about when he says "short" is the number of things to be done, not the
> number of characters needed to describe them.

Yes, but even this gets away from my question about what to do with these
pesky stack mismatches. 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. 

-- 
Duane Rettig    duane@franz.com    Franz Inc.  http://www.franz.com/
555 12th St., Suite 1450               http://www.555citycenter.com/
Oakland, Ca. 94607        Phone: (510) 452-2000; Fax: (510) 452-0182

Relevant Pages

  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... registers (memory mapped) all sorts of fun things happen. ... When the stack overflows you don't see any allocation errors. ...
    (sci.electronics.design)
  • Re: Microcontroller Project
    ... I'd then suggst you take a look at some more modern compilers perhaps. ... When the stack overwrites the ... that hard to avoid unless your program is doing something very strange. ... There is no real reason to avoid C on any micro when good compilers ...
    (sci.electronics.design)
  • Re: Statement on Schildt submitted to wikipedia today
    ... However, what Schildt described was not an abstract stack, but a specific ... but not true -- many compilers will ... support the contention that the standard was designed "to protect profits". ... "Sequence points" were designed to protect profits, ...
    (comp.lang.c.moderated)
  • Re: A Tale of Two Memory Managers (long)
    ... compilers. ... but the JIT also generates atrocious code. ... Multidimensional array access is even worse. ... deep implications for performance as every structure goes through the stack. ...
    (borland.public.delphi.non-technical)
  • Re: PIC Assembler.
    ... PL/M was. ... Check the efficiency of the code they produce. ... The top quality C compilers can produce superbly tight and efficient ... but on your average project the efficiency of your HLL won't ...
    (sci.electronics.basics)