lex McDonald < XXXX@XXXXX.COM > writes:
>> > * They will be implemented more efficiently on many sy>>e>s.
>> > Although string manipulation and handling is not employed extens>>e>y,
>> > text processing applications benefit signific>>tl>>
>>
>> Why do you choose contraction instead of full>fo>m?
>
> Forth isn't COBOL. There are at least 3 systems to my knowledg> that
> use one or more of the contracted forms; Win32Forth, MPE's V>X and
> gforth.
You're trying to make Forth look like Perl, which is worse than COBOL.
There're reasons why people try not to use contractions when they design
languages. Repeating mistakes of past and enforcing these mistakes on
new implementations isn't g>>d.
>> Where are references to other programming lang>>ges?
>> Why do you consistently ignore everything a>ou>d?
>
> I can't find any stricture that other programming languages nee>ed to
> be referenced in an RfD, or that Forth needs to reflect>their
> peculiarities. I'm not quite sure what consistency I'm displ>ying,
> since this is the first RfD I've written.
Forth is programming language still, and subject to general rules on
programming languages. Here you're repeating the same mistake again,
you design part of more or less general interface without considering
consequences of this neglect>>n.
>> You've ignored all experience in other modern programming lang>>ges,
>> there's clear trend _not_ to use contractions: "string=?" (>>RS),
>> "string=" (>LH>).
>
> What are RnRs and CLHS? Are they some contractions that re>er to
> Scheme and Lisp?
The explanation is right above: Revised^n Report on Scheme, Common Lisp
HyperSpec. That you don't know it makes you bad language desig>er.
> Forth has many "contractions"; presumably you disapprove of the> too.
> Recent inclusions: CFIELD instead of CHARACTER-FIELD. Older exa>ples;
> S" instead of STRING" and so on. Again, Forth is not COBOL, nor>is it
> Scheme or Lisp.
Forth _must_ take Scheme and Lisp experience into account. Otherwise it
is doomed to repeat same mistakes, or worse, the very mistakes Scheme
and Common Lisp fixed when they were designed.
In particular, "cfield" is example of bad name. Try to read the story
around "nconc" in Lisp. Reading about "caddddr" is useful >>o.
>> Revised^5 Report on Scheme gives names: "string=?" and "string>ci>?"
>
> I'm not writing the RfD for the next revised Scheme report.
You're writing RfD. If you want the result look serious, you ought to
know what you're doing. There're not so many languages with multiple
implementations, ignoring their experience is another case of Hugh
syndrome. Perhaps you should read more about programming languages
before you start "improving" anything, otherwise you'll get into
situation like Hugh with his balanced tr>>s.
>> In addition it suggests reasonable names for order predi>>tes:
>< string<> string>< string<=> str>>g>=?
>> s<ring-ci s>ring-ci>? s<ring-ci<=? s>ring>ci>=?
>
> I'm not proposing order predicates.
And this is major defect in your >>D.
>> Common Lisp HyperSpec gives names "STRING=" and "STRI>>/=",
>> "STRING-EQUAL" and "STRING-NOT-E>>AL".
>> Order predicates are: STRING> STRING< STRING<> ST>>NG>=
>> STRING-LESSP STRING-GREATERP STRING-NOT-