Some COMPARE 0= statistics
Alex McDonald
that some statistics would be desirable to support the assertion that
COMPARE 0= was inefficient in comparison with a specific test for
equality. Specifically, that it is expensive to execute for equality
or inequality (the common cases) due to the need to complete the
comparison to return greater-than or less-than return values.
I have instrumented Win32Forth for this purpose, and the results for a
compilation of the system are shown (some 59 files in a single
compilation unit). The COMPARE 0= test is used predominantly to search
the dictionaries, shown below.
Vocabularies #Threads #Words #Average
hashed 79 477 6.0
classes 7 100 14.2
environment 1 35 35.0
vimage 19 180 9.4
disassembler 19 301 15.8
optimise 19 72 3.7
asm-hidden 19 349 18.3
assembler 19 524 27.5
root 1 3 3.0
forth 331 2231 6.7
hidden 31 365 11.7
files 3 61 20.3
locals 1 1 1.0
imports 17 3 0.1
exports 3 0 0.0
-----------------------------------------
Total Words: 4702
The #average column is the number of words per hash chain; a single
request for a compare will undertake that many tests on average. The
FORTH vocabulary is the most heavily used, hence the larger table and
shorter chains.
The stats for COMPARE 0= are
Requests 747827
Matches 47281
Matches chars compared 184248
No matches (<>length) 661155
No matches (<>length) chars compared 899534
No matches (=length) 39391
No matches (=length) chars compared 43224
Matches: when the comparison was equal
No matches (<>length): comparisons for unequal length strings.
Characters are compared up until the point of no match
No matches (=length): comparisons for equal length strings.
Only 6.3% of comparisons ended in a match. Of the total characters
tested (1,127,006), only 227472 or 20% are tested when the string
lengths are equal.
Given the preponderence of tests that are failed due to a length
mismatch, a simple COMPARE 0= test is grossly inefficient in this
case. A test for string equality prior to the COMPARE would appear to
be of considerable benefit.
Andrew Haley
Perhaps, but perhaps not. If the first four characters being
different is more common than the length being different, it might
actually be quicker on average to check them first, and not waste time
worrying about the length.
Am I the only one who finds it rather odd that anyone would be using
COMPARE to do dictionary searches? Classically you'd have a counted
string in memory somewhere and a dictionary of (suitably aligned)
counted strings and you'd be doing the comparison a word at a time.
So, if either the count or the first characters were different you'd
know instantly, and go to the next one.
This way:
: match ( a1 a2 - t)
over @ over @ xor if 2drop 0 exit then
dup c@ tuck compare 0= ; ( little-endian!)
or this way:
: (match) ( a1 a2 n - t)
cell 1- + cell/ 0 do
cell+ swap cell+
over @ over @ xor if 2drop 0 unloop exit then
loop
2drop 1;
: match ( a1 at 2)
over @ over @ xor if 2drop 0 exit then
dup c@ (match) ; ( little-endian!)
(Untested, but you get the idea...)
99.something% of the time this first check will tell you what you need
to know, so the time taken by the check when the length is the same
and the first few characters match probably doesn't matter. The only
exception to this is when you have a really pathological case such a a
ton of strings with the same length and a common prefix. In that
case, you have to depend on a good hash function, and it's worth
putting the hash at the start of the name.
Andrew.
Alex McDonald
wrote:
Ignore the dictionary for the moment.
No matches (<>length) 661155
No matches (<>length) chars compared 899534
No matches (=length) 39391
No matches (=length) chars compared 43224
The ratio of compared characters when the lengths are not equal and
there's no match is 1.36 per call. For lengths equal and no match,
it's 1.09 per call. I suspect (see below) that in the unequal lengths
case and further up the string to mismatch is caused by words of the
form prefix-nnn prefix-mm prefix-zzzz and so on.
>
> Am I the only one who finds it rather odd that anyone would be using
> COMPARE to do dictionary searches? Classically you'd have a counted
> string in memory somewhere and a dictionary of (suitably aligned)
> counted strings and you'd be doing the comparison a word at a time.
> So, if either the count or the first characters were different you'd
> know instantly, and go to the next one.
>
That was the easiest place to instrument it, that's all. I wasn't
suggesting that COMPARE is an efficient way of locating dictionary
entries.
>
> 99.something% of the time this first check will tell you what you need
> to know, so the time taken by the check when the length is the same
> and the first few characters match probably doesn't matter. The only
> exception to this is when you have a really pathological case such a a
> ton of strings with the same length and a common prefix. In that
> case, you have to depend on a good hash function, and it's worth
> putting the hash at the start of the name.
The hash for a given chain will have the same value, hence be of no
use if you are using a hash table with chained entries as in the
Win32Forth case.
I have two string equality tests; the first scans left to right, the
second scans right to left. The second compares fewer characters
before declaring a mismatch (1.23 compares per call); it would appear
that, for a given length, the later characters do not match as
frequently as the earlier characters with the Win32Forth wordset. The
difference is marginal, but interesting.
>
> Andrew.
Andrew Haley
> On Nov 26, 1:25?pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>>
>> Perhaps, but perhaps not. If the first four characters being
>> different is more common than the length being different, it might
>> actually be quicker on average to check them first, and not waste time
>> worrying about the length.
>
> Ignore the dictionary for the moment.
OK. We have to think of some concrete usages that actually make
sense, though. I wonder if every usage where the speed of STR= versus
COMPARE 0= actually makes a significant difference is probably better
handled some other way.
> No matches (<>length) 661155
> No matches (<>length) chars compared 899534
> No matches (=length) 39391
> No matches (=length) chars compared 43224
>
> The ratio of compared characters when the lengths are not equal and
> there's no match is 1.36 per call. For lengths equal and no match,
> it's 1.09 per call. I suspect (see below) that in the unequal lengths
> case and further up the string to mismatch is caused by words of the
> form prefix-nnn prefix-mm prefix-zzzz and so on.
The ratio of what to what? I don't understand what you're saying.
>> 99.something% of the time this first check will tell you what you need
>> to know, so the time taken by the check when the length is the same
>> and the first few characters match probably doesn't matter. The only
>> exception to this is when you have a really pathological case such a a
>> ton of strings with the same length and a common prefix. In that
>> case, you have to depend on a good hash function, and it's worth
>> putting the hash at the start of the name.
>
> The hash for a given chain will have the same value,
Only if the hash is utterly broken! Surely a hash function should
return a whole word that you reduce modulo N to select a list.
Andrew.
Alex McDonald
wrote:
> Alex McDonald <b...@rivadpm.com> wrote:
> > On Nov 26, 1:25?pm, Andrew Haley <andre...@littlepinkcloud.invalid>
> > wrote:
>
> >> Perhaps, but perhaps not. If the first four characters being
> >> different is more common than the length being different, it might
> >> actually be quicker on average to check them first, and not waste time
> >> worrying about the length.
>
> > Ignore the dictionary for the moment.
>
> OK. We have to think of some concrete usages that actually make
> sense, though. I wonder if every usage where the speed of STR= versus
> COMPARE 0= actually makes a significant difference is probably better
> handled some other way.
>
> > No matches (<>length) 661155
> > No matches (<>length) chars compared 899534
> > No matches (=length) 39391
> > No matches (=length) chars compared 43224
>
> > The ratio of compared characters when the lengths are not equal and
> > there's no match is 1.36 per call. For lengths equal and no match,
> > it's 1.09 per call. I suspect (see below) that in the unequal lengths
> > case and further up the string to mismatch is caused by words of the
> > form prefix-nnn prefix-mm prefix-zzzz and so on.
>
> The ratio of what to what? I don't understand what you're saying.
Ratio of 661155 COMPAREs for 899534 characters tested = 1.36 character
tests per call of a COMPARE on unequal string lengths that ends in no
match. Ratio of 39391 COMPAREs for 43224 characters tested = 1.09
character tests per call of a COMPARE on equal string lengths that end
in no match.
In other words; strings that are of equal lengths mismatch earlier in
the string compared to strings that are of unequal lengths.
>
> >> 99.something% of the time this first check will tell you what you need
> >> to know, so the time taken by the check when the length is the same
> >> and the first few characters match probably doesn't matter. The only
> >> exception to this is when you have a really pathological case such a a
> >> ton of strings with the same length and a common prefix. In that
> >> case, you have to depend on a good hash function, and it's worth
> >> putting the hash at the start of the name.
>
> > The hash for a given chain will have the same value,
>
> Only if the hash is utterly broken! Surely a hash function should
> return a whole word that you reduce modulo N to select a list.
OK, I see, you mean keeping the hash, not the mod N. In which case,
that's a cell extra to fetch and compare, and you'd still need to
compare the following characters on a match. It's cheaper comparing
lengths and not hashing unless you have to given the results above.
>
> Andrew.
BruceMcF
> Given the preponderence of tests that are failed due to a length
> mismatch, a simple COMPARE 0= test is grossly inefficient in this
> case. A test for string equality prior to the COMPARE would appear to
> be of considerable benefit.
So you are saying that instead of defining STR= as:
: STR= ( ca1 u1 ca2 u2 -- flag ) COMPARE 0= ;
If S= ( ca1 ca2 u -- flag ) is available, STR= should be defined as:
: STR= ( ca1 u1 ca2 u2 -- flag )
ROT OVER <> IF DROP 2DROP FALSE EXIT THEN
S= ;
Of course, if S= is not available, it can be defined as:
[UNDEFINED] S= [IF]
: S= ( ca1 ca2 u -- flag ) TUCK COMPARE 0= ;
[THEN]
Alex McDonald
Possibly. In the Win32Forth case, the STR= or S= would very likely
need to be in CODE to make a positive difference; the stack juggling
may outweigh the benefit. I need to test further.
BruceMcF
Given a primitive S=, a factor to do all the stack juggling in code
would be:
\ ?LEN<> ( ca1 u1 ca2 u2 -- TRUE | ca1 u1 ca2 u2 FALSE )
: STR= ( ca1 u1 ca2 u2 -- flag )
?LEN<> IF FALSE EXIT THEN
S= ;
BruceMcF
> Given a primitive S=, a factor to do all the stack juggling in code
> would be:
> \ ?LEN<> ( ca1 u1 ca2 u2 -- TRUE | ca1 u1 ca2 u2 FALSE )
>
> : STR= ( ca1 u1 ca2 u2 -- flag )
> ?LEN<> IF FALSE EXIT THEN
> S= ;
No, that's:
: STR= ( ca1 u1 ca2 u2 -- flag )
?LEN<> IF FALSE EXIT THEN
COMPARE 0= ;
But cleaner is:
\ LEN= ( ca1 u1 ca2 u2 -- ca1 u1 ca2 u2 flag=[u1=u2?] )
: STR= ( ca1 u1 ca2 u2 )
LEN= IF COMPARE 0= ELSE 2DROP 2DROP FALSE THEN ;
Aleksej Saushev
> As part of the RFD for string equality comparisons, it was suggested
> that some statistics would be desirable to support the assertion that
> COMPARE 0= was inefficient in comparison with a specific test for
> equality. Specifically, that it is expensive to execute for equality
> or inequality (the common cases) due to the need to complete the
> comparison to return greater-than or less-than return values.
>
> I have instrumented Win32Forth for this purpose, and the results for a
> compilation of the system are shown (some 59 files in a single
> compilation unit). The COMPARE 0= test is used predominantly to search
> the dictionaries, shown below.
(Table skipped.)
> The #average column is the number of words per hash chain; a single
> request for a compare will undertake that many tests on average. The
> FORTH vocabulary is the most heavily used, hence the larger table and
> shorter chains.
>
> The stats for COMPARE 0= are
>
> Requests 747827
> Matches 47281
> Matches chars compared 184248
> No matches (<>length) 661155
> No matches (<>length) chars compared 899534
> No matches (=length) 39391
> No matches (=length) chars compared 43224
>
> Matches: when the comparison was equal
> No matches (<>length): comparisons for unequal length strings.
> Characters are compared up until the point of no match
> No matches (=length): comparisons for equal length strings.
>
> Only 6.3% of comparisons ended in a match. Of the total characters
> tested (1,127,006), only 227472 or 20% are tested when the string
> lengths are equal.
>
> Given the preponderence of tests that are failed due to a length
> mismatch, a simple COMPARE 0= test is grossly inefficient in this
> case. A test for string equality prior to the COMPARE would appear to
> be of considerable benefit.
This is patchwork specifically tuned to support your claims rather than
objective research. You have completely ignored several independent points
that make the need for special string equality predicate doubtful.
First, you didn't measure the ratio of COMPARE calls to total number of calls,
thus you haven't demonstrated how important the problem is in general.
Second, I see above that you used interpreter implementation source in
your research. Is Win32Forth used only to implement itself? How do your
figures change if you use applications rather than interpreter?
Third, that you use COMPARE to search dictionary doesn't make "string="
interesting from optimisation point of view. Replace "compare 0=" in
your dictionary search with "aaknbgfjcxckaer" that is specifically
optimised to your dictionary operations. Nobody's interested in what you
do there in general, you can do whatever you want there. On the contrary,
if you standardise anything, it is exposed to everyone. You haven't done
anything to determine the impact of your proposed "optimisation" outside
internal problems of your implementation.
Fourth, it is quite possible that someone may prefer using three-way comparison
rather than equality test. For instance, one may wish to implement a kind of
search tree rather than linked list. This shows that it is absolutely wrong
to base any decision on benchmarks that include perhaps very inefficient
dictionary structure which requires string equality predicate rather than
something else.
Fifth, there's large corpus of code (SP-Forth user libraries, ac* network suite)
that refutes your arguments pro string equality predicate. You have completely
ignored its existence in your research. Given that major part of that corpus
deals with textual information (text-based network protocols like HTTP, SMTP,
POP3, IMAP4), this is very strong point.
--
HE CE3OH...
Alex McDonald
Why other calls? The exercise was to test COMPARE 0= with STR= . Since
COMPARE 0= can't be replaced by DUP SWAP or any other words, the point
is lost on me.
> Second, I see above that you used interpreter implementation source in
> your research. Is Win32Forth used only to implement itself? How do your
> figures change if you use applications rather than interpreter?
They don't, at least by no more than a few %age points. The
interpreter requires the compilation and searching of several
thousands of words, with 747827 lookups. The average application is
much shorter, hence the choice of it as an example.
>
> Third, that you use COMPARE to search dictionary doesn't make "string="
> interesting from optimisation point of view. Replace "compare 0=" in
> your dictionary search with "aaknbgfjcxckaer" that is specifically
> optimised to your dictionary operations. Nobody's interested in what you
> do there in general, you can do whatever you want there. On the contrary,
> if you standardise anything, it is exposed to everyone. You haven't done
> anything to determine the impact of your proposed "optimisation" outside
> internal problems of your implementation.
The instrumentation point was chosen because of the very large number
of lookups. Win32Forth does not use COMPARE 0= for dictionary
searches, nor does it use STR= as documented, as I indicated in a
previous reply. The case insensitive compare used in the dictionary
search is the basis for exposing STR= .
>
> Fourth, it is quite possible that someone may prefer using three-way comparison
> rather than equality test. For instance, one may wish to implement a kind of
> search tree rather than linked list. This shows that it is absolutely wrong
> to base any decision on benchmarks that include perhaps very inefficient
> dictionary structure which requires string equality predicate rather than
> something else.
The test is for COMPARE 0= , not for the dictionary implementation.
The dictionary lookup is being used as a harness, not to demonstrate
its other attributes.
>
> Fifth, there's large corpus of code (SP-Forth user libraries, ac* network suite)
> that refutes your arguments pro string equality predicate. You have completely
> ignored its existence in your research. Given that major part of that corpus
> deals with textual information (text-based network protocols like HTTP, SMTP,
> POP3, IMAP4), this is very strong point.
I can only guess at its significance, since the entire corpus of the
commentary is written in Russian.
>
> --
> HE CE3OH...
Aleksej Saushev
Because if "compare 0=" makes really insignificant amount of calls,
there's no point in optimisation at all. SP-Forth code demonstrates
that you can live without proposed "syntactic sugar." There's another
counterexample of Gforth demonstrating that you can live with "str="
being equivalent to "compare 0=" without any special optimisations
behind it.
>> Second, I see above that you used interpreter implementation source in
>> your research. Is Win32Forth used only to implement itself? How do your
>> figures change if you use applications rather than interpreter?
>
> They don't, at least by no more than a few %age points.
This is to be demonstrated.
> The
> interpreter requires the compilation and searching of several
> thousands of words, with 747827 lookups. The average application is
> much shorter, hence the choice of it as an example.
It is completely uninteresting how your interpreter works inside.
If you're writing standard proposal to make it easier to implement
_interpreter_, it isn't interesting at all. Implementors' problems
are _not_ interesting to language users.
Consider another programming language. Say, Erlang.
I care absolutely nothing how it delivers messages, whether it uses
locks or lock-free algorithms, and if it uses locks, I care absolutely
nothing how they're implemented, whether they use athomic CAS or LL/SC
operations or some other hardware support. It may be possible that some
particular patterns of commincation are better performed via specially
crafted communication method. Still I have never heard that anyone
came up with proposal to standardise something of the kind. Even though
Erlang has known performance problems.
The world has gone further in past 30 years. If programming language
requires special tricks on programmer's side to achieve performance,
it is considered bad. Performance optimisations are for optimisers
nowadays.
>> Third, that you use COMPARE to search dictionary doesn't make "string="
>> interesting from optimisation point of view. Replace "compare 0=" in
>> your dictionary search with "aaknbgfjcxckaer" that is specifically
>> optimised to your dictionary operations. Nobody's interested in what you
>> do there in general, you can do whatever you want there. On the contrary,
>> if you standardise anything, it is exposed to everyone. You haven't done
>> anything to determine the impact of your proposed "optimisation" outside
>> internal problems of your implementation.
>
> The instrumentation point was chosen because of the very large number
> of lookups. Win32Forth does not use COMPARE 0= for dictionary
> searches, nor does it use STR= as documented, as I indicated in a
> previous reply. The case insensitive compare used in the dictionary
> search is the basis for exposing STR= .
This is non sequitur. If you use anything in implementation, it doesn't
follow that you should expose it. It is wrong to base justification on a
number of lookups too (these lookups may be part of one-time job).
It is wrong to base justification on building interpreter.
>> Fourth, it is quite possible that someone may prefer using three-way comparison
>> rather than equality test. For instance, one may wish to implement a kind of
>> search tree rather than linked list. This shows that it is absolutely wrong
>> to base any decision on benchmarks that include perhaps very inefficient
>> dictionary structure which requires string equality predicate rather than
>> something else.
>
> The test is for COMPARE 0= , not for the dictionary implementation.
> The dictionary lookup is being used as a harness, not to demonstrate
> its other attributes.
The test is based on interpreter implementation source.
>> Fifth, there's large corpus of code (SP-Forth user libraries, ac* network suite)
>> that refutes your arguments pro string equality predicate. You have completely
>> ignored its existence in your research. Given that major part of that corpus
>> deals with textual information (text-based network protocols like HTTP, SMTP,
>> POP3, IMAP4), this is very strong point.
>
> I can only guess at its significance, since the entire corpus of the
> commentary is written in Russian.
I have no doubt at Win32Forth insignificance, since I have never heard
of any program written with it and used in the wild outside small Forth
community. To add to this, you have failed to find any code corpus
besides Win32Forth source.
--
HE CE3OH...
Alex McDonald
[snipped points]
>
> I have no doubt at Win32Forth insignificance, since I have never heard
> of any program written with it and used in the wild outside small Forth
> community. To add to this, you have failed to find any code corpus
> besides Win32Forth source.
>
> --
> HE CE3OH...
Your points are noted. Since I have not heard of you either, I shall
assign them a corresponding weight in any revised RfD.
Brad
> Given the preponderence of tests that are failed due to a length
> mismatch, a simple COMPARE 0= test is grossly inefficient in this
> case. A test for string equality prior to the COMPARE would appear to
> be of considerable benefit.
I tried this on VFX:
: s= ( a1 n1 a2 n2 -- flag )
2 pick over <> if 2drop 2drop 0 exit then compare 0= ;
S= is redefined ok
see s=
S=
( 0048BBC0 3B5D04 ) CMP EBX, [EBP+04]
( 0048BBC3 0F8409000000 ) JZ/E 0048BBD2
( 0048BBC9 BB00000000 ) MOV EBX, 00000000
( 0048BBCE 8D6D0C ) LEA EBP, [EBP+0C]
( 0048BBD1 C3 ) NEXT,
( 0048BBD2 E8498CF7FF ) CALL 00404820 COMPARE
( 0048BBD7 85DB ) TEST EBX, EBX
( 0048BBD9 0F94C3 ) SETZ/E BL
( 0048BBDC F6DB ) NEG BL
( 0048BBDE 0FBEDB ) MOVSX EBX, BL
( 0048BBE1 C3 ) NEXT,
( 34 bytes, 11 instructions )
ok
When the lengths don't match, five instructions (including next,)
execute. But for all I know, COMPARE might already perform this
trivial test. If the off-the-shelf COMPARE isn't quite optimal, you
can always add the length test. My preference would be for the
compiler to recognize "COMPARE 0=" as a peephole optimization and
replace it with the S= version.
--Brad
Alex McDonald
COMPARE can't check the length, since it has to determine collating
order. I think you mean STR= which can. Either way, I suspect VFX S=
does not use COMPARE.
Aleksej Saushev
> On Nov 30, 7:53 pm, Brad <hwfw...@gmail.com> wrote:
>> On Nov 26, 5:32 am, Alex McDonald <b...@rivadpm.com> wrote:
>>
>> > Given the preponderence of tests that are failed due to a length
>> > mismatch, a simple COMPARE 0= test is grossly inefficient in this
>> > case. A test for string equality prior to the COMPARE would appear to
>> > be of considerable benefit.
>>
>> When the lengths don't match, five instructions (including next,)
>> execute. But for all I know, COMPARE might already perform this
>> trivial test. If the off-the-shelf COMPARE isn't quite optimal, you
>> can always add the length test. My preference would be for the
>> compiler to recognize "COMPARE 0=" as a peephole optimization and
>> replace it with the S= version.
>
> COMPARE can't check the length, since it has to determine collating
> order. I think you mean STR= which can. Either way, I suspect VFX S=
> does not use COMPARE.
"STR=" should be equivalent to "COMPARE 0=", otherwise you introduce
unjustified inconsistency.
--
HE CE3OH...
Aleksej Saushev
> On Nov 30, 4:29 pm, Aleksej Saushev <a...@inbox.ru> wrote:
>
> [snipped points]
>>
>> I have no doubt at Win32Forth insignificance, since I have never heard
>> of any program written with it and used in the wild outside small Forth
>> community. To add to this, you have failed to find any code corpus
>> besides Win32Forth source.
>
> Your points are noted. Since I have not heard of you either, I shall
> assign them a corresponding weight in any revised RfD.
I haven't heard of you either. So, who are you to write proposals?
You don't understand requirements for research work we tell students
in course on science methodology. It was demonstrated above that
all you see is Win32Forth, and that Win32Forth makes the whole world to you.
You look only at implementation you passionatly love and not a step further.
An example of similar attitude is "novice" package that makes the whole world
for another person. You both found a way to optimise performance a little bit,
and now push your views into the world. The only difference between you is
that you patch up figures, methodologically invalid, to support your claims.
What makes you worse than your counterpart is that he doesn't claim (didn't
to the moment) insignificance of others' works based on his personal feelings.
"I can only guess at its significance, since the entire corpus of the
commentary is written in <some natural language>." These are your words,
they're not mine. It's you basing arguments on your ignorance.
You could as well have written, "I can only at its significance, since
the entire corpus is written in a different implementation." This wouldn't
change anything. You've dismissed several facts that are easy to check,
and, if you were honest researcher, you would have checked them already.
Alright, I doubt that you can read that much, I doubt that you have read
all that you've snipped above either. The whole this story shows that
you can't look further than your own sandbox. It is so much easier to
dismiss all the inconvenient world around than to bother with all those
rough facts.
--
HE CE3OH...
Alex McDonald
Sigh. Do you treat everyone and everything that you disagree with with
such disdain? While you may get off on being a pompous prat with
others, I'm afraid my patience with your snide remarks is at an end.
Please, do me a favour and take your superior attitude and shove it.
Aleksej Saushev
> Sigh. Do you treat everyone and everything that you disagree with with
> such disdain? While you may get off on being a pompous prat with
> others, I'm afraid my patience with your snide remarks is at an end.
> Please, do me a favour and take your superior attitude and shove it.
Talk like a serious man, and you'll be treated otherwise.
You have been pointed to several major defects in your research which
invalidate it as a basis for standardisation efforts. Address them
rather than invent evasions like a freshman, an incompetent worker,
or an old crackpot.
You also have been pointed to the way how to to fix your research
or at least to attempt to do so. Instead you chose to attack the most
tricky argument, the one that involves commercial server and desktop
user experience. If you really think that your proposal is an
improvement to all Forth implementations rather than to yours only,
you'd rather demostrate exactly that than dream up reasons why
experience of one or another major implementation should be ignored.
--
HE CE3OH...
Andrew Haley
>>> Alex McDonald <b...@rivadpm.com> writes:
>>> > On Nov 30, 4:29 pm, Aleksej Saushev <a...@inbox.ru> wrote:
>>>
>>> Alright, I doubt that you can read that much, I doubt that you have read
>>> all that you've snipped above either. The whole this story shows that
>>> you can't look further than your own sandbox. It is so much easier to
>>> dismiss all the inconvenient world around than to bother with all those
>>> rough facts.
>>
>> Sigh. Do you treat everyone and everything that you disagree with with
>> such disdain? While you may get off on being a pompous prat with
>> others, I'm afraid my patience with your snide remarks is at an end.
>> Please, do me a favour and take your superior attitude and shove it.
>
> Talk like a serious man, and you'll be treated otherwise.
Even if Alex's proposal was as hopeless as you think it is, you still
don't have any proper excuse for abuse. It's hardly likely to
persuade the person you're addressing or anyone else who reads your
post. The more you do this, the more you're guaranteeing that your
posts don't have any effect.
Andrew.