Re: Elegant code Was: Re: what kind of non microconroller app are

Gerry <gerry@[EMAIL PROTECTED]
> wrote:
> Jonah Thomas <jethom...@[EMAIL PROTECTED]
> wrote:

: CHECK-STRING5 ( xt ca len -- xt ca' len' )
=A0 =A03DUP 1- 0< IF=20
     2DROP
   ELSE
=A0 =A0 =A0SWAP EXECUTE IF 1 /STRING RECURSE THEN
   THEN ;

> Personally I think you're worrying unnecessarily, your first attempt
> looks OK to me. When working with strings I often end up with a
> BEGIN... WHILE...WHILE...REPEAT...THEN structure. The only thing that
> grates is the THEN. I think it looks more complicated because of the
> way you've laid it out.

A loop with mutiple WHILEs is inherently complex. And the results are
separated from the code that creates them. I don't want to do that when
there's a better way. This particular time it turned out that a pretty
simple tail-recursion worked. So I want to try tail-recursion and
recursion before I try a loop with multiple WHILEs.=20
=20
> Incidentally if you have a Forth that handles multiple local
> declarations( I think GForth does) you can simplify your last attempt
> by getting rid of the TO's e.g.
>=20
> : GOOD-STRING2 { ca len xt }
>    ca len
>    BEGIN
>       { ca' len' }
>       len' 0 >
>    WHILE
>       ca' xt EXECUTE
>    WHILE
>       ca' len' 1 /STRING
>    REPEAT
>    THEN
>    ca len len' -
> ;
>
> Untested but I don't see why it wouldn't work, but probably isn't
> F200X compliant. It also shows my preferred layout.

I like to indent to show the nesting. Every now and then I start to make
an error that this catches. I figure that if I'm making errors then my
code is too complicated -- but how do you simplify a loop with multiple
exits? I think it's kind of simpler to use EXIT . You know the stack
state when you do EXIT is just what you'll get when your definition is
done. You don't have to depend on code somewhere else to do the right
thing. But sometimes that isn't simpler after all.

I made an error even with my simple tail-recursion code. I changed
something and forgot about the case where the string was empty. The code
that handled that was down at the bottom.

I'm better off if my habits make it easier to avoid errors. Try the
simplest way first. Do things that let me concentrate on one part at a
time without having to think about how it affects code somewhere else,
apart from the stack.

I liked multiple WHILEs when I first saw them. They were technically
good, and they made it easy to do multiple tests. But maybe it made it
easier to write things in  complicated ways.

It would be good if the layout of the language encouraged good coding
habits. When I started using Forth it had some things that strongly
discouraged some bad coding habits. Code went into 1K blocks which
discouraged routines longer than 16 lines of 64 characters. There were
no tools to help debug complicated routines, which discouraged big
complicated routines. The overhead for factoring was small, so there was
no particular advantage to putting in .S and ." statements to show what
was happening inside the code, as opposed to making each section be its
own routine that could be tested in isolation.=20

It encouraged adequate coding habits by breaking when people used bad
habits. Of course, a lot of people who tried it decided that it didn't
work rather than find out how to make it work.

So I'm starting to see multiple WHILE kind of like I see PICK though
less so. I like to have it available in case I get into a jam that needs
it. But if I need it, that's a hint that maybe I've already made a
mistake, I've painted myself into a corner where I need PICK to get out.