Richard Owlett <rowlett@[EMAIL PROTECTED]
> wrote:
> I'm interested in a variety of problems ranging from subsets of speech
>
> recognition to sources of GPS errors and their significance.
>
> What do they have in common?
> Someone else has compiled raw data. It's available in ASCII format.
> That requires me to parse it.
> I doubt anyone would claim string handling as a Forth forte.
>
> I've quit asking questions on c.l.f. as typical answer has been
>
> "DON'T DO THAT"
My experience has been somewhat different.
Various people are interested in string hasndling with Forth. In general
each of them prefers his own methods, but I've seen them compare notes
and learn from each other.
I don't see much common practice. Each different string package is,
well, different. None of them is particularly simple, partly because
they do complicated things. I haven't seen one that seems particularly
forthy to me.
The only people who say don't do it are people who prefer other
languages. Why try to play catch-up with Forth, when it would be easier
to just use *my-favorite-language* instead. And if you just want quick
results in the short run, that's probably the way to go.
So if you have raw data in ASCII format and you want to do something
special with it in Forth, one possibility is to notice what you want to
do, and build words that do it, and then give them good names, and
finally use some other language to put your names into the data file at
just the right places so they do what you want. One traditional trick
was to store single-cell data with , and put a comma after each item you
want to store. Sometimes the only massaging you'd need was to get spaces
between the existing commas and the numbers.
If you just want quick results with the data you have today, it's bound
to be easier to use some simple language that does strings well to
change the files into a format you can use, than to invent a good string
package.
The point of managing strings with Forth has got to be that you'll do it
better than it gets done elsewhere. You have to believe you can invent a
better string package than the guys who have 40 years experience with
other languages, or it probably isn't worth doing. Re-inventing the
wheel is fine, but why re-invent the transmission? Do a whole lot of
work and get something that's no better than what you could get
off-the-shelf?
Elizabeth Rather has pointed out an approach that's likely to work for
that. You start with an application that needs some string manipulation,
and you solve it from scratch. Then do it again with a second
application, and a third. After awhile you'll see common patterns and
you'll develop generally-useful approaches. The tools that have been
generally useful become a string package. Other people will not be used
to these simple tools and they'll have to learn how to use them. If
enough others figure it out and like how it works, then eventually
they'll spread. (This is not exactly what she said. She described how
Chuck does things, and I extrapolated from it.)
There's the problem that if you're on a tight deadline you probably
don't want to spend much time developing string handling from scratch.
And if there's no deadline you're likely to be desultory about it. I've
done a little bit along these lines but without much urgency. Here's one
thing I picked up from Marcel -- he rewrote a string word very simply,
using locals and a DO LOOP . He used BOUNDS to convert the loop
parameters from ( ca len ) to ( ca+len+1 ca ) and his loop was simpler.
I found the word was easier for me with other approaches when I did it
that way too. Make the inputs ( ca+len+1 ca xt) instead of ( ca len xt )
.. I had been jockeying things around so I could use /STRING but with (
ca' ca ) instead of ( ca len ) I only needed to change one item instead
of two and /STRING wasn't needed. So in my spare-time no-deadline slow
project I'll look at the ( ca' ca ) format and see whether I get any
general disadvantages from it compared to ( ca len ).
There's an old story where a sword-teacher was asked which was more
important, speed or strength or agility etc. And he told a story about
some people who were dancing to a drumbeat, and the drummer was dancing
too. He asked who would be best at dancing to the time. The students
agreed that the drummer could match his own timing better than anyone
else could. The winning swordsman was the one who could get the
initiative. In the same way, a Forth string package that's supposed to
do the same thing as an existing string package can hardly be a whole
lot better. If string.c is the goal you're trying to achieve, how do you
make string.f be more like string.c than string.c is?
So I think once you've built a half a dozen applications that use string
handling from scratch, you might notice you have a good way to handle
strings without garbage collection. That to my mind would be better than
finding several good ways to do garbage collection. YMMV.
|
