[comp.lang.forth] More "things you cannot do"

wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (02/11/91)

> 5) You can't execute control structures interpretively.
>    (This also applies to many implemenations of TO.)
>
> Of course, you can't do this in any current Forth except yours and
>  John Hayes' (to my knowledge).  This is something I miss from STOIC
>  (yes, I once used STOIC), and it's one of the _hardest_ things for
>  me to get across to a new Forth programmer.

I proposed this feature last year, but it didn't pass.  The rationale
for rejecting it was that:

a) ANS Forth is primarily intended to provide a standard language for
   writing programs, rather than a standardized interactive environment
   (yes, I know this is a weak argument).

b) Interpreted control structures don't really add new capability, but
   instead extra convenience.  (Convenience is good, but not compelling).

> Another stumbling block for new programmers:
> 6) You can't compile in-line string arguments.
>
> Meaning, arguments which are taken from the input stream.  It's
>  painful to explain, to a neophyte who's tired of typing INCLUDE"
>  commands, why you can't write a shorthand word
>    : L  INCLUDE" TEST.FTH" ;
>
> The only solution .. that I'm aware of would use the STOIC
> method of passing string arguments.

Yes, this is a problem in general.  It's really a fundamental botch in
the design of Forth.  I prefer STOIC in this respect myself.

Greg Bailey and I briefly considered proposing some form of prefix
thing that would "condition" certain words to accept an argument from
the stack instead of from the input stream.  However, when we got into
the design, we discovered some nasty modality problems.  It was really
a can of worms.  There was an outside proposal about the same issue, but
it had some ugly side effects too.

WRT the particular word INCLUDE, at the last meeting we nuked it in
favor of the postfix word INCLUDED , which takes ( addr len -- ). e.g.

        S" TEST.FTH" INCLUDED

Mitch Bradley