Re: [OT] PostLisp, a language experiment

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

Date: 14 Mar 2005 01:43:55 -0800

Ed Beroset <beroset@mindspring.com> writes:

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

Yes, of course; that's easy for me to see, because you already have
a preconception that there isn't a language for which longer
definitions don't automatically make the function more buggy (as
opposed to writing the same amount of functionality into a greater
quantity of shorter definitions). Since I know a language for which
a longer definition _can_ be written without increasing the liklihood
of bugs, I can separate the concept of wanting longer definitions
from the concept of wanting buggier code. Obviously, I don't desire
buggier code.

> 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?"

First, I'm assuming that you aren't saying that writing shorter
definitions in Forth guarantees the code to be bug-free - right?
If my assumption is false, then we need to start back a little
farther and find out how this is done. But I think the assumption
is true, because of what your colleagues are saying about testing,
as well as my experiences with Forth (and of course, common sense).

If it's true that short definitions don't guarantee bug-free code,
then your analogy doen't hold; that's not at all what I'm saying.

  It's not
> that the question doesn't make literal sense, but that it's not clear
> why anyone would want to do that.

Indeed. Why would one want to write buggy code? Let's move on.
Do you think I'm saying that? If so, then you have some assumptions
that need to be adjusted, because I'm obviously not saying 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.

In the Lisp world, we tend to look down on efficiency-as-excuse-for-
bugginess. Of course, there are areas where we desire to compete
with C efficiency, where in order to do so we must model the
hardware-modulo effect (i.e. where adding 1 to the most-positive
machine-integer mysteriously results in the most-negative
machine-integer) but for the most part we try to analyze types
to prove that overflowing to different representations are not
necessary.

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

Lexical proximity and modularity.

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

Not necessarily, but even if it always did, how do you reconcile
a 1000-entry case statement into a "short" definition?

 That is, you wouldn't have extremely long actions for each case.
> Just as in Forth, you'd break things up into named function.

And how do you describe the function/word that contains the actual
case statement? Is it short? (Of course, we'd have to assume that
there would exist a case type of construct in the first place; Elizabeth
Rather has suggested a particular implementation, but is such an
implementation even likely in the Forth world?)

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

Right. I think we're actually getting somewhere. Perhaps if you
were to analyze precisely what you mean by "short" and "long",
you would conclude that such measurement is really a qualitaative
measurement about the amount of complexity in the stack
interaactions. Possible?

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

Heh :-) I actually do avoid them. It's been 1984 since my last
Forth program :-)

(but more below... )

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

Yes, I also avoid these in the same way...

I like my code to document itself. Why? Because documentation always
becomes out-of-date - nobody has the perfection of discipline to always
change the docmentation when the function/word is changed. But when I
run my code through a tool that generates that documentation
automatically, it is only out of date until I regenerate my documentation.

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

On the contrary; we use these tools all the time (though not to check,
but to actually generate). Especially when one uses the shortcut
functions that combine a "c" with any numbers of "a" and "d" followed
finally by "r" (as in cadr, cadadr, etc) to follow down the nodes of
trees or other list structures; we often use macros to decide what the
correct branch in the tree is at a particular point, given a higher-level
specification.

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

Yes, of course; I know the Forth of the 80s, but I don't know what
tools people are using to enhance their productivity in Forth
nowadays, and hence my questioning. Note that I'm also not trying
to "convert" you to Lisp use, but I am trying to get you to think
about how your productivity can be increased, given that you like
to stay in Forth. 

-- 
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: [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: [OT] PostLisp, a language experiment
    ... my discussion with John Doty was based on stack ... I already have a language in which I can write long ... latter method in Lisp, and C and many other languages so that the code ... > apparently no runtime checks for stack mismatches, ...
    (comp.lang.lisp)
  • Re: [OT] PostLisp, a language experiment
    ... If you specifically refer to one language ... > IMHO the worst thing in Lisp is its many parentheses. ... > The worst thing about Forth IMHO is the stack clutter. ... > local variables instead. ...
    (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)