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

In article <08011322183559@[EMAIL PROTECTED]
>, Marcel Hendrix <mhx@[EMAIL PROTECTED]
>
wrote:
>mhx@[EMAIL PROTECTED]
 (Marcel Hendrix) wrote Re: What's right with FORTH and wrong
with c.l.f.
>[..]
>>                                      E.g. if the input is
>
>>  12 apestaart 3456 kippekot 18 hondehok -771
>
>> the numbers can be fetched by string parsing and >NUMBER.
>
>> But also with
>
>>  : apestaart ; : kippekot ; : hondehok ; PARSE-NAME EVALUATE
>
>Free associations .. Would it be nice to have a special type of
VOCABULARY
>which does *not* insist on a direct string match, but accepts
>patterns (vectored FIND)? We could then define not only
>words with names, but also words with names that match a certain
>pattern. Let's say we can do that with "::" instead of ":".
>
>VOCABULARY myapp  myapp DEFINITIONS
>  S" [a-zA-Z]+" :: ( noop ) ;
>PREVIOUS DEFINITIONS
>( you must be careful not to leave myapp in the normal search order :-)
>
>12 apestaart 3456 kippekot 18 hondehok -771
>
>would now be equivalent to
>
>12 3456 18 -771
>
>Or
>
>VOCABULARY myapp myapp DEFINITIONS
>  S" ," :: ( noop ) ;
>  S~ "[a-zA-Z]+"~ :: last-name 1- 1/STRING 2DUP $CREATE ( magic1 ) , (
magic2 ) , ;
>PREVIOUS DEFINITIONS
>
>.. where last-name ( -- c-addr u ) returns the matched pattern. This
allows
>
>"HARRY","MAGDA"
>
>.. to become Forth words. Magic1 adds strings to a sorted list,
>returning the new head, and magic2 returns n based on some formula.

Looks like my PREFIX idea pushed over the edge.
In this way a reader looses all foothold to understand the code.
Compare with perl. How arcane it may be, you will always know what
is interpreted, and what is interpreting code.

A library for generating tables indexed by regexp's may be a
great idea, building it into Forth is not.

>
>Must try this in my copious spare-time.

You'll think it over, and find better things to do :-)

>-marcel

Groetjes Albert

--
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- like all pyramid schemes -- ultimately falters.
albert@[EMAIL PROTECTED]
 &=n http://home.hccnet.nl/a.w.m.van.der.horst