string concatenation (was: What's right with FORTH ...)

Jonah Thomas <jethomas5@[EMAIL PROTECTED]
> writes:
>The weakness I see is concatenating strings.

Yes, that's one of the few things that I define beyond what the
standard provides.  Here's what I have used lately:

: s+ { addr1 u1 addr2 u2 -- addr u }
    u1 u2 + allocate throw { addr }
    addr1 addr u1 move
    addr2 addr u1 + u2 move
    addr u1 u2 +
;

: append { addr1 u1 addr2 u2 -- addr u }
    addr1 u1 u2 + dup { u } resize throw { addr }
    addr2 addr u1 + u2 move
    addr u ;

S+ is for the case where the concatenated string should be newly
allocated.  APPEND is for the case where the first string is ALLOCATEd
and can be freed in the process.  Both words return ALLOCATEd strings.
A typical usage is:

    [ libtool-command s"  --silent --mode=compile gcc -I " s+
    s" includedir" getenv append ] sliteral
    s"  -O -c " s+ lib-filename 2@[EMAIL PROTECTED]
 append s" .c -o " append
    lib-filename 2@[EMAIL PROTECTED]
 append s" .lo" append ( c-addr u )
    2dup system drop free throw $? abort" libtool compile failed"

I.e., first you create an ALLOCATEd string with S+, then you APPEND to
it, then you use it (in SYSTEM this time), and finally you FREE it.

If I don't have to worry about FREEing, I can just use S+ everywhere.

All of that is not particularly efficient, though.

The other set of string words I use now and then is for comparison:

: str= ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
    compare 0= ;

: string-prefix? ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
    \G Is @[EMAIL PROTECTED]
 u2} a prefix of @[EMAIL PROTECTED]
 u1}?
    tuck 2>r min 2r> str= ;

: str< ( c-addr1 u1 c-addr2 u2 -- f ) \ gforth
    compare 0< ;

I don't compare strings that often, but when I do, usually one of
these words fits.

These words are defined in compat/strcomp.fs, so they can be used on
any standard system.

>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. 

I have been thinking lately about enhancing Forth with pipes/streams.
This would not just allow to use multiple hardware threads, it could
also help with some of the usual problems by introducing a new way of
factoring: Factor your computation into filters that talk to each
other.

For string concatenation, one could pipe the substrings to a filter
that just generates the full string; or one could pipe it to a filter
that outputs the individual characters as a stream (that would be a
stream representation of the string), which could then be piped into
other components.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2008:
http://www.complang.tuwien.ac.at/anton/euroforth/ef08.html