Re: What's right with FORTH and wrong with c.l.f.

"The Beez'" <hansoft@[EMAIL PROTECTED]
> wrote:

> I've equivalents of Basic string handling (start/count), ZX string
> handling (start/end), but I rarely seem to use them. /STRING. 1-, CHOP
> and BOUNDS are much handier tools in everyday use. And yes, I got
> equivalents for substring replacement and substring deletion as well.
> Parsing files is unmatched in Forth/4tH. Much easier and versatile
> than e.g. C.
 
The weakness I see is concatenating strings. You can use ALLOCATE and
depend on the system that provides ALLOCATE to do decent garbage
collection. Or you can copy both strings at HERE and trust you'll be
able to -ALLOT the space at the right time.

If the point is to send the string to a file or a pipe etc, you don't
have to concatenate strings, just send all the parts in the right order.
You can get by sending the first part as soon as you know it, and then
you don't have to keep track of it. 

If you find a method to do the needed work that's low-overhead for the
hardware (or low overhead for the Forth virtual machine, even if it
isn't the most efficient on the real hardware) then it's likely to wind
up conceptually simple too. Simple methods, simple ideas. It won't be as
easy to use as the string packages that let you do *anything* without
any consideration for how it's done. But it's likely to fit well into
the rest of the Forth toolbox.

Would Forth programmers put up with that? We already do things that need
to be arranged just so, that other languages make easier. Is there any
justification for one more of those?

You can eliminate all stack noise by using locals in every definition.
Put the input parameters into locals. Whenever you generate a stack item
that you don't DROP , put it into a local too. No stack noise at all.
You could get rid of the stack words. Is there any advantage to writing
so the stack is easy to use, when you can get results just as good by
using locals all the time? There's an art to writing Forth so things
mostly appear on the stack when they're needed without much stack noise.
But why go to that trouble when locals will put things wherever you want
with no thought required? Similarly, why accept a simple string package
that requires you to think, when you can have a complicated one that
does everything you want behind your back and gives you results with no
thought required?