Re: using MISC (post 1987 Forth hardware) opcodes


Jeff Fox wrote:

Take the removal of ELSE for instance.

This clearly had nothing to do with hardware in that an ELSE is
just a jump and the machines all have had jump instructions.

Yes.

So instead of using ELSE, Chuck wanted to use ; instead.

This would keep words short and simple as in:

: DEMO blah if this ; then that ;

This does not make sense to me. What makes this simple is factoring
DEMO into blah this and that.

: DEMO blah if this else that then ;

For ease of use and simplicity for the programmer, I don't see a
difference here -- once the programmer is equally used to both
approaches.

An implementation might make your method compile nicer code without
optimisation. On the other hand, if that's desirable ELSE might be
implemented as

: ELSE POSTPONE ; ; IMMEDIATE

and

: THEN :NONAME POSTPONE THEN ; IMMEDIATE

and depending on your implementation you might get the same result. It
won't work for implementations that leave both colon-sys and dest on
the stack.

Either way, you still have to test every branch of DEMO . And if you
have branches that are hard to factor into THIS and THAT then you can't
do unit tests on THIS and THAT but you have to test DEMO with all its
branches.

It doesn't actually look at all simpler to me. It looks like the same
thing.

Chuck said, for those interested in the conceptual foundation
for why he removede ELSE, that this would enforce factoring
into smaller definitions and make the code easer to write,
to read, and to maintain.

It's semantic sugar. Since you can implement ELSE in his code with no
trouble (I think)

: ELSE POSTPONE ; :NONAME ; IMMEDIATE

nothing has been enforced.

He said, if you make your code that simple that most of the errors
that happen to people in the page long definitions, that are so
popular in c.l.f, would not happen. He said if you use that kind
of simple one liner definitions and test them that most of the
errors that other people see will be impossible.

If you write a page-long definition with one : and a long series of ;
thens, your code is just as complex as the page-long definition with
ELSEs. And no easier to test.

So I think what Chuck is doing here is not enforcing short definitions.
He's suggesting an idiom that might possibly help remind people to
write short definitions. It's like the idea of writing english in E'
where you never use any version of the word "is" or "to be". The
exercise *can* encourage people to think about the times they say one
thing is something else, and so it can have a profound effect on their
thinking. But if they're inclined to use 'is' they're likely to just
replace it with 'seems' or some other formula that fits the same
pattern and then write E' without thinking and lose all the benefit.

It's a reminder. When you choose to use Chuck's Forth you're making a
choice to try for simplicity. And the phrase ; then in place of else
reminds you of that choice.

And that's all it does. it's a subtle trick by Chuck to encourage
people to simplify their code.

I'd be interested to find out I'm wrong about that. Does it actually
make the code easier to debug? Or easier to understand? Easier to
write? If my Forth compiler was arranged so that I could do a global
replace through my code and change every ELSE to ; THEN would my code
be better?

.

Relevant Pages

  • Re: A theorem cant be wrong
    ... >>> It seems odd that I need to remind that a theorem cannot be ... > So you focus on the practical question of factoring. ... There is no general statement to characterize what makes a ...
    (sci.math)
  • Re: A theorem cant be wrong
    ... >> It seems odd that I need to remind that a theorem cannot be ... So you focus on the practical question of factoring. ...
    (sci.math)