"Kris" <fu bar.com> writes:

Food for thought:

Java is explicit about the distinction between equality and identity, just
as D is. However, where D uses '==' as an equivalence operator, Java uses an
equals() method. Where D uses (triple) '===' and 'is' for identity purposes,
Java uses the traditional double '==' instead.

So, what's that got to do with the price of tea in China?

While porting 125,000 lines of Java to D, and an interesting thing happened.
You'll perhaps not be surprised to hear Java identity style tests are far
more prevalent than equivalence tests, but you may be surprised to know that
the former comprised 98.75% of all explicit tests within those 125,000
lines. To embellish, equals() was applied just 1.25% of the time.

Please note that we're talking about high-quality Java code that makes
extensive use of OO practices, and does indeed use equals() appropriately
when doing class comparisons. It's just that there's relatively little call
for that kind of thing once you get beyond writing sorting-algorithms,
containers, and so on. What I'd classify as "user-level code" appears to
apply equivalence testing rather seldom.

The Java code was converted mechanically, so it was thankfully easy to
change all identity tests into the D equivalent, which is the word 'is', or
the triplet '==='. Likewise, the inversion was converted from '!=' to the D
triplet '!=='. Each equals() instance was translated into the more
traditional twin '==' equivalence operator.

This has some notable ramifications; of which I'll attempt to be brief:

1) The converted Java code now has reams of  'is' statements throughout the
code, which makes it look 'interesting', to say the least. Quite nice,
actually; and eminantly readable, even vaguely amusing at times. The '!=='
instances look suitably alien by comparison. This amplifies the need for a
sibling for the word 'is', such as the oft proposes 'not' or the colloquial
'aint'.

BTW, using 'is' generates optimal code for that 98.75% of tests within that
large body of code. That is absolutely not the case when applying the
traditional operators instead. Look at the emitted codegen.

2) Anyone used to C or Java will habitually use the traditional '==' and
'!=' all over their D code. This is actually the *wrong* thing to do, since
those operators in D are for equivalence testing instead of identity
testing. This has implications for both performance and for "expectations of
behaviour". For example, the subsequent addition of an opEquals() to some
aggregate may break the overall system in all manner of subtle and
unexpected ways, where the original developer used '==' by force of habit.

3) Just as importantly, this highlights a significant divergence of D from C
and, IMO, in a rather fundamental manner. Think about this: you should
actually be using 'is' most of the time instead of (twin) '=='. How many of
you even use 'is' at all?

One might perhaps argue the numbers above are artificially inflated since
many of those test are applied to native types rather than to classes and
structs ~ that may be true. But we're talking about something that's already
well-developed as a habit in the community (the double '==') and we're
talking about consistency in the majority case.

I think D has perhaps made a serious blunder here. IMO, Java has the right
approach by maintaining compatability for the vast majority of usage, whilst
providing an option for testing "deep equivalence" via the equals() method
for the remaining small percentage.

D has effectively inverted that, and almost requires the adoption of a
different, and somewhat confusing, idiom to do what has been tradition for a
rather long time. The alternative is potentially error-prone code.

There's ostensibly nothing wrong with change, but it's not clear what the
benefit is here ~ if any?

At the very least, one has to mentally shift gears to perform identity tests
on classes and structs instead of native types. This would be OK if such
things were in the minority, but they're not. In the case noted above, one
has to continually shift gears for the overwhelming majority of tests.

Those of you who avoid OO like the plague will likely not be bothered by
such trivialities. For the rest, is it best to full embrace "is" and just
stick with it?

What sayeth ye?

- Kris

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

Common sense and anecdotal observations argues against the wisdom of 
lexing, never mind using, == and === / != and !==. You're correct in 
pointing out that your quantitative observation's Java-biased, but 
... [hang on while I divert power to the aft shields] ... I think 
D's going to end up being more Java-like than C++-like anyway, 
especially in the balance between value and reference semantics.

I'd be 100% behind === and !== being removed - after a deprecation 
phase - in favour of "is" and "isnot'.

(Contrarily, I'd have to say that I can't remember making any ==/=== 
or !=/!== transcription errors for some years, but then I am quite 
the language gadfly and probably not representative.)

Cheers

Charon


"Kris" <fu bar.com> wrote in message 
news:d37pdo$179t$1 digitaldaemon.com...
 Food for thought:

 Java is explicit about the distinction between equality and 
 identity, just
 as D is. However, where D uses '==' as an equivalence operator, 
 Java uses an
 equals() method. Where D uses (triple) '===' and 'is' for identity 
 purposes,
 Java uses the traditional double '==' instead.

 So, what's that got to do with the price of tea in China?

 While porting 125,000 lines of Java to D, and an interesting thing 
 happened.
 You'll perhaps not be surprised to hear Java identity style tests 
 are far
 more prevalent than equivalence tests, but you may be surprised to 
 know that
 the former comprised 98.75% of all explicit tests within those 
 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

 Please note that we're talking about high-quality Java code that 
 makes
 extensive use of OO practices, and does indeed use equals() 
 appropriately
 when doing class comparisons. It's just that there's relatively 
 little call
 for that kind of thing once you get beyond writing 
 sorting-algorithms,
 containers, and so on. What I'd classify as "user-level code" 
 appears to
 apply equivalence testing rather seldom.

 The Java code was converted mechanically, so it was thankfully 
 easy to
 change all identity tests into the D equivalent, which is the word 
 'is', or
 the triplet '==='. Likewise, the inversion was converted from '!=' 
 to the D
 triplet '!=='. Each equals() instance was translated into the more
 traditional twin '==' equivalence operator.

 This has some notable ramifications; of which I'll attempt to be 
 brief:

 1) The converted Java code now has reams of  'is' statements 
 throughout the
 code, which makes it look 'interesting', to say the least. Quite 
 nice,
 actually; and eminantly readable, even vaguely amusing at times. 
 The '!=='
 instances look suitably alien by comparison. This amplifies the 
 need for a
 sibling for the word 'is', such as the oft proposes 'not' or the 
 colloquial
 'aint'.

 BTW, using 'is' generates optimal code for that 98.75% of tests 
 within that
 large body of code. That is absolutely not the case when applying 
 the
 traditional operators instead. Look at the emitted codegen.

 2) Anyone used to C or Java will habitually use the traditional 
 '==' and
 '!=' all over their D code. This is actually the *wrong* thing to 
 do, since
 those operators in D are for equivalence testing instead of 
 identity
 testing. This has implications for both performance and for 
 "expectations of
 behaviour". For example, the subsequent addition of an opEquals() 
 to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force 
 of habit.

 3) Just as importantly, this highlights a significant divergence 
 of D from C
 and, IMO, in a rather fundamental manner. Think about this: you 
 should
 actually be using 'is' most of the time instead of (twin) '=='. 
 How many of
 you even use 'is' at all?

 One might perhaps argue the numbers above are artificially 
 inflated since
 many of those test are applied to native types rather than to 
 classes and
 structs ~ that may be true. But we're talking about something 
 that's already
 well-developed as a habit in the community (the double '==') and 
 we're
 talking about consistency in the majority case.

 I think D has perhaps made a serious blunder here. IMO, Java has 
 the right
 approach by maintaining compatability for the vast majority of 
 usage, whilst
 providing an option for testing "deep equivalence" via the 
 equals() method
 for the remaining small percentage.

 D has effectively inverted that, and almost requires the adoption 
 of a
 different, and somewhat confusing, idiom to do what has been 
 tradition for a
 rather long time. The alternative is potentially error-prone code.

 There's ostensibly nothing wrong with change, but it's not clear 
 what the
 benefit is here ~ if any?

 At the very least, one has to mentally shift gears to perform 
 identity tests
 on classes and structs instead of native types. This would be OK 
 if such
 things were in the minority, but they're not. In the case noted 
 above, one
 has to continually shift gears for the overwhelming majority of 
 tests.

 Those of you who avoid OO like the plague will likely not be 
 bothered by
 such trivialities. For the rest, is it best to full embrace "is" 
 and just
 stick with it?

 What sayeth ye?

 - Kris


 

David L. Davis <SpottedTiger yahoo.com> writes:

In article <d37ucp$1bbd$1 digitaldaemon.com>, Matthew says...
 ...

I'd be 100% behind === and !== being removed - after a deprecation 
phase - in favour of "is" and "isnot'.

 ...

I agree with Matthew on deprecating and removing the "===" and "!==" operators,
I've always felt that any operator that needs three operator symbols treads to
make the source code ugly and confusing to read...so it should probably be
spelled out anyway with a keyword. So, I think the current "is" was a good
replacement for "===", and that it makes perfect sense that "isnot" (but not
"aint", because it's simply bad grammar to use) would match up rather nicely to
replace "!==".

David L.

-------------------------------------------------------------------
"Dare to reach for the Stars...Dare to Dream, Build, and Achieve!"

"Andrew Fedoniouk" <news terrainformatica.com> writes:

Hi, Charon, :)

Python uses forms:

'is' ['not']
and also
['not'] 'in'

I am personally quite happy with
=== and !== too.

And for IsNot there is a US patent :)

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040230959%22.PGNR.&OS=DN/20040230959&RS=DN/20040230959

Andrew Cerberus.





"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message 
news:d37ucp$1bbd$1 digitaldaemon.com...
 Common sense and anecdotal observations argues against the wisdom of 
 lexing, never mind using, == and === / != and !==. You're correct in 
 pointing out that your quantitative observation's Java-biased, but ... 
 [hang on while I divert power to the aft shields] ... I think D's going to 
 end up being more Java-like than C++-like anyway, especially in the 
 balance between value and reference semantics.

 I'd be 100% behind === and !== being removed - after a deprecation phase - 
 in favour of "is" and "isnot'.

 (Contrarily, I'd have to say that I can't remember making any ==/=== or 
 !=/!== transcription errors for some years, but then I am quite the 
 language gadfly and probably not representative.)

 Cheers

 Charon


 "Kris" <fu bar.com> wrote in message 
 news:d37pdo$179t$1 digitaldaemon.com...
 Food for thought:

 Java is explicit about the distinction between equality and identity, 
 just
 as D is. However, where D uses '==' as an equivalence operator, Java uses 
 an
 equals() method. Where D uses (triple) '===' and 'is' for identity 
 purposes,
 Java uses the traditional double '==' instead.

 So, what's that got to do with the price of tea in China?

 While porting 125,000 lines of Java to D, and an interesting thing 
 happened.
 You'll perhaps not be surprised to hear Java identity style tests are far
 more prevalent than equivalence tests, but you may be surprised to know 
 that
 the former comprised 98.75% of all explicit tests within those 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

 Please note that we're talking about high-quality Java code that makes
 extensive use of OO practices, and does indeed use equals() appropriately
 when doing class comparisons. It's just that there's relatively little 
 call
 for that kind of thing once you get beyond writing sorting-algorithms,
 containers, and so on. What I'd classify as "user-level code" appears to
 apply equivalence testing rather seldom.

 The Java code was converted mechanically, so it was thankfully easy to
 change all identity tests into the D equivalent, which is the word 'is', 
 or
 the triplet '==='. Likewise, the inversion was converted from '!=' to the 
 D
 triplet '!=='. Each equals() instance was translated into the more
 traditional twin '==' equivalence operator.

 This has some notable ramifications; of which I'll attempt to be brief:

 1) The converted Java code now has reams of  'is' statements throughout 
 the
 code, which makes it look 'interesting', to say the least. Quite nice,
 actually; and eminantly readable, even vaguely amusing at times. The 
 '!=='
 instances look suitably alien by comparison. This amplifies the need for 
 a
 sibling for the word 'is', such as the oft proposes 'not' or the 
 colloquial
 'aint'.

 BTW, using 'is' generates optimal code for that 98.75% of tests within 
 that
 large body of code. That is absolutely not the case when applying the
 traditional operators instead. Look at the emitted codegen.

 2) Anyone used to C or Java will habitually use the traditional '==' and
 '!=' all over their D code. This is actually the *wrong* thing to do, 
 since
 those operators in D are for equivalence testing instead of identity
 testing. This has implications for both performance and for "expectations 
 of
 behaviour". For example, the subsequent addition of an opEquals() to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force of 
 habit.

 3) Just as importantly, this highlights a significant divergence of D 
 from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many 
 of
 you even use 'is' at all?

 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's 
 already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.

 I think D has perhaps made a serious blunder here. IMO, Java has the 
 right
 approach by maintaining compatability for the vast majority of usage, 
 whilst
 providing an option for testing "deep equivalence" via the equals() 
 method
 for the remaining small percentage.

 D has effectively inverted that, and almost requires the adoption of a
 different, and somewhat confusing, idiom to do what has been tradition 
 for a
 rather long time. The alternative is potentially error-prone code.

 There's ostensibly nothing wrong with change, but it's not clear what the
 benefit is here ~ if any?

 At the very least, one has to mentally shift gears to perform identity 
 tests
 on classes and structs instead of native types. This would be OK if such
 things were in the minority, but they're not. In the case noted above, 
 one
 has to continually shift gears for the overwhelming majority of tests.

 Those of you who avoid OO like the plague will likely not be bothered by
 such trivialities. For the rest, is it best to full embrace "is" and just
 stick with it?

 What sayeth ye?

 - Kris

 

Georg Wrede <georg.wrede nospam.org> writes:

Andrew Fedoniouk wrote:
 Hi, Charon, :)

...
 And for IsNot there is a US patent :)
 
 http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PG01&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.html&r=1&f=G&l=50&s1=%2220040230959%22.PGNR.&OS=DN/20040230959&RS=DN/20040230959

Does not apply to D.

So we can use isnot (or even IsNot) if we please.

Lars Ivar Igesund <larsivar igesund.net> writes:

Kris wrote:
 What sayeth ye?
 
 - Kris

I'm not sure that I got the use of these operators wrapped up correctly, 
but I like 'is', so I hope that it succeds (and possibly get a negative 
cousin into the language).

Lars Ivar Igesund

"Kris" <fu bar.com> writes:

That's a good point, Lars Ivar. I was also somewhat confused over the
distinction until this exercise. Perhaps I still am. I was, however,
relieved to discover "is" behaves in an equivalent manner for all types (as
it should; at least /one/ of 'em should :)

Can't help but feel something so fundamental should surely be trivial to
grasp, and be thoroughly consistent in its usage. Compared to Java, I think
D fails this sniff test quite badly WRT '==' and '!='. On the other hand,
"is" does pass that test.

Perhaps the real issue here, though, is whether 'is' should exist at all. I
personally like it, but then the continued and parallel existence of the
traditional '==' & '!=' confuses the waters badly; as you indicate.

I'll probably make an effort to provide equals() methods within library
classes and structs, to make usage clear, and to avoid user-mistakes over
'=='. At the very least, a deliberate avoidance of opEquals() will help to
alleviate common errors?

Is it perhaps better to /add/ opEquals() with a "static assert(0);" in it?
At least the intention would be made thoroughly clear, and the compiler
would catch those easy-to-make 'mistakes'?

That's a genuine question ...

Of course, such classes could not be used where opEquals() usage is implied
by D "built-in" functionality (things that should perhaps be in the library
instead). Messy.

- Kris


"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:d37unm$1buv$1 digitaldaemon.com...
 Kris wrote:
 What sayeth ye?

 - Kris

 I'm not sure that I got the use of these operators wrapped up correctly,
 but I like 'is', so I hope that it succeds (and possibly get a negative
 cousin into the language).

 Lars Ivar Igesund

Sean Kelly <sean f4.ca> writes:

In article <d380r6$1enu$1 digitaldaemon.com>, Kris says...
That's a good point, Lars Ivar. I was also somewhat confused over the
distinction until this exercise. Perhaps I still am. I was, however,
relieved to discover "is" behaves in an equivalent manner for all types (as
it should; at least /one/ of 'em should :)

Personally, I always use 'is' rather than '===.'  I find the latter form just a
bit too easy to misread, though I don't think I'm in much danger of mistyping
one when I mean the other.  I would love if there were an 'isnt' or something
similar in the language.

Can't help but feel something so fundamental should surely be trivial to
grasp, and be thoroughly consistent in its usage. Compared to Java, I think
D fails this sniff test quite badly WRT '==' and '!='. On the other hand,
"is" does pass that test.

Perhaps the real issue here, though, is whether 'is' should exist at all. I
personally like it, but then the continued and parallel existence of the
traditional '==' & '!=' confuses the waters badly; as you indicate.

I think the traditional operators should stay as-is for the sake of consistency.
If '==' were changed to be an identity comparison then the other comparison
operators would need to change as well (<, >, etc).  And I don't see a reason to
have all those operators compare addresses instead of object contents.

As an aside, how are address comparisons handled on NUMA machines?  I know
std::less in C++ is required to work for pointers, but I don't have any
experience with machines where such comparisons might be a tad odd.

I'll probably make an effort to provide equals() methods within library
classes and structs, to make usage clear, and to avoid user-mistakes over
'=='. At the very least, a deliberate avoidance of opEquals() will help to
alleviate common errors?

Probably a good idea for the Java folks, though I'm not likely to use them.  But
as a library programmer I'm probably more likely to use equivalence comparisons
than identity comparisons anyway.

Is it perhaps better to /add/ opEquals() with a "static assert(0);" in it?
At least the intention would be made thoroughly clear, and the compiler
would catch those easy-to-make 'mistakes'?

It would be better IMO to remove opEquals from Object if it's there.
Compile-time errors are always preferable to run-time errors.


Sean

Georg Wrede <georg.wrede nospam.org> writes:

Kris wrote:
 Food for thought:
 
 Java is explicit about the distinction between equality and identity,
 just as D is. However, where D uses '==' as an equivalence operator,
 Java uses an equals() method. Where D uses (triple) '===' and 'is'
 for identity purposes, Java uses the traditional double '==' instead.
 
 
 So, what's that got to do with the price of tea in China?
 
 While porting 125,000 lines of Java to D, and an interesting thing
 happened. You'll perhaps not be surprised to hear Java identity style
 tests are far more prevalent than equivalence tests, but you may be
 surprised to know that the former comprised 98.75% of all explicit
 tests within those 125,000 lines. To embellish, equals() was applied
 just 1.25% of the time.
 
 Please note that we're talking about high-quality Java code that
 makes extensive use of OO practices, and does indeed use equals()
 appropriately when doing class comparisons. It's just that there's
 relatively little call for that kind of thing once you get beyond
 writing sorting-algorithms, containers, and so on. What I'd classify
 as "user-level code" appears to apply equivalence testing rather
 seldom.

This does make one think.

Traditionally, the problem with new languages is, they are discussed and 
tested with relatively small programs or snippets. The _problem_ here is 
that small programs are both structurally and statistically different 
from large programs. People tend to not ponder these possible 
differences -- at all.

The same phenomenon is markedly visible when teaching programming 
languages. The new coder's first largish program tends to have the same 
overall structure (stretched out) as the homework programs. (This 
results in only a few bloated classes, or overly long procedures / 
functions.)

Small programs use proportionally less OO (in general). The smaller the 
program, or the less OO it contains, the larger the proportion of 
equality tests compared to identity tests.

This naturally leads to myopia that hampers judgment when discussing, 
say, choice of operators.

 The Java code was converted mechanically, so it was thankfully easy
 to change all identity tests into the D equivalent, which is the word
 'is', or the triplet '==='. Likewise, the inversion was converted
 from '!=' to the D triplet '!=='. Each equals() instance was
 translated into the more traditional twin '==' equivalence operator.
 
 This has some notable ramifications; of which I'll attempt to be
 brief:
 
 1) The converted Java code now has reams of  'is' statements
 throughout the code, which makes it look 'interesting', to say the
 least. Quite nice, actually; and eminantly readable, even vaguely
 amusing at times. The '!==' instances look suitably alien by
 comparison. This amplifies the need for a sibling for the word 'is',
 such as the oft proposes 'not' or the colloquial 'aint'.
 
 BTW, using 'is' generates optimal code for that 98.75% of tests
 within that large body of code. That is absolutely not the case when
 applying the traditional operators instead. Look at the emitted
 codegen.
 
 2) Anyone used to C or Java will habitually use the traditional '=='
 and '!=' all over their D code. This is actually the *wrong* thing to
 do, since those operators in D are for equivalence testing instead of
 identity testing. This has implications for both performance and for
 "expectations of behaviour". For example, the subsequent addition of
 an opEquals() to some aggregate may break the overall system in all
 manner of subtle and unexpected ways, where the original developer
 used '==' by force of habit.
 
 3) Just as importantly, this highlights a significant divergence of D
 from C and, IMO, in a rather fundamental manner. Think about this:
 you should actually be using 'is' most of the time instead of (twin)
 '=='. How many of you even use 'is' at all?
 
 One might perhaps argue the numbers above are artificially inflated
 since many of those test are applied to native types rather than to
 classes and structs ~ that may be true. But we're talking about
 something that's already well-developed as a habit in the community
 (the double '==') and we're talking about consistency in the majority
 case.
 
 I think D has perhaps made a serious blunder here. IMO, Java has the
 right approach by maintaining compatability for the vast majority of
 usage, whilst providing an option for testing "deep equivalence" via
 the equals() method for the remaining small percentage.

A problem with bringing this up is, that to most, this may seem like an 
unimportant issue. So, why bother to change, or even think hard enough 
about this -- there are "more practical" things open at the moment.

It's good you brought it up now, before it's too late to even discuss this.

Since we aim for D to become used in large projects, this really is 
important. While I personally don't here present an explicit opinion on 
the issue itself, I do think this should be carefully discussed, right 
now, before D1.0.

When discussing, we should keep in mind, that the audience here may not 
represent the D programmers 3 years from now. If D succeeds, then most 
will be doing "user level coding" in large projects, and D should become 
superior in that use. But today, many of us do one-person projects, 
library writing, compiler writing [ ;-) ], or lab experiments on syntax 
and semantics, or compiler bugs.

This biases our opinions, and whenever one does not notice it himself, 
it exacerbates the difficulties of really seeing where we should be 
going with D.

 D has effectively inverted that, and almost requires the adoption of
 a different, and somewhat confusing, idiom to do what has been
 tradition for a rather long time. The alternative is potentially
 error-prone code.
 
 There's ostensibly nothing wrong with change, but it's not clear what
 the benefit is here ~ if any?
 
 At the very least, one has to mentally shift gears to perform
 identity tests on classes and structs instead of native types. This
 would be OK if such things were in the minority, but they're not. In
 the case noted above, one has to continually shift gears for the
 overwhelming majority of tests.

There's so much legacy in this room, it begs for explanation why this 
difference was introduced in D. If the explanation is good, then fine, 
let's keep it -- but definitely not for "just because".

 Those of you who avoid OO like the plague will likely not be bothered
 by such trivialities. For the rest, is it best to full embrace "is"
 and just stick with it?
 
 What sayeth ye?
 
 - Kris
 
 
 

"Unknown W. Brackets" <unknown simplemachines.org> writes:

To me it's not confusing.  I've worked with Java fairly little, and with 
other languages such as C and PHP more.

PHP implements many things in a very similar way to D.  I actually 
expect this to be a good thing for D, considering both PHP's popularity 
and relative slowness compared to D.

A good example is concatenation, as PHP also uses a separate operator - 
although, it uses . instead of ~, and forces the use of -> for 
OOP/structs/etc.  That said, PHP is not as OOP friendly as the languages 
you're likely used to, and most people either don't use it or use it 
incorrectly (overlord classes are too common.)

For this, which is my point (sorry), PHP is also similar.  It's 
different, because PHP is weakly typed, but consider the following code:

function func($test)
{
    static $i;

    if ($test == '+')
       return ++$i;
    else
       return $i + (int) $test;
}

Surely, you can see the immediate differences between PHP and most other 
langauges right away.  But, because of this, you won't see the *MISTAKE* 
I made in the above code (purposefully, though.)  It is the subject of 
your post - ==.

Why?  Because if I call func() with 0 as an argument here, the test will 
return TRUE.  You'll remember that in weakly typed languages, this:

$test == '+'

Will cast down to the following if $test is an int:

$test == (int) '+'

Which is clearly true (since casting, in weakly typed languages, 
converts) when $test is zero (as PHP has no NaN.)

The solution here is, again, ===.  It means "equal without conversion". 
  Since PHP has no pointers, this is the strictest way to test.  It's 
also - according to benchmarks - much faster.

The way I write PHP code, at least, I'm always aware of the type of any 
given variable (or, if not, I know the type is unknown.)  As such, the 
operator I want to use is not ==.  Most of the time, I should be using 
=== - it's error checking, for one thing.

Now, as someone heavily indoctrinated into OOP, I can imagine you saying 
this has absolutely nothing to do with your post.  I disagree.  Your 
post has nothing to do with OOP, but rather with operators, their 
meanings, and the use thereof.

You're saying that the "change" D has made is wrong.  Thus, you're also 
saying that the order for the symbols PHP took is wrong, since it took 
the same order (even though they mean different things.)  Again, I disagree.

D is not a child of Java.  D isn't necessarily expecting a throng of 
Java programmers to convert their code from Java to D.  Indeed, 
considering it has bugs in its OOP this is unlikely imho.  No, D came 
from C.  PHP, also, as weakly typed as it is, came from C.

And thus, they both made the right choices.  Seems to have paid off for 
the language used on over 30% of webservers on the internet (I think it 
was mroe, can't remember.)

Clearly, it would have been a horrible mistake if PHP had been looking 
for programmers to come out of the woodwork from Java and switch to PHP. 
  I don't think that was their intention.  Is it D's?

-[Unknown]


 D has effectively inverted that, and almost requires the adoption of a
 different, and somewhat confusing, idiom to do what has been tradition for a
 rather long time. The alternative is potentially error-prone code.
 
 There's ostensibly nothing wrong with change, but it's not clear what the
 benefit is here ~ if any?
 
 At the very least, one has to mentally shift gears to perform identity tests
 on classes and structs instead of native types. This would be OK if such
 things were in the minority, but they're not. In the case noted above, one
 has to continually shift gears for the overwhelming majority of tests.
 
 Those of you who avoid OO like the plague will likely not be bothered by
 such trivialities. For the rest, is it best to full embrace "is" and just
 stick with it?
 

"Kris" <fu bar.com> writes:

"Unknown W. Brackets" <unknown simplemachines.org> wrote in message
<snip>
 The way I write PHP code, at least, I'm always aware of the type of any
 given variable (or, if not, I know the type is unknown.)  As such, the
 operator I want to use is not ==.  Most of the time, I should be using
 === - it's error checking, for one thing.

Excellent!


 Now, as someone heavily indoctrinated into OOP, I can imagine you saying
 this has absolutely nothing to do with your post.  I disagree.

Eh? You're making some truly wild assertions there. You might as well claim
I'm currently sitting in the air on the sharp end of a twenty foot pole,
with a chicken strapped to my head and a dancing-bear performing the can-can
on my shoulder. I mean, really ...


Your
 post has nothing to do with OOP, but rather with operators, their
 meanings, and the use thereof.

Duh. The point I raised is particularly noticeable with aggregates, in that
one often has to mentally switch gears to use "is", rather than just using
'= =' as one would with native types.

You may have missed the postulation entirely, WB, so I'll spell it out to
you again ~ it's perhaps easier, from the point of consistency, to just
adopt the usage of "is" /all of the time/, with native types too, rather
than switching back and forth between "is" and '= =' (98.75% of the time, in
the example given). If so, that begs the question: why have both forms?
(there's a further, implied, postulation. But we'll ignore that).

If you don't use aggregates, or you are someone who never, ever, makes a
mistake, then you can happily ignore the post in its entirety. However,
there's almost 8000 explicit tests in that particular body of code. When one
has to constantly think about which operator to use in which context, to get
the /same/ job done, how many mistakes will be made? The fact that '= = ='
is so close to '= =' just serves to amplify the issue (not to mention that
some printers make them look almost identical). This is why I wonder (aloud)
whether just using "is", for everything, is ultimately a better way to go.
If you just don't like "is" then simply state so.


 You're saying that the "change" D has made is wrong.  Thus, you're also
 saying that the order for the symbols PHP took is wrong, since it took
 the same order (even though they mean different things.)  Again, I

disagree.

Given the tenuous and questionable context you pose, I truly don't give a
rat's ass what PHP did or does. You're more than welcome to draw such
conclusions and comparisons for yourself.

The point was that of potential confusion. Again, the postulation was that
it's perhaps better to just use "is" (and its as-yet non-existing companion)
for the overwhelming majority of cases (98.75% in the example given) and use
either '= =' (or perhaps even an equals() method) for the remaining cases
where a true "deep equivalence" is required.

Lest ye forget, the post was directed towards a final question mark ("fully
embrace 'is' ?"). In addition, the post was clearly marked as "food for
thought". If you wish to extract vast quantities of coal from there, go
right ahead. The reason for posting was to give pause for a wee bit of
reflection.

Instead, (given your earlier assertions upon my personal intent,
preferences, and likely answers) you appear to be somewhat upset and taking
it as flame bait. That's too bad, so I'll ask you to read it again with a
touch more levity. Or don't bother. Your choice.

Additionally, you're focusing on just one aspect. There's more to that post
than just some thoughts on whether D did the right thing or not when
introducing five (somewhat overlapping) operators to do exactly the same job
that three can do. Think about it.


 D is not a child of Java.  D isn't necessarily expecting a throng of
 Java programmers to convert their code from Java to D.  Indeed,
 considering it has bugs in its OOP this is unlikely imho.  No, D came
 from C.  PHP, also, as weakly typed as it is, came from C.

Seems to me like you seriously misread the post, since you apparently just
veered off the road and into the ocean. Java just happened to be the
comparison point since it was the source of the example (it also happens to
be considerably closer to D than you may care to admit. But just exactly who
cares if it is?)


 And thus, they both made the right choices.  Seems to have paid off for
 the language used on over 30% of webservers on the internet (I think it
 was mroe, can't remember.)
 Clearly, it would have been a horrible mistake if PHP had been looking
 for programmers to come out of the woodwork from Java and switch to PHP.
   I don't think that was their intention.  Is it D's?

Hmmm.  You're off on an entirely different topic than I.  Would be happy to
join your new thread on that particular subject, if you like.

"Unknown W. Brackets" <unknown simplemachines.org> writes:

I'll try to be short, since then there's less to misconstrue:

Firstly, I said:
 Now, as someone heavily indoctrinated into OOP, I can imagine...

This means, "knowing that you like OOP, I am worried that you will 
believe the above...".  It was not an assertion, not a poke, not 
anything more than an admittance of fear (that you would not understand 
my meaning.)  My fear, not yours - the statement had little to do with 
you, indeed.

I'm sorry you took me wrong.

Now, let me try again with my example.

PHP:

$x = 'test';
$y = 'test';
$x == $y;

C++:

x = new string("test");
y = new string("test");
x == y;

D:
x = "test";
y = "test";
x == y;

Java:

x = "test";
y = "test";
x.equals(y);

Which one is different?  My childhood experience with Sesame Street 
allows me to point immediately to Java.  Do I get a gold star?

I agree that comparing, in very very many cases especially with 
aggregates - and even in some with strings, is the Right Thing (tm).  I 
am not arguing about that, in any way, shape, or form.  Please do not 
misunderstand me.

I'm simply saying that as much as this is the Right Thing (tm), it's 
wrong because other languages don't do it, and clearly that means it 
would be confusing if D reversed their meanings.

Of course, it's true that the following are equivalent:

5 == 5
5 === 5

So, it wouldn't be *that* bad, but it would still be different from C++.

I agree that D is a movement toward Java, and again please do not 
misunderstand or misconstrue my meaning when I say that I don't frankly 
care.  That's not the point.  I am trying to say that D came from C++, 
and so it makes sense to act more like C++ if there's a possibly 
confusing point.

And, surely, this is not something you would propose for after 1.0, is 
it?  I mean, obviously it would break code.... so you mean it for 1.0, 
then, right?

-[Unknown]

"Kris" <fu bar.com> writes:

"Unknown W. Brackets" <unknown simplemachines.org>
 Firstly, I said:
  > Now, as someone heavily indoctrinated into OOP, I can imagine...

 This means, "knowing that you like OOP, I am worried that you will
 believe the above...".  It was not an assertion, not a poke, not
 anything more than an admittance of fear (that you would not understand
 my meaning.)  My fear, not yours - the statement had little to do with
 you, indeed.

Thanks for the clarification.


 Now, let me try again with my example.

<snip>

All clear and understood :)


 And, surely, this is not something you would propose for after 1.0, is
 it?  I mean, obviously it would break code.... so you mean it for 1.0,
 then, right?

This explains a lot.

I was quite careful not to propose any change to D at all, other than noting
further evidence for a companion to "is" (such as "not", or whatever).

It was "food for thought" only, and a reflection of one persons experience
porting a rather significant chunk of what I consider high-quality "user
level code" to D. If you, and others, feel D should change in some related
way then I'll likely support that. But, frankly, I'm really tired of trying
to foster change in D itself.

This was merely a "Hey! Did you know?", since it was clear to me I'd had a
certain quality of snow-blindness WRT this particular area of D. There was
big question-mark as to whether it was even worth bothering to post.

If you're asking my opinion whether a change should be made pre-release,
then I'll repeat what was noted earlier: D has five operators to do exactly
the same job of three. That, alone, should give us all some pause.

- Kris

"Unknown W. Brackets" <unknown simplemachines.org> writes:

I hope you'll forgive me then; when I see things like this:

 I think D has perhaps made a serious blunder here.

I read "please change the above."  So, it seems we both jumped to 
conclusions and read what did not exist between the lines...

Personally, and call me crazy, I like the way it's done here.  If I was 
used to === instead of ==, I might want to reverse it, but I've already 
explain that at length.

To me, it just seems silly when you can do this:

if (instance + 5 > 0)

But you have to do this:

if (instance.equals(5))

If we're not to have an operator for "equal in value", why bother with 
+, -, >, <, or others?  We could have instance.add, subtract, 
isLessThan, and similar... and they'd be more readable, too, just like 
equals.

As much as you described that is/=== was used more than ==, how much 
were they used in comparison to other operators?

I say this only because those other operators work on the value of the 
variable just as clearly as == does, at least in D.  When would you ever 
  use them if they worked on the pointer or some such?

A counterargument there, I think, is that while an aggregate could 
theoretically be easily/efficiently identified as less than or greater 
than another, it might be a bit more "heavy" to check if it is, 
completely, equal to a peer aggregate.

Just food for thought, as well - sorry again for my misunderstanding.

And, as for == when there's no instance, I feel pretty strongly 
(although I haven't mentioned it prior) that - especially as you note 
that value checks are often uncommon - they should have an error 
message, except in release mode.

Meaning, this:

if (instance == 5)

Would be equivalent to:

if (instance === null)
    throw new UninitializedReferenceException(); // e.g.
if (instance == 5)

Not even necessarily for other operators/method calls, because that 
would get slow.  But, it seems as if it might be a common error.  Of 
course, this likely won't float (or rather rock) anyone's, least of all 
Walter's, boat.


and it does roughly this.  But, it would be much easier for those new to 
the language, and if it send along its filename and line possibly even 
easier to debug.

-[Unknown]


 This explains a lot.
 
 I was quite careful not to propose any change to D at all, other than noting
 further evidence for a companion to "is" (such as "not", or whatever).
 
 It was "food for thought" only, and a reflection of one persons experience
 porting a rather significant chunk of what I consider high-quality "user
 level code" to D. If you, and others, feel D should change in some related
 way then I'll likely support that. But, frankly, I'm really tired of trying
 to foster change in D itself.
 
 This was merely a "Hey! Did you know?", since it was clear to me I'd had a
 certain quality of snow-blindness WRT this particular area of D. There was
 big question-mark as to whether it was even worth bothering to post.
 
 If you're asking my opinion whether a change should be made pre-release,
 then I'll repeat what was noted earlier: D has five operators to do exactly
 the same job of three. That, alone, should give us all some pause.
 
 - Kris

Ben Hinkle <Ben_member pathlink.com> writes:

What sayeth ye?

I agree Java, C and C++ programmers will get burned often in porting code and
using == when they should use "is". I've caught myself typing "is" and !== in
C++ code so I've started to go to the D side :-)
It would be nice to somehow make == so that it doesn't seg-v on a null object
reference. I started to feel a little better about == after realizing a dlint
can flag "obj == null". 
Still, it is annoying to catch my fingers coding in the wrong language, though.

-Ben

"Kris" <fu bar.com> writes:

"Ben Hinkle" <Ben_member pathlink.com> wrote in message
news:d3a3bv$107b$1 digitaldaemon.com...
What sayeth ye?

 I agree Java, C and C++ programmers will get burned often in porting code

and
 using == when they should use "is". I've caught myself typing "is" and !==

in
 C++ code so I've started to go to the D side :-)

Me too :-)

I had someone looking over my shoulder the other day, whilst writing some
Java, and was asked just what the heck was I typing ...

Anyway. Thanks for reading and 'getting' the point of the post.


 It would be nice to somehow make == so that it doesn't seg-v on a null

object
 reference. I started to feel a little better about == after realizing a

dlint
 can flag "obj == null".

(does it still do that? I tried briefly a week or two ago, and it seemed to
catch the null correctly. But looking at the codegen is when I realized my
own personal blindness on this subject, and just how badly I needed to use
"is" everywhere instead)

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

 This has some notable ramifications; of which I'll attempt to be brief:
 
 1) The converted Java code now has reams of  'is' statements throughout the
 code, which makes it look 'interesting', to say the least. Quite nice,
 actually; and eminantly readable, even vaguely amusing at times. The '!=='
 instances look suitably alien by comparison. This amplifies the need for a
 sibling for the word 'is', such as the oft proposes 'not' or the colloquial
 'aint'.

And something tells me that it didn't look very tempting to rewrite the
"x !== y" with the officially sanctioned workaround "!(x is y)", right ?
(like the equally ugly "version (Foo) {} else" workaround for #ifndef)

Wonder that if there wasn't a "!==" already, if "isnot" would be all 
that popular ? For instance, there is no negative alternative for "in" ?
(And for some reason, the Perl construct "unless" is still not popular)


Anyway, like you say - mixing "is" and "!==" does look outlandish....
But I'm in the "why not have all four of them" camp myself, as usual.
Adding "isnot" keyword for TOKnotidentity is trivial, I posted a patch ?

The only uncertaintanty was the spelling thereof, but that might be
big enough of an issue to kill the entire keyword... I also suggested
the alternative "~is", in celebration of the D destructor syntax. :-)


 2) Anyone used to C or Java will habitually use the traditional '==' and
 '!=' all over their D code. This is actually the *wrong* thing to do, since
 those operators in D are for equivalence testing instead of identity
 testing. This has implications for both performance and for "expectations of
 behaviour". For example, the subsequent addition of an opEquals() to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force of habit.

I think the "problem" is that D mixes two different paradigms into one ?

C:
   x = "test"; // const pointer
   y = "test";
   strcmp(x,y) == 0; // equality
   x == y; // identity

Java:
   x = "test"; // String object
   y = "test";
   x.equals(y); // equality
   x == y; // identity

D:
   x = "test"; // dynamic array
   y = "test";
   x == y; // equality
   x is y; // identity

Perhaps this was a lame example, since "x.equals(y)" in all - due to 
string pooling, and that it doesn't show the similarity to primitives ?

   i = 1;
   j = 1;
   assert(i == j); // equality

Or if one checks for "less than" instead ?

C:    strcmp(x,y) < 0;
Java: x.compareTo(y) < 0;
D:    x < y;

Since D mixes two paradigms, it has some extra traps than C / Java...
For instance, "struct", "struct*" and "Object" works very differently ?
(the exception to the rule being the pointer type, not too surprisingly)
Regular structs => http://www.digitalmars.com/d/ctod.html#structcmp,
where as pointers or references work as C (memcmp) or Java (equals)

But in *isolation*, the D approach is very short and clean - compared...
And one can still use "is" with pointers too in D, just be consistant.

 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.

I think D has made a good choice, but you are right - it is not very 
"compatible". (at least not to Java, it should be compatible with C)
Guess it boils down to how important this compatibility is, for D ?

In my opinion (and code), the most common use of identity is "!== null",
and that has already been beaten to death - with the widespread use of 
"assert(x);" or "if (y) { }" - I think ? (due to the lack of booleans).
It would also be good if the compiler could catch "== null", "!= null",
and other constructs that are a runtime NullError waiting to happen...
(or re-define the meaning of equals for null, as is discussed below)

But changing D to make it behave like Java ? Not sure it's a good idea.
Since people confuse equality and identity all the time there, too ?


And, by accident, I stumbled upon this interesting proposal via Google:
http://cdsmith.twu.net/professional/java/pontifications/comparison.html
(from 2001, suggesting to add a '===' operator to the Java language...)

It featured the good suggestion of making '==' *not* throw Exceptions:



     if both objects are non-null.

AFAIK, that in theory/pseudo-code is done by modifying "_d_obj_eq" ?

dmd/src/phobos/internal/obj.d:
   -13,6 +13,7   

  int _d_obj_eq(Object o1, Object o2)
  {
+    if (o2 is null) return o1 is null; else
      return o1 is o2 || (o1 && o1.opEquals(o2));
  }

I'm *not* sure whether that's all the DMD change that is needed...
(it probably needs some more internal code-gen changes, as well)

But it would be nice if comparisions with null were *defined* in D,
other than to instead invoke a implementation-defined behaviour... ?
(segfault / bus error, or throw RuntimeError("access violation"))

http://www.digitalmars.com/d/expression.html#EqualExpression:
   "For class objects, equality is defined as the result of calling
    Object.opEquals(). If one or the other or both objects are null,
    an exception is raised."

Avoiding this null-dereference would be a nice change to D, I think.
I'm not sure if it would have any negative sides ? Does anyone else ?
(it seems to be working just fine for "null" D strings and arrays...)

--anders

novice3 <novice3_member pathlink.com> writes:

hello all

whats the problem with !is instead of isnot ?
of course it looks better with the syntax highlighting...

=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:

novice3 wrote:

 whats the problem with !is instead of isnot ?
 of course it looks better with the syntax highlighting...

"!" is not usually part of such words, but "~is" could work ?
(where ~/tilde is the binary "not" symbol, used in destructor)

Both would need a extension of the allowed keyword characters.
I just think that ~ would look more like part of the keyword ?

And I guess most people would prefer reading "is!", than "!is",
("is not" versus "not is") and is! does have parsing problems...

Save ! for the (ugly) recommended "!(x is y)" syntax, perhaps ?
<http://www.digitalmars.com/d/expression.html#EqualExpression>


Binary (bitwise) not: (the "one's complement")
    unary ~ : ~0 == -1

Array concatenation: (combines the two arrays)
   binary ~ : "a" ~ "b"

Constructor:
              this();

Destructor:
              ~this(); // "not constructor"


Then again, I'm not sure how it works out in practice ?
   writef("%s",foo ~ bar);
   assert(param ~is null);
   data[bitnum >> 5] &= ~(1L << (bitnum & 31));
Hmm... Perhaps not all *that* great, but it limps along ?

And it *would* avoid all the spelling issues of "isnot"...
(isnt, isnot, aint, "isn't", "ain't", "is not", iSnot, etc)


Assuming that ~/tilde is added to the allowed id characters,
and '!==' commented out just like '===' is, it would be like:

    {	"is",		TOKidentity	},  // ===, '≡'
    {	"~is",		TOKnotidentity	},  // !==, '≢'

So I think I will change my current (ignored) feature suggestion
of "isnot", into the even more obscure "~is" keyword instead...

http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList


Assuming for a second that the D "this" and "~this" syntax was
better than adding new keywords, like "construct" / "destruct" ?

And I don't think that the '===' and '!==' should be removed,
just that 'is' (possibly '~is') should be the preferred form.

It would of course be possible to add "~in" too, but with the
current pointer syntax I'm not not sure what it would return ?

--anders

spock (ex novice3) <spock_member pathlink.com> writes:

In article <d3bea0$2ijr$1 digitaldaemon.com>,
=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= says...
novice3 wrote:

 whats the problem with !is instead of isnot ?
 of course it looks better with the syntax highlighting...

"!" is not usually part of such words, but "~is" could work ?
(where ~/tilde is the binary "not" symbol, used in destructor)

Both would need a extension of the allowed keyword characters.
I just think that ~ would look more like part of the keyword ?

And I guess most people would prefer reading "is!", than "!is",
("is not" versus "not is") and is! does have parsing problems...

Save ! for the (ugly) recommended "!(x is y)" syntax, perhaps ?
<http://www.digitalmars.com/d/expression.html#EqualExpression>


Binary (bitwise) not: (the "one's complement")
    unary ~ : ~0 == -1

Array concatenation: (combines the two arrays)
   binary ~ : "a" ~ "b"

Constructor:
              this();

Destructor:
              ~this(); // "not constructor"


Then again, I'm not sure how it works out in practice ?
   writef("%s",foo ~ bar);
   assert(param ~is null);
   data[bitnum >> 5] &= ~(1L << (bitnum & 31));
Hmm... Perhaps not all *that* great, but it limps along ?

And it *would* avoid all the spelling issues of "isnot"...
(isnt, isnot, aint, "isn't", "ain't", "is not", iSnot, etc)


Assuming that ~/tilde is added to the allowed id characters,
and '!==' commented out just like '===' is, it would be like:

    {	"is",		TOKidentity	},  // ===, '≡'
    {	"~is",		TOKnotidentity	},  // !==, '≢'

So I think I will change my current (ignored) feature suggestion
of "isnot", into the even more obscure "~is" keyword instead...

http://www.prowiki.org/wiki4d/wiki.cgi?FeatureRequestList


Assuming for a second that the D "this" and "~this" syntax was
better than adding new keywords, like "construct" / "destruct" ?

And I don't think that the '===' and '!==' should be removed,
just that 'is' (possibly '~is') should be the preferred form.

It would of course be possible to add "~in" too, but with the
current pointer syntax I'm not not sure what it would return ?

--anders

ok

"~" (bitwise negation) is less appropriate than "!" (logical negation)

"~" is used in destructor too but in method header: it's readable

as you notice, "~" is used for concatenation... things are going complicated

so i understand mixing "!" with keyword is not usual, but it should be since
we need it for at least too keyword, is & in and the workaround are not
practical
for a non english like me, aint isn't or ain't is just shocking in a computer
language

==  -->  !=
is  -->  !is
in  -->  !in

any other way seems illogical to me captain kirk

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

spock (ex novice3) wrote:

 "~" (bitwise negation) is less appropriate than "!" (logical negation)

Since D uses "bit" for booleans, they're not all that different... ;-)

Seriously, any of them would do. Just thought it would be less likely
to be mixed up with the normal use, since it's "out of context" here ?

So just the fact that it is less apropriate, actually makes it "better".

 so i understand mixing "!" with keyword is not usual, but it should be since
 we need it for at least too keyword, is & in and the workaround are not
 practical

The workaround is just that, a way around the missing feature...
(unfortunate in this case, since it's about a deprecated feature)

In this case, it looks better to continue with '===' and '!=='
instead of switching to an "is" operator that lacks a negative.

But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
Either way, it needs *some* kind of new token for the not variant!

Both of '!' and '~' needs changes to the current lexer, though...
(and then one might as well add "is not", and be done with it ?)

 for a non english like me, aint isn't or ain't is just shocking in a computer
 language

I don't think they're going to make it, either...
But "isn't" is (just a little) better than "isnt".

 ==  -->  !=

   === -->  !==
 is  -->  !is
 in  -->  !in
 
 any other way seems illogical to me captain kirk

What's the "not" of a pointer ? (like the "in" operator returns now)
For the boolean "in" it makes perfect sense. Just not for the D one.
Or do you mean that the "not in" operator should make the D lack of
booleans the preferred way, and behave the same as (!(key in hash)) ?

It would be nice if there could be a *good* solution to the current
"isnot" (TOKnotidentity) and possibly "notin" (much less used, though), 
and why not the AA problems of "delete" (remove a key from an AA) too.
Currently all changes to them, seem stopped by fear of new D keywords ?

I have "submitted" two horrible puns and hacks, in lack of any others
i.e. "~is" and "out", to match the "is" and "in" expressions... :-)
They're a little better than the old ones, IMHO, but not very much ?
Then again, I didn't have much problems with the old '===' syntax.

Just thought that mixing use of 'is' and '!==' was somewhat strange.

--anders

Georg Wrede <georg.wrede nospam.org> writes:

Anders F Björklund wrote:
 spock (ex novice3) wrote:
 
 "~" (bitwise negation) is less appropriate than "!" (logical
 negation)

 
 
 Since D uses "bit" for booleans, they're not all that different...
 ;-)

AAARRGHHHHHHHHH!!!!!!!

  >:-Q

"A one bit boolean makes a two-bit language."  :-(

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5E89.70605 nospam.org...
 Anders F Björklund wrote:
 spock (ex novice3) wrote:

 "~" (bitwise negation) is less appropriate than "!" (logical
 negation)


 Since D uses "bit" for booleans, they're not all that 
 different...
 ;-)

 AAARRGHHHHHHHHH!!!!!!!

  >:-Q

 "A one bit boolean makes a two-bit language."  :-(

No argument from me there. 

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Georg Wrede wrote:

 Since D uses "bit" for booleans, they're not all that different...
 ;-)

 
 AAARRGHHHHHHHHH!!!!!!!

Hey, it wasn't the meaning to ruin your morning or anything...
(seems like those battle scars haven't healed enough for a joke)

Let's just pretend that D now *has* a boolean type called "bool",
which can take the values "true" and "false". It's near enough.

One day, hopefully soon, Walter will see the light - and then
the code will be all ready for it. Let's lead by example here ?

It's just a missed opportunity, not the end of world or anything...
And if it was good enough for C and C++, I guess D can limp along ?

// this is perfectly legal code already:
assert(false);

Let's talk about something else, shall we ? Like adding "isnot"
and be done with that discussion too. There's real stuff to do :-)

--anders

Georg Wrede <georg.wrede nospam.org> writes:

Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

Damn, folks! What's so horribly wrong with isnot??????

We have foreach, and nobody seems to jump in the river Styx!

"Regan Heath" <regan netwin.co.nz> writes:

On Mon, 11 Apr 2005 14:28:53 +0300, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

 Damn, folks! What's so horribly wrong with isnot??????

i-snot perhaps?

 We have foreach, and nobody seems to jump in the river Styx!

Personally, I have no problem with isnot, aint, isnt..

Regan

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5F75.3060405 nospam.org...
 Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky 
 ?
 Either way, it needs *some* kind of new token for the not 
 variant!

 Damn, folks! What's so horribly wrong with isnot??????

Nothing at all. I think there's a fear that the M$ patent for IsNot 
is scaring people. Maybe ... 

Georg Wrede <georg.wrede nospam.org> writes:

Matthew wrote:
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:425A5F75.3060405 nospam.org...
 
Anders F Björklund wrote:

But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky 
?
Either way, it needs *some* kind of new token for the not 
variant!

Damn, folks! What's so horribly wrong with isnot??????

 
 
 Nothing at all. I think there's a fear that the M$ patent for IsNot 
 is scaring people. Maybe ... 

Damn squared!

First, I've read the application, and it does not apply to D.

Second, folks are getting paranoid. In another post somebody opposed the 
usage "version(unix)" on the grounds that we may get sued. That's about 
as intelligent as if I wrote a novel about a housewife, in which she 
says "I'll hoover the living room". And then some nitwit says I can't 
publish the novel because then the vacuum firm would sue.

(Hell, maybe I'll get sued right now, by both!)

LIke "POSIX" were less of a registered trade mark, huh!

To top it all, this "version(unix)" guy (IIRC) had no problem with 
"version(windows)". Go figure.

-----------

PS, if everybody isn't nice to me, I'll patent every single word there 
is. That'd be the end of programming. And if not, then I'll patent every 
single character combination. I'd live on the Bahamas with 50 virgins, 
and G. Bush would have to come crawling to me, asking "Pretty please, 
Mr. Wrede, Sir! May we licence words from you Sir? The NSA, Echelon, 
IRS, and others really need it!"

Oops. Maybe G. Bush has registered his name? Eeeek, he's coming to sue 
me for usage! I better quit while ahead.

Sean Kelly <sean f4.ca> writes:

In article <425A8760.9080206 nospam.org>, Georg Wrede says...
Second, folks are getting paranoid. In another post somebody opposed the 
usage "version(unix)" on the grounds that we may get sued. That's about 
as intelligent as if I wrote a novel about a housewife, in which she 
says "I'll hoover the living room". And then some nitwit says I can't 
publish the novel because then the vacuum firm would sue.

..
-----------

PS, if everybody isn't nice to me, I'll patent every single word there 
is.

FWIW, you can't patent words, only processes.  Words can be trademarked, so long
as they aren't in common usage (ie. you couldn't trademark "and").  And I
haven't read the patent, but there's no way someone could patent an inverse
identity comparison.  That would be like trying to patent long division.
Finally, the burden of proof for patent violations is on the patent holder, not
the potential violator.  ie. you're much better off not researching whether
something has been patented than vice-versa, especially when you're not spending
a bundle on research.  If someone has a complaint then it can be dealt with at
the time they bring it up.


Sean

=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:

Georg Wrede wrote:

 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

 
 Damn, folks! What's so horribly wrong with isnot??????

Nothing... Just waiting for the Word from the W. since DMD 111 ?
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14705

It would also be interesting to know whether '===' and '!=='
are going to remain in the language, or eventually be torn out ?


I think all of them are useful, but that's just me.
Anyway, I would rather have four than just one: "is"

Pretty straightforward and universal (math), too:

ASCII - Unicode
  ==        =  (http://www.fileformat.info/info/unicode/char/003d/)
  !=        ≠  (http://www.fileformat.info/info/unicode/char/2260/)
  ===       ≡ (http://www.fileformat.info/info/unicode/char/2261/)
  !==       ≢ (http://www.fileformat.info/info/unicode/char/2262/)


But the english operator "is" isn't too bad either :-)
(once this "issue" with the negative form is sorted out)

Just wonder if it is going to spread to the others too ?
("equals" ==, "and" &&, "or" ||) Or if this "is" it... ?

Just be careful, or we will end up with something like:

http://developer.apple.com/documentation/AppleScript/
Conceptual/AppleScriptLangGuide/AppleScript.103.html

With the "isn't less than or equal to" operator... (>)

--anders

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5F75.3060405 nospam.org...
 Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

 Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't 
"isnot".

 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ben Hinkle wrote:

Damn, folks! What's so horribly wrong with isnot??????

 
 To me the only problem with isnot is that the contraction of "is not" isn't 
 "isnot".

The "isnot" was only used to avoid changing the D lexer.

If it *was* to be changed, I guess "is not" is
as likely as "is!" or "!is" or "~is" or anything...
(which also makes it the most desirable version)

I think Walter will get to decide which one it is.
Just hope that it isn't the current "!(is)" form ?
Seems like most will continue to use '!==', if so.

Only problem with "is not" is that it looks like Python :-)

--anders

"Ben Hinkle" <bhinkle mathworks.com> writes:

"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3e4tn$2nv0$1 digitaldaemon.com...
 Ben Hinkle wrote:

Damn, folks! What's so horribly wrong with isnot??????

 To me the only problem with isnot is that the contraction of "is not" 
 isn't "isnot".

 The "isnot" was only used to avoid changing the D lexer.

 If it *was* to be changed, I guess "is not" is
 as likely as "is!" or "!is" or "~is" or anything...
 (which also makes it the most desirable version)

 I think Walter will get to decide which one it is.
 Just hope that it isn't the current "!(is)" form ?
 Seems like most will continue to use '!==', if so.

 Only problem with "is not" is that it looks like Python :-)

 --anders

IMHO "isnt" is better than "isnot". 

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Ben Hinkle wrote:

 IMHO "isnt" is better than "isnot". 

Might as well use "is not", or there will be endless
fights over which one was the best to use... Of course,
that's two tokens - which might pose a problem in itself ?

At least I *think* it's a problem, or why was e.g.
"unsigned int" contracted into "uint" ? Something else ?
But both the "isnot" and "isnt" forms does look like typos...

Let's hope it can be resolved swiftly, like float literals.
(i.e. we debate it here for ages, and W. says: "it's done")
As long as *something* is added, "isnt" isnt all that bad. :-)


But I think that it's been a "while" with !(foo is null) now:
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/826
W: "I'd like to run with the current scheme for a while longer first."

It's time to do something about this wart *now*. It not(is pretty)...

--anders

pragma <pragma_member pathlink.com> writes:

In article <d3e3jj$2mel$1 digitaldaemon.com>, Ben Hinkle says...
"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425A5F75.3060405 nospam.org...
 Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky ?
 Either way, it needs *some* kind of new token for the not variant!

 Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is not" isn't 
"isnot".

 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.

You should take a trip to West Virginia some time.  Folks out that way would
probably have this shortened to "for'ch" or "ferch" in no time.

(I once had a friend who did construction in those mountains.  He said that one
guy on the job site had managed to contract "Could I please have another one?"
to "'nothern?".  True story.)

- EricAnderton at yahoo

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"pragma" <pragma_member pathlink.com> wrote in message 
news:d3e8ea$2sh1$1 digitaldaemon.com...
 In article <d3e3jj$2mel$1 digitaldaemon.com>, Ben Hinkle says...
"Georg Wrede" <georg.wrede nospam.org> wrote in message
news:425A5F75.3060405 nospam.org...
 Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get 
 lucky ?
 Either way, it needs *some* kind of new token for the not 
 variant!

 Damn, folks! What's so horribly wrong with isnot??????

To me the only problem with isnot is that the contraction of "is 
not" isn't
"isnot".

 We have foreach, and nobody seems to jump in the river Styx!

There is no standard contraction of "for each" so foreach is ok.

 You should take a trip to West Virginia some time.  Folks out that 
 way would
 probably have this shortened to "for'ch" or "ferch" in no time.

 (I once had a friend who did construction in those mountains.  He 
 said that one
 guy on the job site had managed to contract "Could I please have 
 another one?"
 to "'nothern?".  True story.)

Tha m'no n'naught 'bart t'nth 'r'England, s'll a'cn se 

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Ben Hinkle" <bhinkle mathworks.com> wrote in message 
news:d3e3jj$2mel$1 digitaldaemon.com...
 "Georg Wrede" <georg.wrede nospam.org> wrote in message 
 news:425A5F75.3060405 nospam.org...
 Anders F Björklund wrote:
 But if "isnot" wouldn't fly, maybe "!is" or "~is" will get lucky 
 ?
 Either way, it needs *some* kind of new token for the not 
 variant!

 Damn, folks! What's so horribly wrong with isnot??????

 To me the only problem with isnot is that the contraction of "is 
 not" isn't "isnot".

 We have foreach, and nobody seems to jump in the river Styx!

 There is no standard contraction of "for each" so foreach is ok.

'course there is: freach. I believe I have the singular honour of 
introducing that one. (It'll go in the book, along with death 
tractor <g>) 

brad domain.invalid writes:

Why not do what python does?
if (a is b) ...
if (a is not b) ...

I'm guessing it is harder on the compiler to do it this way?

Brad

Georg Wrede <georg.wrede nospam.org> writes:

Anders F Björklund wrote:
 Since people confuse equality and identity all the time there, too ?

If one of them was keywords only and the other not, then that would 
remove this confusion, once and for all.

In general, anytime there are two concepts "too near each other" (be it 
in pros' or uninitiateds' minds), they should be made very dissimilar in 
appearance. -- This is just common sense, and applies to scores of other 
things outside programming languages, too.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Georg Wrede wrote:

 Since people confuse equality and identity all the time there, too ?

 
 If one of them was keywords only and the other not, then that would 
 remove this confusion, once and for all.

In Java they are called "equals()" and "==", and people confuse them ?

People would still confuse "==" and "is" too, but perhaps less than
"==" and "===" when using some weird font unsuitable for programming.

Oops, it seems like some bias might have crept into that last sentence.
--anders

pragma <pragma_member pathlink.com> writes:

In article <d37pdo$179t$1 digitaldaemon.com>, Kris says...
Food for thought:

I'm thinking constantly, thanks for the brainfood!

My home system died a horrible death last Saturday, so I am sans computer on the
weekends.  My, did this thread *explode* with comments.

So my thoughts are going to seem a touch retrograde with respect to the rest of
the thread... I'm still catching up.

I think D has perhaps made a serious blunder here. IMO, Java has the right
approach by maintaining compatability for the vast majority of usage, whilst
providing an option for testing "deep equivalence" via the equals() method
for the remaining small percentage.

D has effectively inverted that, and almost requires the adoption of a
different, and somewhat confusing, idiom to do what has been tradition for a
rather long time. The alternative is potentially error-prone code.

There's ostensibly nothing wrong with change, but it's not clear what the
benefit is here ~ if any?

I had to ponder this for a bit.  I think that D makes it *more* clear than java
in that it tries to make objects more like scalars where Java makes /references/
more like scalars.  The difference seems trival at first, but has serious
ramifications for generic programming and consistency.

Java's operators assume that a reference is really another scalar type.  You use
'==' to compare two integers so likewise you use it to compare the address
stored in two references.  This is just like with C pointers.  But it introduces
the 'equals()' wart for object-value tests just to work around the
already-occupied '==' operator.

On the other hand, D allows the programmer to treat the reference as a
full-fledged type.  By this, it assumes that you want to use objects as
value-types, so it caters to the value-comparison nature of '=='.  Identity
tests, which belong wholly to OOP, are evaluated by the 'extra' operators: '==='
or 'is'.  

D has one added advantage: the 'is' operator applies to scalars as well, as it
compiles down to a value comparison (since scalar identity and value are
one-in-the-same).

So when you look at it, D is vastly more consistent:

Java:
int a,b;
Integer c,d;
if(a == b){} // value comparsion
if(a == b){} // identity comparsion
if(c.equals(d)){} // value comparison
if(c == d){} // identity comparision

D:
int a,b;
Integer c,d;
if(a == b){} // value comparsion
if(a is b){} // identity comparsion (same as '==' in this case)
if(c == d){} // value comparison (opEquals)
if(c is d){} // identity comparision (compare references)

.. since the meaning of '==' is context-sensitive in D only to make the
semantics of the operator the same in all cases; same goes for 'is'.  Java makes
the reverse tradeoff, which makes it easier for the compiler-writer (references
are scalars unless followed by '.') and harder on the programmer.

As for littering one's code with 'is' all over the place: I think its a good
thing.  For starters, 'is' cannot be confused with '=' whereas '==' can (don't
get me started on '===').  It can be used freely on any type, and is anything
but ambiguous as to what it means.  

If for no other reason, it has a rather cosmetic affect on code:

Integer a,b;
bit result1 = a === b;
bit result2 = a is b; // easier to read.

I'm on the fence when it comes to depricating '===' and '!==', although I'm
leaning more towards deprication.  IMO, it just seems inconsistent to have two
sets of operators for one task only.  Since object-identity tests are in their
own category, they might as well get a different treatment just so they're not
confused with value-style tests.

Furthermore on consistency: we need a word to represent '!=='.  In order of
preference, I'd like to see any one of the following:

1) isnot
2) is not *
3) isnt
4) !is
5) notis
6) not is
7) is!
..
998) aint
999) iSnot (/imagines a G4 cube-style kleenex box)

(* 'not' should also be considered for an alternative to '!')

- EricAnderton at yahoo

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

pragma wrote:

 I'm on the fence when it comes to depricating '===' and '!==', although I'm
 leaning more towards deprication.  IMO, it just seems inconsistent to have two
 sets of operators for one task only. 

You shouldn't listen to everything that Guido (van Rossum) says... :-)

http://c2.com/cgi/wiki?TimTowTdi

Seriously, I think we might have gotten ourselves another Religious War.

And I'm with Larry (Wall) here...

--anders

Georg Wrede <georg.wrede nospam.org> writes:

Anders F Björklund wrote:
 
 http://c2.com/cgi/wiki?TimTowTdi

Ahhh, that made me remember why we never got anywhere with "isnot". It 
wasn't that most were against it, it was only that everyone and their 
dog had to have their own word to propose.

"Another way to defeat democracy: have 4000 candidates for the presidency."

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425AB303.9090407 nospam.org...
 Anders F Björklund wrote:
 http://c2.com/cgi/wiki?TimTowTdi

 Ahhh, that made me remember why we never got anywhere with 
 "isnot". It wasn't that most were against it, it was only that 
 everyone and their dog had to have their own word to propose.

 "Another way to defeat democracy: have 4000 candidates for the 
 presidency."

What's de-mo-cra-cy? (Did I say it right?)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 1) isnot

Fine

 2) is not *

 (* 'not' should also be considered for an alternative to '!')

Do you mean we should consider reserving "not" as a keyword in an of 
itself, and therefore avoid mixing it with is for identity? If so, I 
agree

 3) isnt

Less good that isnot, but I can live with it without a murmur of 
disquiet.

 4) !is

Hopelessly crap

 5) notis

Unreadable

 6) not is

Somewhat unreadable

 7) is!

Definitely not

 ..
 998) aint

Horrid. I agree with Walter that D has a nice (albeit ambiguous) 
ring, and Phobos does not smack of amateur hour, but aint most 
certainly would.

 999) iSnot (/imagines a G4 cube-style kleenex box)

:-) (I'm still entertaining getting a Mac - the end of financial 
year beckons - and I reckon an iSnot would go quite well)

pragma <pragma_member pathlink.com> writes:

In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...
 1) isnot

Fine

 2) is not *

 (* 'not' should also be considered for an alternative to '!')

Do you mean we should consider reserving "not" as a keyword in an of 
itself, and therefore avoid mixing it with is for identity? If so, I 
agree

I think we're on the same page here, but let me clarify all the same. :)

To sum up, 'not' could be used interchangably with '!'.  I can see this having
some ramifications for the lexer and lexer, and then again perhaps !; that's for
Walter do decide if its doable. I for one feel !like some others in that !using
'!', and replacing it with a readable word, would keep some expressions from
being !readable.  Perhaps deciding what is or !is readable is best left for a
new thread? 

 ..
 998) aint

Horrid. I agree with Walter that D has a nice (albeit ambiguous) 
ring, and Phobos does not smack of amateur hour, but aint most 
certainly would.

Agreed.  I guess we could always leave that for a "localized" version of D:

 Foobar[] x;
 forch(Foobar a; x){
   if(x aint nuthin){
      a.gitSomethin();
   }
   else nothern;
 }

- EricAnderton at yahoo

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"pragma" <pragma_member pathlink.com> wrote in message 
news:d3gqmg$2sg5$1 digitaldaemon.com...
 In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...
 1) isnot

Fine

 2) is not *

 (* 'not' should also be considered for an alternative to '!')

Do you mean we should consider reserving "not" as a keyword in an 
of
itself, and therefore avoid mixing it with is for identity? If so, 
I
agree

 I think we're on the same page here, but let me clarify all the 
 same. :)

 To sum up, 'not' could be used interchangably with '!'.  I can see 
 this having
 some ramifications for the lexer and lexer, and then again perhaps 
 !; that's for
 Walter do decide if its doable. I for one feel !like some others 
 in that !using
 '!', and replacing it with a readable word, would keep some 
 expressions from
 being !readable.  Perhaps deciding what is or !is readable is best 
 left for a
 new thread?

I buy that 

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how far could this be carried though.
For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3i8oj$s5n$1 digitaldaemon.com...
 "pragma" <pragma_member pathlink.com> wrote in message
 news:d3gqmg$2sg5$1 digitaldaemon.com...
 In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...


*snip*
 To sum up, 'not' could be used interchangably with '!'.  I can see
 this having
 some ramifications for the lexer and lexer, and then again perhaps
 !; that's for
 Walter do decide if its doable. I for one feel !like some others
 in that !using
 '!', and replacing it with a readable word, would keep some
 expressions from
 being !readable.  Perhaps deciding what is or !is readable is best
 left for a
 new thread?

 I buy that

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

TechnoZeus wrote:

 I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.
 Gets me thinking, just how far could this be carried though. For example...
 
 If (true xor false and (a lessthan c) and not (a equals b))...
 
 any thoughts?  :)

Score one more for "isnt"... Since "is !" is very different from "!==" ?

Actually, "xor" seems to still be missing from D too (i.e. ^^ operator)


"if left parenthesis true exclusive or false and left parenthesis a...

</hawking>. Please, let's avoid those keywords. What's wrong with math ?


Think I know why Walter didn't want to leave "!(a is b)". Can of worms.

--anders

"Matthew" <admin.hat stlsoft.dot.org> writes:

"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how 
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

All fine to me. But one must ask whether there's any advantage to it, I guess.


 "Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3i8oj$s5n$1 digitaldaemon.com...
 "pragma" <pragma_member pathlink.com> wrote in message
 news:d3gqmg$2sg5$1 digitaldaemon.com...
 In article <d3f0i7$q3o$1 digitaldaemon.com>, Matthew says...


 *snip*
 To sum up, 'not' could be used interchangably with '!'.  I can see
 this having
 some ramifications for the lexer and lexer, and then again perhaps
 !; that's for
 Walter do decide if its doable. I for one feel !like some others
 in that !using
 '!', and replacing it with a readable word, would keep some
 expressions from
 being !readable.  Perhaps deciding what is or !is readable is best
 left for a
 new thread?

 I buy that

 

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how 
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

 All fine to me. But one must ask whether there's any advantage to it, I guess.

Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it
is. Belay that opinion, ye black-hearted 
blaggards!

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ikh2$169m$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

 All fine to me. But one must ask whether there's any advantage to it, I guess.

 Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it
is. Belay that opinion, ye black-hearted
 blaggards!

Hahaha.  Well, I'll answer the de-asked question anyway...

Yes, there would be potential advantages... but to my knowledge they haven't
been explored, or weighed against the potential disadvantages.  For example,
there is no good way to search for the "=" operator in a text file, without
also finding every "==" and "+=" and so on.  Also, a newbie could easily see
the diggerence between "a equals b" and "a becomes b" where the difference
between "a == b" and "a = b" isn't so obvious.  Don't get me wrong here.  I'm
not advocating the use of "equals" or "becomes" or any specific keywords at
this point.  I'm simply pointing out that there are "potential" benefits of
development along this line of thinking.

I do like the idea of boolean comparator keywords (including "not") and the
"isnt" keyword... but I haven't thought through their potential disadvantages,
if any, so I'm not advocating them as of yet... just stating my opinion, that
the idea is worth further discussion.

TZ

"Matthew" <admin.hat stlsoft.dot.org> writes:

"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3im12$17es$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ikh2$169m$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just 
how
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

 All fine to me. But one must ask whether there's any advantage to it, I guess.

 Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it
is. Belay that opinion, ye black-hearted
 blaggards!

 Hahaha.  Well, I'll answer the de-asked question anyway...

 Yes, there would be potential advantages... but to my knowledge they haven't
been explored, or weighed against the 
 potential disadvantages.  For example, there is no good way to search for the
"=" operator in a text file, without 
 also finding every "==" and "+=" and so on.  Also, a newbie could easily see
the diggerence between "a equals b" and 
 "a becomes b" where the difference between "a == b" and "a = b" isn't so
obvious.  Don't get me wrong here.  I'm not 
 advocating the use of "equals" or "becomes" or any specific keywords at this
point.  I'm simply pointing out that 
 there are "potential" benefits of development along this line of thinking.

 I do like the idea of boolean comparator keywords (including "not") and the
"isnt" keyword... but I haven't thought 
 through their potential disadvantages, if any, so I'm not advocating them as
of yet... just stating my opinion, that 
 the idea is worth further discussion.

Fair enough

btw, you can search for a single equals by "[^=]=[^=]"

btw2: I tried to respond to your emails today, but got your funny email defense
thing. Although I don't mind getting 
into a challenge response once in order to register, I'm not going to be
bothered to have to append a keyword to the 
subject line of every email I send. Do you have a secret undefended email
address, which you could let me know by email 
me on my not-so-private email matthew hat synesis dot com dotility-dot-dot au?

Cheers

Matthew

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

What program were you doing your searching in?  I'm writing code in Notepad and
Wordpad at the moment, and neither one of them support that sort of search to
my knowledge.

As for my e-mail, I'll check the box that catches unexpected e-mails and look
for your e-mail there.  Expect a reply if I find it.

TechnoZeus

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ipmv$1ai1$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3im12$17es$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ikh2$169m$1 digitaldaemon.com...
 "Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3ik9s$167k$1 digitaldaemon.com...
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message
news:d3ihmm$13ru$1 digitaldaemon.com...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just
how
far could this be carried though. For example...

 If (true xor false and (a lessthan c) and not (a equals b))...

 any thoughts?  :)

 All fine to me. But one must ask whether there's any advantage to it, I guess.

 Bobdamnit, I changed my mind and deleted it from the outbox. And yet here it
is. Belay that opinion, ye black-hearted
 blaggards!

 Hahaha.  Well, I'll answer the de-asked question anyway...

 Yes, there would be potential advantages... but to my knowledge they haven't
been explored, or weighed against the
 potential disadvantages.  For example, there is no good way to search for the
"=" operator in a text file, without
 also finding every "==" and "+=" and so on.  Also, a newbie could easily see
the diggerence between "a equals b" and
 "a becomes b" where the difference between "a == b" and "a = b" isn't so
obvious.  Don't get me wrong here.  I'm not
 advocating the use of "equals" or "becomes" or any specific keywords at this
point.  I'm simply pointing out that
 there are "potential" benefits of development along this line of thinking.

 I do like the idea of boolean comparator keywords (including "not") and the
"isnt" keyword... but I haven't thought
 through their potential disadvantages, if any, so I'm not advocating them as
of yet... just stating my opinion, that
 the idea is worth further discussion.

 Fair enough

 btw, you can search for a single equals by "[^=]=[^=]"

 btw2: I tried to respond to your emails today, but got your funny email
defense thing. Although I don't mind getting
 into a challenge response once in order to register, I'm not going to be
bothered to have to append a keyword to the
 subject line of every email I send. Do you have a secret undefended email
address, which you could let me know by email
 me on my not-so-private email matthew hat synesis dot com dotility-dot-dot au?

 Cheers

 Matthew

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d3j529$1l27$1 digitaldaemon.com...
 What program were you doing your searching in?  I'm writing code 
 in Notepad and Wordpad at the moment, and neither one of them 
 support that sort of search to my knowledge.

Desist immediately, and get GVIM (http://vim.org/). Sure, if you're 
unfamiliar with vi keystrokes, it'll seem quite weird at first, but 
I _promise_ that once you get used to it you'll be a very happy 
puppy. (Caveat: I actually do my D editing in Visual Studio '98, but 
I do edit make scripts, Ruby, Python, C & C++ in GVIM both on Win32 
and Linux, it's really cool. Others on this ng have specific 
expertiese on using it with D, and they can help out, I'm sure.)

I also recommend the book "Vi IMproved - Vim", by Steve Oualline.

John Demme <me teqdruid.com> writes:

On Thu, 2005-04-14 at 09:38 +1000, Matthew wrote:
 "TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
 news:d3j529$1l27$1 digitaldaemon.com...
 What program were you doing your searching in?  I'm writing code 
 in Notepad and Wordpad at the moment, and neither one of them 
 support that sort of search to my knowledge.

 
 Desist immediately, and get GVIM (http://vim.org/). Sure, if you're 
 unfamiliar with vi keystrokes, it'll seem quite weird at first, but 
 I _promise_ that once you get used to it you'll be a very happy 
 puppy. (Caveat: I actually do my D editing in Visual Studio '98, but 
 I do edit make scripts, Ruby, Python, C & C++ in GVIM both on Win32 
 and Linux, it's really cool. Others on this ng have specific 
 expertiese on using it with D, and they can help out, I'm sure.)
 
 I also recommend the book "Vi IMproved - Vim", by Steve Oualline.
 
 
 

Don't listen to him! He's mad!

Get yourself a nice copy of emacs.

(heh heh heh)

"Kris" <fu bar.com> writes:

"John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

Yes, Yes! Matthew has entirely lost control of his faculties. Emacs is the
one, the true, the Holy Shoe!

(ahem  ... *cough*)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Kris" <fu bar.com> wrote in message 
news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

 Yes, Yes! Matthew has entirely lost control of his faculties. 
 Emacs is the
 one, the true, the Holy Shoe!

 (ahem  ... *cough*)

But - and I am 100% ignorant of Emacs - doesn't it take like a 
whole-system-approach, i.e. you have to give your brain up to Lisp, 
and "the Emacs way"? At least that's the impression I've gotten from 
people - such as Raymond - who've written about the two.

(Bear in mind that I've been hanging on to VS98 for 7 years now, so 
reluctant am I to have to get productive in another editor. So I 
might not be sane ...) 

"Kris" <fu bar.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kch3$2o1r$1 digitaldaemon.com...
 "Kris" <fu bar.com> wrote in message
 news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

 Yes, Yes! Matthew has entirely lost control of his faculties.
 Emacs is the
 one, the true, the Holy Shoe!

 (ahem  ... *cough*)

 But - and I am 100% ignorant of Emacs - doesn't it take like a
 whole-system-approach, i.e. you have to give your brain up to Lisp,
 and "the Emacs way"? At least that's the impression I've gotten from
 people - such as Raymond - who've written about the two.

No more than the "VI way" :-)

Yes, Emacs wields a mighty sword, but you can use just what you need and no
more. I use it only as an editor, nowadays. A changing world. Lisp is just
one flavour of cutomization langauges used by various versions of Emacs.
Back in the day, I used one of the originals on TOPS-20 (DEC-20), where the
underlying language was TECO (TECO put APL to shame).

http://en.wikipedia.org/wiki/Emacs


 (Bear in mind that I've been hanging on to VS98 for 7 years now, so
 reluctant am I to have to get productive in another editor. So I
 might not be sane ...)

VS98 probably has a keyboard mapping for Epsilon. This is about as close as
many people get to Emacs, and the MSVC mappings are sometimes a bit bogus (I
first used Epsilon about 20 years ago, and was truly happy with it for at
least a decade). T'was a productive IDE at that time.

But (as you know), editors are like religion. People both applaud and defend
them in the most irrational manner. Hence the reference to Montly Pythons
"Grail".

"Kris" <fu bar.com> writes:

Whoops; meant to note that Epsilon uses a small dialect of C as the
customization language instead (called EEL: Epsilon Extension Language). An
editor that arrived with its very own compiler used to be considered
something very special :-)

- Kris

John Demme <me teqdruid.com> writes:

I don't know the first thing about LISP, but I use Emacs very
productively.  If I ever wanted to write something like Ben Hinkle's
D-Mode (or even modify it) then I would have to learn LISP.

Once you learn a few simple concepts, and key bindings, you can get
pretty productive in Emacs.

John Demme

On Thu, 2005-04-14 at 10:12 +1000, Matthew wrote:
 "Kris" <fu bar.com> wrote in message 
 news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

 Yes, Yes! Matthew has entirely lost control of his faculties. 
 Emacs is the
 one, the true, the Holy Shoe!

 (ahem  ... *cough*)

 
 But - and I am 100% ignorant of Emacs - doesn't it take like a 
 whole-system-approach, i.e. you have to give your brain up to Lisp, 
 and "the Emacs way"? At least that's the impression I've gotten from 
 people - such as Raymond - who've written about the two.
 
 (Bear in mind that I've been hanging on to VS98 for 7 years now, so 
 reluctant am I to have to get productive in another editor. So I 
 might not be sane ...) 
 
 

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Hmmm.  I have a copy of Microsoft Visual Studio version 6 someplace around
here... although not currently installed.  Isn't that like 92 versions before
VS98?  Hehe.

Oh, I tried that vim.org site and it wouldn't open.  Is there an alternative
address, or a mirror site?  As for Emacs, I tried downloading that once a while
back, hoping to use it to read some LaTex files, but the download said it was
going to take something like 7 days, so I canceled it.

TZ

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kch3$2o1r$1 digitaldaemon.com...
 "Kris" <fu bar.com> wrote in message
 news:d3kc9h$2ns6$1 digitaldaemon.com...
 "John Demme" <me teqdruid.com> wrote in message
 Don't listen to him! He's mad!

 Get yourself a nice copy of emacs.

 (heh heh heh)

 Yes, Yes! Matthew has entirely lost control of his faculties.
 Emacs is the
 one, the true, the Holy Shoe!

 (ahem  ... *cough*)

 But - and I am 100% ignorant of Emacs - doesn't it take like a
 whole-system-approach, i.e. you have to give your brain up to Lisp,
 and "the Emacs way"? At least that's the impression I've gotten from
 people - such as Raymond - who've written about the two.

 (Bear in mind that I've been hanging on to VS98 for 7 years now, so
 reluctant am I to have to get productive in another editor. So I
 might not be sane ...)

jicman <jicman_member pathlink.com> writes:

Matthew is right.  Vim is the junk...!

jic

Matthew says...
"TechnoZeus" <TechnoZeus PeoplePC.com> wrote in message 
news:d3j529$1l27$1 digitaldaemon.com...
 What program were you doing your searching in?  I'm writing code 
 in Notepad and Wordpad at the moment, and neither one of them 
 support that sort of search to my knowledge.

Desist immediately, and get GVIM (http://vim.org/). Sure, if you're 
unfamiliar with vi keystrokes, it'll seem quite weird at first, but 
I _promise_ that once you get used to it you'll be a very happy 
puppy. (Caveat: I actually do my D editing in Visual Studio '98, but 
I do edit make scripts, Ruby, Python, C & C++ in GVIM both on Win32 
and Linux, it's really cool. Others on this ng have specific 
expertiese on using it with D, and they can help out, I'm sure.)

I also recommend the book "Vi IMproved - Vim", by Steve Oualline.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"jicman" <jicman_member pathlink.com> wrote in message 
news:d3knb8$2uov$1 digitaldaemon.com...
 Matthew is right.  Vim is the junk...!

Oh Bob! Have I become old? I don't know whether junk is good or bad.

I'm guessing .... good ... ??


:-(

jicman <jicman_member pathlink.com> writes:

Sorry, trying to use some of the new lingo I've heard on the street, the other
day.  It means good.  Like, "vim is the bomb!" Which is really good.  I used to
use emacs, but... Long story...  But I have been using vim for the last 4 years
and it rocks!  Ahem, it's really swell. :-)

jic

Matthew says...
"jicman" <jicman_member pathlink.com> wrote in message 
news:d3knb8$2uov$1 digitaldaemon.com...
 Matthew is right.  Vim is the junk...!

Oh Bob! Have I become old? I don't know whether junk is good or bad.

I'm guessing .... good ... ??


:-(

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

There are reasons such terms are common "on the streets" and usually
coincidence isn't one of them.  Hehe.  Personally, I try to stay away from
using ambiguous language.  Hard enough to be understood sometimes without
adding the element of ambiguity.

TZ

"jicman" <jicman_member pathlink.com> wrote in message
news:d3kret$13b$1 digitaldaemon.com...
 Sorry, trying to use some of the new lingo I've heard on the street, the other
 day.  It means good.  Like, "vim is the bomb!" Which is really good.  I used to
 use emacs, but... Long story...  But I have been using vim for the last 4 years
 and it rocks!  Ahem, it's really swell. :-)

 jic

 Matthew says...
"jicman" <jicman_member pathlink.com> wrote in message
news:d3knb8$2uov$1 digitaldaemon.com...
 Matthew is right.  Vim is the junk...!

Oh Bob! Have I become old? I don't know whether junk is good or bad.

I'm guessing .... good ... ??


:-(

pragma <pragma_member pathlink.com> writes:

In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how far could this be carried though.
For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes. 

ColdFusion has three-to-four letter shorthand operator names to replace the
typical comparison operators.  They also have a longhand form that, IMO, nobody
really uses:

http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

Their motivation for operators like "gte", "lte" and so forth was simple.
ColdFusion is a markup-based language, so symbols like '<' and '>' have
implications for parsing the language as a whole. (it'd be like using "[" or "{"
as operators in D).

I for one would love to see such operators in place, but I'm also biased. DSP
(or anyplace else that D is embedded in markup) could benefit hugely from such
an addition as "<[CDATA[...]]>" tags wouldn't be needed for code blocks.  It is
far and away better than using entities (eg. "if(x &lt;= y){}"), a hideous
looking workaround, even if its commonplace to so in XPATH and XSLT.

To me the gain seems minimal at best, although it would cause the bare minimum
of headache for developers. I seriously doubt anyone is using "and", "or", "gte"
or "eq" as identifiers in their programs.

- EricAnderton at yahoo

Sean Kelly <sean f4.ca> writes:

In article <d3jhio$20jr$1 digitaldaemon.com>, pragma says...
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!" operator
would be nice.  Gets me thinking, just how far could this be carried though.
For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes. 

ColdFusion has three-to-four letter shorthand operator names to replace the
typical comparison operators.  They also have a longhand form that, IMO, nobody
really uses:

http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

FWIW, this exists in C++ as well, though nobody seems to use them.  Check
section 2.5 of the C++ standard--Alternative tokens.  Here's the table from that
section:

<% {
and &&
and_eq &= _
%> }
bitor |
or_eq |=
<: [
or ||
xor_eq ^=
:> ]
xor ^
not !

compl ~
not_eq !=

bitand &

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Sean Kelly" <sean f4.ca> wrote in message 
news:d3jn59$25vi$1 digitaldaemon.com...
 In article <d3jhio$20jr$1 digitaldaemon.com>, pragma says...
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!" 
operator would be nice.  Gets me thinking, just how far could 
this be carried though. For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes.

ColdFusion has three-to-four letter shorthand operator names to 
replace the
typical comparison operators.  They also have a longhand form 
that, IMO, nobody
really uses:

http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

 FWIW, this exists in C++ as well, though nobody seems to use them. 
 Check
 section 2.5 of the C++ standard--Alternative tokens.  Here's the 
 table from that
 section:

 <% {
 and &&
 and_eq &= _
 %> }
 bitor |
 or_eq |=
 <: [
 or ||
 xor_eq ^=
 :> ]
 xor ^
 not !

 compl ~
 not_eq !=

 bitand &

Indeed. And it can catch you out in quite vexing ways. ;)

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

I actually kindof like it.  :)  Then again, when I read what Walter had written
in http://digitalmars.com/d/sdwest/paper.html about the "researcher who wore
special goggles that turned the world upside down" my first thought was that it
sounded like something I would do.  In fact, I have thought about such
experiments, but simply lacked the means to try them.  I do have sun-glasses
that I've made with different color lenses though, and ones that I made
specifically to train my brain to have better control over which eye it pays
the most attention to the input from at any given time, as well as defractive
glasses that I use to see the difference between various composite lightings
such as halogen or florescent.

But a point that I would like to state clearly is that in the same way that
having several ways to do a single task in Windows allows each user to find the
one that best fits their way of thinking, whether it's keyboard shortcuts or
fly-out menus or context menus or icons, or whatever... it could increase the
ease of getting started if alternatives are available that are intuitive enough
for some people to "guess" them.

The use of "not" as an alternative to "!" would be a good example of something
that would probably be that intuitive.  Few people would have trouble
understanding things like "a and not b" or not(a<b) for example.  Again, I'm
not advocating the use of "not" specifically, but simply using it as an example
to make my point.  What it intuitive shouldn't be decided by one person, if
there is any opportunity to have more than one person colaborate on the
effort... and the more diverse their ways of thinking, the better.

TZ

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kanv$2mu4$2 digitaldaemon.com...
 "Sean Kelly" <sean f4.ca> wrote in message
 news:d3jn59$25vi$1 digitaldaemon.com...
 In article <d3jhio$20jr$1 digitaldaemon.com>, pragma says...
In article <d3ihmm$13ru$1 digitaldaemon.com>, TechnoZeus says...
I agree also.  Adding a "not" keyword as an equivilant of the "!"
operator would be nice.  Gets me thinking, just how far could
this be carried though. For example...

If (true xor false and (a lessthan c) and not (a equals b))...

any thoughts?  :)

Yes.

ColdFusion has three-to-four letter shorthand operator names to
replace the
typical comparison operators.  They also have a longhand form
that, IMO, nobody
really uses:

http://www.intermedia.net/support/ColdFusion/CF5docs/CFML_Reference/Expressions5.html

 FWIW, this exists in C++ as well, though nobody seems to use them.
 Check
 section 2.5 of the C++ standard--Alternative tokens.  Here's the
 table from that
 section:

 <% {
 and &&
 and_eq &= _
 %> }
 bitor |
 or_eq |=
 <: [
 or ||
 xor_eq ^=
 :> ]
 xor ^
 not !

 compl ~
 not_eq !=

 bitand &

 Indeed. And it can catch you out in quite vexing ways. ;)

J C Calvarese <jcc7 cox.net> writes:

pragma wrote:

...

 Furthermore on consistency: we need a word to represent '!=='.  

I agree.

 In order of preference, I'd like to see any one of the following:

1) isnt
2) isnot

3) is not*
4) !is
5) ~is
6) not is
7) notis
8) is!
...
998) aint
999) iSnot

I feel like the first two are really by far the strongest candidates, 
but in the spirit of consensus, I extended out my list. I think it's 
much more important to have a reasonable counterpart to !== than to have 
my personal favorite. :)

-- 
jcc7
http://jcc_7.tripod.com/d/

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

J C Calvarese wrote:

 Furthermore on consistency: we need a word to represent '!=='.  

 
 I agree.
 
 In order of preference, I'd like to see any one of the following:

 
 1) isnt
 2) isnot

[...]
 I feel like the first two are really by far the strongest candidates, 
 but in the spirit of consensus, I extended out my list. I think it's 
 much more important to have a reasonable counterpart to !== than to have 
 my personal favorite. :)

They also have the advantage of being very simple to add to D...
http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/14705

So, what now ? Will there be mutiny on the Mars starship "Bounty"
or will Walter pick one and just silently drop it into DMD 0.121 ?

I'll just go with '!==' now, and "s/\!\=\=/$TOKnotidentity/g" later.
It's not the that name of the operator is a big deal, just the fight.

--anders

"Kris" <fu bar.com> writes:

Some additional thoughts (inline):

"pragma" <pragma_member pathlink.com> wrote in message
 In article <d37pdo$179t$1 digitaldaemon.com>, Kris says...
Food for thought:

 I'm thinking constantly, thanks for the brainfood!

 My home system died a horrible death last Saturday, so I am sans computer

on the
 weekends.  My, did this thread *explode* with comments.

 So my thoughts are going to seem a touch retrograde with respect to the

rest of
 the thread... I'm still catching up.

I think D has perhaps made a serious blunder here. IMO, Java has the


right
approach by maintaining compatability for the vast majority of usage,


whilst
providing an option for testing "deep equivalence" via the equals()


method
for the remaining small percentage.

D has effectively inverted that, and almost requires the adoption of a
different, and somewhat confusing, idiom to do what has been tradition


for a
rather long time. The alternative is potentially error-prone code.

There's ostensibly nothing wrong with change, but it's not clear what the
benefit is here ~ if any?

 I had to ponder this for a bit.  I think that D makes it *more* clear than

java
 in that it tries to make objects more like scalars where Java makes

/references/
 more like scalars.  The difference seems trival at first, but has serious
 ramifications for generic programming and consistency.

 Java's operators assume that a reference is really another scalar type.

You use
 '==' to compare two integers so likewise you use it to compare the address
 stored in two references.  This is just like with C pointers.  But it

introduces
 the 'equals()' wart for object-value tests just to work around the
 already-occupied '==' operator.

 On the other hand, D allows the programmer to treat the reference as a
 full-fledged type.  By this, it assumes that you want to use objects as
 value-types, so it caters to the value-comparison nature of '=='.

Identity
 tests, which belong wholly to OOP, are evaluated by the 'extra' operators:

'==='
 or 'is'.

 D has one added advantage: the 'is' operator applies to scalars as well,

as it
 compiles down to a value comparison (since scalar identity and value are
 one-in-the-same).


Absolutely. This is why the original post was suggesting fully adopting
'is'. And is partly why it warned against blanket use of the '= =' operator
~  if you're not actually trying to do a deep copy, the codegen is truly
inefficient where aggregates are concerned.

I think the quote from the original post is perhaps being taken out of
context a little? The issue that quote focuses upon is not one of which
operator is best for the job ~ instead, the focus is one of consistently
with long-term habits in the community. The point being made was that Java
caters to those habits for the overwhelming majority of cases, whereas D
almost does the opposite (when we're talking about aggregates). I'll expand
on this later on.


 So when you look at it, D is vastly more consistent:

 Java:
 int a,b;
 Integer c,d;
 if(a == b){} // value comparsion
 if(a == b){} // identity comparsion
 if(c.equals(d)){} // value comparison
 if(c == d){} // identity comparision

 D:
 int a,b;
 Integer c,d;
 if(a == b){} // value comparsion
 if(a is b){} // identity comparsion (same as '==' in this case)
 if(c == d){} // value comparison (opEquals)
 if(c is d){} // identity comparision (compare references)

 .. since the meaning of '==' is context-sensitive in D only to make the
 semantics of the operator the same in all cases; same goes for 'is'.  Java

makes
 the reverse tradeoff, which makes it easier for the compiler-writer

(references
 are scalars unless followed by '.') and harder on the programmer.


Disagree here, Eric. I think Java tried to cater to the most widely used
cases of '= =' such that it rarely conflicts with established use (per the
original example given). Don't forget that Java was attempting to pick up
C/C++ users, just like D ;-)


 As for littering one's code with 'is' all over the place: I think its a

good
 thing.  For starters, 'is' cannot be confused with '=' whereas '==' can

(don't
 get me started on '===').  It can be used freely on any type, and is

anything
 but ambiguous as to what it means.

 If for no other reason, it has a rather cosmetic affect on code:

 Integer a,b;
 bit result1 = a === b;
 bit result2 = a is b; // easier to read.


Couldn't agree more.


 I'm on the fence when it comes to depricating '===' and '!==', although

I'm
 leaning more towards deprication.  IMO, it just seems inconsistent to have

two
 sets of operators for one task only.  Since object-identity tests are in

their
 own category, they might as well get a different treatment just so they're

not
 confused with value-style tests.


Simplicity of use is preferable in my book. If there were a counterpart to
"is", these two triplet-operators would be completely redundant. Not to
mention the issues of confusion regarding certain Fonts.


 Furthermore on consistency: we need a word to represent '!=='.  In order

of
 preference, I'd like to see any one of the following:

 1) isnot
 2) is not *
 3) isnt
 4) !is
 5) notis
 6) not is
 7) is!
 ..
 998) aint
 999) iSnot (/imagines a G4 cube-style kleenex box)

 (* 'not' should also be considered for an alternative to '!')


Something should certainly be added as a counterpart to 'is'.

So, let's speculate briefly: suppose we have "is" and "isnot". Further, let
us suppose the usage of "is" becomes the recommended idiom in D; due to its
handy "universal" nature. The situation we'd thus be in is as follows:

if (x is y) {}
if (x isnot y) {}

for all types of  'x' and 'y' (aggregates and primitives).

This is in rather sharp contrast to the picture in the C/C++/Java world,
don't you think? Not that such a notion is bad in and of itself, but it is
still a distinct change for such a fundamental operation. This is what the
original post was getting at. You make a good point about the consistency of
'is', for the same reasons I favoured it for the mechanical translation.
Having said that, the now-generic usage of 'is' has somewhat switched its
role from an "identity" operator, and has <gasp> suddenly become identical
to the Java '= =' :-)

Testing for "deep equivalence" would still be performed using the  '= =' and
"!=" pair. It could be argued these should be restricted to aggregate types
only, since the generic, and consistent, usage of 'is' would be applied to
non-aggregate types. But, whatever ~ let's suppose there's still the
overlap. Given that, '= =' is now actually the equivalent of the Java
equals() method, but with the twist that it can be applied to primitive
types also. Confused? No. But you can imagine how many people will feel?

The kicker here, if there isn't already one or two, is that unsuspecting
C/Java users will apply the twin '= =' anyway, which will do the wrong thing
in many, many cases. This is also one of the points made in the original
post, given the percentage figures of the example illustrated there.

In summation, here's a potential approach:

- drop the triplet operators (to help limit confusion)
- add a companion to "is", such as "isnot"
- indicate "is" and "isnot" are the equivalent of '= =' & '!=' in related
languages
- indicate very clearly that '= =' does a deep comparison wherever that
might apply

If these were to happen, I think it would become much more obvious what D is
all about in this respect.

Finally, I really do think the "is" operator should become defacto-standard
for D. But it does take the place of the '= =' operator in related
languages, whereas the D '= =' operator is somewhat different. Therein lies
significant confusion potential, which brings us back to the quote you
highlighted earlier.

- Kris

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

 Disagree here, Eric. I think Java tried to cater to the most widely used
 cases of '= =' such that it rarely conflicts with established use (per the
 original example given). Don't forget that Java was attempting to pick up
 C/C++ users, just like D ;-)

Since all strings in Java are objects, the "hidden pointer" in '==' in 
Java usually trips up the beginner - like already the first week or so:

   "No, you must use equals() to compare strings in Java."
   "Well, == does work for string literals. That's special"

   "No, you can't use the same equals() on number literals."
   "They are primitive types, you must use Object wrappers"

BTW;
Did you read the text about adding '===' to Java, instead of '==' to D ?
http://cdsmith.twu.net/professional/java/pontifications/comparison.html

I thought it provided an interesting read regarding this ?

[...]
 Having said that, the now-generic usage of 'is' has somewhat switched its
 role from an "identity" operator, and has <gasp> suddenly become identical
 to the Java '= =' :-)

Interesting point of view. You seem to think that checking identity
for primitive types is a natural operation (hadn't even occured to me)

I always thought that C checked the equality of the pointers, and that
the memcmp/equals had to be added as a call to check to the contents ?
(seeing as how the Java references are just "virtual" pointers anyway)

I guess your approach does make sense. Just find it somewhat alien :-)
And it doesn't offer much help for comparisons, except calling "compare"

 Testing for "deep equivalence" would still be performed using the  '= =' and
 "!=" pair. It could be argued these should be restricted to aggregate types
 only, since the generic, and consistent, usage of 'is' would be applied to
 non-aggregate types.

You mean that (i == j) should be deprecated ? That's pretty "huge"...

And that identity should be promoted to the primary operation,
with the "equals" offered as a method for the aggregate types ?

Q: What if you want to order two things ? i.e. < > >= <=, and so on ?
Now those would not be connected to the == and != operators anymore ?

 But, whatever ~ let's suppose there's still the
 overlap. Given that, '= =' is now actually the equivalent of the Java
 equals() method, but with the twist that it can be applied to primitive
 types also. Confused? No. But you can imagine how many people will feel?

I think D has the pretty solution. It's just not the compatible one.
(i.e. it does "change" the meaning of '==' for references, which is
even more confusing due to the presence of pointers with C-style '==')

Also, Java does not have overloaded operators. One reason for "equals" ?

 The kicker here, if there isn't already one or two, is that unsuspecting
 C/Java users will apply the twin '= =' anyway, which will do the wrong thing
 in many, many cases. This is also one of the points made in the original
 post, given the percentage figures of the example illustrated there.
 
 In summation, here's a potential approach:
 
 - drop the triplet operators (to help limit confusion)

Wouldn't it be possible to "recommend" the new and keep the old ?
(is this another one of those "consistancy" things fought earlier ?)

 - add a companion to "is", such as "isnot"

Or perhaps "isnt", that doesn't have the same nasal connection...
(and does not have the same begging for "is_not" or "isNot", etc)

 - indicate "is" and "isnot" are the equivalent of '= =' & '!=' in related
 languages

It is mentioned on the "C to D" and "Java to D" pages, as a start ?

http://www.digitalmars.com/d/ctod.html
http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD

 - indicate very clearly that '= =' does a deep comparison wherever that
 might apply

I would add: define '==' in a way that it works with null references...
Having "== null" and "null ==" runtime-segfault is not very friendly.

If this was fixed, then using '==' instead of '===' would most of
the time just be slower - not have the same "crash factor" as now ?
(ignoring the special case where you first run with the default/identity
opEquals, and then add an member-cmp implementation of opEquals later)

 If these were to happen, I think it would become much more obvious what D is
 all about in this respect.
 
 Finally, I really do think the "is" operator should become defacto-standard
 for D. But it does take the place of the '= =' operator in related
 languages, whereas the D '= =' operator is somewhat different. Therein lies
 significant confusion potential, which brings us back to the quote you
 highlighted earlier.

You mean that the '==' operator in D does not have the same confusion
as it currently does in Java ? (i.e. there it works very differently
for primitive types and for reference types). Yeah, that's "different".

However, I do think it is the Java (and C) method that needs explaining.
And I for one do not think that promoting identity is the way to go...

--anders

"Kris" <fu bar.com> writes:

Good points. Thoughts inline:

"Anders F Björklund" <afb algonet.se> wrote in message
news:d3g1t4$23l3$1 digitaldaemon.com...
 Kris wrote:

 Disagree here, Eric. I think Java tried to cater to the most widely used
 cases of '= =' such that it rarely conflicts with established use (per


the
 original example given). Don't forget that Java was attempting to pick


up
 C/C++ users, just like D ;-)

 Since all strings in Java are objects, the "hidden pointer" in '==' in
 Java usually trips up the beginner - like already the first week or so:

    "No, you must use equals() to compare strings in Java."
    "Well, == does work for string literals. That's special"

    "No, you can't use the same equals() on number literals."
    "They are primitive types, you must use Object wrappers"

 BTW;
 Did you read the text about adding '===' to Java, instead of '==' to D ?
 http://cdsmith.twu.net/professional/java/pontifications/comparison.html

 I thought it provided an interesting read regarding this ?


I didn't, but will.


 [...]
 Having said that, the now-generic usage of 'is' has somewhat switched


its
 role from an "identity" operator, and has <gasp> suddenly become


identical
 to the Java '= =' :-)

 Interesting point of view. You seem to think that checking identity
 for primitive types is a natural operation (hadn't even occured to me)

 I always thought that C checked the equality of the pointers, and that
 the memcmp/equals had to be added as a call to check to the contents ?
 (seeing as how the Java references are just "virtual" pointers anyway)

 I guess your approach does make sense. Just find it somewhat alien :-)
 And it doesn't offer much help for comparisons, except calling "compare"


So we get to the third installment, and perhaps logical conclusion of this
meandering path:

If the assigned role of '= =' and 'is' were flipped, D would be just like
C/Java ~ with the aforementioned twist regarding the equals() working with
primitives as well as aggregates. That is, since '= =' is currently the same
as a Java equals(), but works with primitives also, and 'is' currently plays
the identical role of the Java '= =' operator, switching the D operators
around makes D equivalent to Java in the usage of '= =' and equivalent to C
for the largest percentage of uses (given the original illustration). The
use of 'is' would thus be relegated to "deep equivalence" testing instead.

This is all to do with compatability vis-a-vis accepted usage. It is not a
proposition for the ideal usage of these operators.


 Testing for "deep equivalence" would still be performed using the  '= ='


and
 "!=" pair. It could be argued these should be restricted to aggregate


types
 only, since the generic, and consistent, usage of 'is' would be applied


to
 non-aggregate types.

 You mean that (i == j) should be deprecated ? That's pretty "huge"...


Just food for thought, Anders. But it would never come to that, if the D
operators '= =' and 'is' were role-reversed :-)


 And that identity should be promoted to the primary operation,
 with the "equals" offered as a method for the aggregate types ?

 Q: What if you want to order two things ? i.e. < > >= <=, and so on ?
 Now those would not be connected to the == and != operators anymore ?


And if the roles of '= =' and 'is' were reversed ...?

Again, this meandering path is about compatability with the majority of use
cases. I'm not paying much attention to the value of various theoretical
aspects, but more to the general usage of the operators in question.


 But, whatever ~ let's suppose there's still the
 overlap. Given that, '= =' is now actually the equivalent of the Java
 equals() method, but with the twist that it can be applied to primitive
 types also. Confused? No. But you can imagine how many people will feel?

 I think D has the pretty solution. It's just not the compatible one.
 (i.e. it does "change" the meaning of '==' for references, which is
 even more confusing due to the presence of pointers with C-style '==')


Absolutely. Here we agree fully. The compatability aspect is the one of
concern, for all the reasons noted in posts gone by.


 Also, Java does not have overloaded operators. One reason for "equals" ?


Undoubtedly. But that does make it rather easy to negate (since it's a
boolean method) and it's easily overloadable. That's one less operator used,
and the method-call overhead will typically be drowned by the deep
comparison. Don't forget that D has both opEquals() and opCmp() methods. The
latter is the despised one, not the former.


 The kicker here, if there isn't already one or two, is that unsuspecting
 C/Java users will apply the twin '= =' anyway, which will do the wrong


thing
 in many, many cases. This is also one of the points made in the original
 post, given the percentage figures of the example illustrated there.

 In summation, here's a potential approach:

 - drop the triplet operators (to help limit confusion)

 Wouldn't it be possible to "recommend" the new and keep the old ?
 (is this another one of those "consistancy" things fought earlier ?)


Sometimes it's better to just let go? Have you noticed I've been adding a
space between the '= =' so that it wouldn't be mistaken for '===' ?


 - add a companion to "is", such as "isnot"

 Or perhaps "isnt", that doesn't have the same nasal connection...
 (and does not have the same begging for "is_not" or "isNot", etc)


The suggestion was for purposes of clarity only. Personally I think it's
perhaps better to just use "not" as the inverse. It's a logical "not" as
opposed to a bitwise "not". e.g.

if (x is y) {}
if (x not y) {}

Once one has adopted 'is', it's a very small step to relate it directly to
'not'. But, whatever (I can already hear some shouting "that reads like if x
but not y!")


 - indicate "is" and "isnot" are the equivalent of '= =' & '!=' in


related
 languages

 It is mentioned on the "C to D" and "Java to D" pages, as a start ?

 http://www.digitalmars.com/d/ctod.html
 http://www.prowiki.org/wiki4d/wiki.cgi?JavaToD

 - indicate very clearly that '= =' does a deep comparison wherever that
 might apply

 I would add: define '==' in a way that it works with null references...
 Having "== null" and "null ==" runtime-segfault is not very friendly.

 If this was fixed, then using '==' instead of '===' would most of
 the time just be slower - not have the same "crash factor" as now ?
 (ignoring the special case where you first run with the default/identity
 opEquals, and then add an member-cmp implementation of opEquals later)


Yep; thoughtless application of '= =' currently leads to inefficient codegen
(and likely increases the cost of maintenance). But I think the compiler
does hande null comparisons recently? Maybe not.


 If these were to happen, I think it would become much more obvious what


D is
 all about in this respect.

 Finally, I really do think the "is" operator should become


defacto-standard
 for D. But it does take the place of the '= =' operator in related
 languages, whereas the D '= =' operator is somewhat different. Therein


lies
 significant confusion potential, which brings us back to the quote you
 highlighted earlier.

 You mean that the '==' operator in D does not have the same confusion
 as it currently does in Java ? (i.e. there it works very differently
 for primitive types and for reference types). Yeah, that's "different".


Sarcasm aside, the D '= =' operator currently /does/ work quite differently
for both primitive and reference types. It just a matter of perspective.

There's no question that this is a sticky area, and perhaps there will
always have to be compromises made regardless of compatability concerns? I
don't question that at all. What I do question is the break in backward
compatability, which you (and others) acknowledge.

However if the D operators '= =' and 'is' were role-reversed, the C & Java
compatability would be restored for the majority case (98.75% in the
use-case given). There's still compromise going on there, naturally. But,
shouldn't one optimize for the majority case?


 However, I do think it is the Java (and C) method that needs explaining.

That may be so (and I agree that they're all somewhat confusing in specific
areas), but shouldn't the alienation of current practice be performed with
extreme care?


 And I for one do not think that promoting identity is the way to go...

Wasn't promoting 'identity' as a concept, but would operator flipping make
things better? It's just a thought.

- Kris

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote: (and I cut it down heavily)

 This is all to do with compatability vis-a-vis accepted usage. It is not a
 proposition for the ideal usage of these operators.

It does sound like a compatibility kludge, that much is certain.

You mean that (i == j) should be deprecated ? That's pretty "huge"...

 
 Just food for thought, Anders. But it would never come to that, if the D
 operators '= =' and 'is' were role-reversed :-)

Considering there is no identity for primitives, they both
map to the same thing anyway. Normally called "equals" (eq).

  >>Q: What if you want to order two things ? i.e. < > >= <=, and so on ?
Now those would not be connected to the == and != operators anymore ?

 
 And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.

"less than", "is", "greater than" would be better - although
I would still prefer to use "equal to" for the middle one...
(or the Swedish equivalent, if I ever read them out aloud)

 Absolutely. Here we agree fully. The compatability aspect is the one of
 concern, for all the reasons noted in posts gone by.

Especially since '==' and null is defined in D to segfault.

If it hadn't been for that, it would merely be slower...
(again, ignoring "now you opEquals, now you don't" thing)

 Undoubtedly. But that does make it rather easy to negate (since it's a
 boolean method) and it's easily overloadable. That's one less operator used,
 and the method-call overhead will typically be drowned by the deep
 comparison. Don't forget that D has both opEquals() and opCmp() methods. The
 latter is the despised one, not the former.

They're both good, and both available in Java too under different names.
And like stated in the D specification, the equals one is pretty often
easy to do "faster" than the compare - that might not even be available.

Although Java makes it an interface that you implement, (i.e. 
java.lang.Sortable), whether as D adds the opCmp to Object
and has non-sortable classes throw up at runtime instead...

Wouldn't it be possible to "recommend" the new and keep the old ?
(is this another one of those "consistancy" things fought earlier ?)

 
 Sometimes it's better to just let go? Have you noticed I've been adding a
 space between the '= =' so that it wouldn't be mistaken for '===' ?

"Been annoyed by", yes. :-) Wonder what dumb font would mix the two up ?
Surely people aren't using Helvetica or Arial to program in ? <horrors>

You mean that the '==' operator in D does not have the same confusion
as it currently does in Java ? (i.e. there it works very differently
for primitive types and for reference types). Yeah, that's "different".

 
 Sarcasm aside, the D '= =' operator currently /does/ work quite differently
 for both primitive and reference types. It just a matter of perspective.

The sarcasm was all mine, sorry about that. But I do think if that I 
have a int, a struct, and a class - that D's '==' works similar for all?
(assuming that the class defines opEquals, instead of using the default)

 That may be so (and I agree that they're all somewhat confusing in specific
 areas), but shouldn't the alienation of current practice be performed with
 extreme care?

I'm not sure, there seems to be too many locked positions and legacy
considerations to make the ultimate solution come out of this anyway...

Funny how D is pinned down by history, before it has even been released?

 Wasn't promoting 'identity' as a concept, but would operator flipping make
 things better? It's just a thought.

Well, '==' IS equals and '===' IS identity... Thus,
promoting the 'is' expression is promoting identity.

The "equality" of '==' in C and Java is between the
pointers (or references), not the contents of them.

Maybe it would have been easier if D had used Object*,
like suggested by someone else already on this thread.

--anders

brad domain.invalid writes:

I don't profess to know what I am talking about - so I am going to "ring 
the bell" on this topic - hopefully someone will explain the problem 
like I am a two year old.

I have read this whole thread with interest though, here is what I have 
taken from it
1) Kris ported a significant Java project to D, and found that 99% of 
time Java programmers use == rather than equals(), which in D means that 
99% of the time you will use "is" rather than "=="
  - What exactly is the significance of this finding?  People generally 
want to shallow compare objects rather than deep compare.
2) Generally everybody hates === and !===
3) "is" is good, and needs a counterpart - "isnot" for want of a keyword
4) Does making "==" a reference (shallow) compare break consistancy with 
the other operators, which are effectively deep compares?

I got to thinking about what languages try to achieve with allowing 
operator overloading, I think that they try to make user defined types 
behave exactly as intrinsics.  This is especially important for a 
language that allows templates, as your templates should work with built 
in types and user defined types.  A while ago Derek ran across a problem 
   (thread title "opValue()") where his templates wouldn't work with 
aggregates because "=" does a reference copy, when he infact wanted a 
deep copy.
I think that this is a similar problem - do programmers want their 
operators to do a reference compare, or a deep compare?

In thinking along these lines I realised that D (at the moment) does not 
allow you to create user defined types that behave exactly as built in 
types, because user defined types (ie classes) are references, and built 
in types are not.  It looks to me like there is a huge change in 
thinking required between using built in types and user defined types.
Now, for most objects I think that references are correct and efficient. 
  However for the objects that are designed to look at act like built in 
types (ie, BigNum implementation), then they will NEVER behave exactly 
like built ins.

So I think the real question might be - how do we bridge the gap between 
user defined types and built in types?  This gap doesn't only show up in 
operators, but in passing values/references to functions.

Am I making sense, or being the Village Idiot?  If I am being an Idiot - 
please, please enlighten me.

Brad

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

<brad domain.invalid> wrote in message 
news:d3hc44$5lt$1 digitaldaemon.com...
I don't profess to know what I am talking about - so I am going to 
"ring the bell" on this topic - hopefully someone will explain the 
problem like I am a two year old.

I'm with you 100% on this one. A clarification/summarisation would 
be most useful at this point

"Kris" <fu bar.com> writes:

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
 <brad domain.invalid> wrote in message
 news:d3hc44$5lt$1 digitaldaemon.com...
I don't profess to know what I am talking about - so I am going to
"ring the bell" on this topic - hopefully someone will explain the
problem like I am a two year old.

 I'm with you 100% on this one. A clarification/summarisation would
 be most useful at this point


OK. I'll attempt to clarify the picture:

This topic is, first and foremost, a heads' up about the use of '==' and
'is' within D. It is also about compatability with established practice and
habit, borne through the use of D's predecessors.

The topic is /not/ a campaign to change the language. I'll repeat that: it
is NOT a campaign, since it's been shown such causes, however well
intentioned, and/or well supported, are naught but exercises in futility.

So, with the preamble out of the way:

------------

D supports the notions of equality and identity. Equality can be thought of
as a test to see if two individual entities have equivalent 'value', whereas
identity can be thought of as a test whether two entities are, in fact, one
and the same. Identity is rarely discussed for primitive types (int, long,
bool, etc) since they are typically dealt with via equality. However,
pointers to primitive types are covered by the identity umbrella.

D supports equality via the '==' operator, and supports identity via the
'is' operator. D has a second operator for identity, which uses a triplet
'===' token, plus its inverse '!=='.

The problem, if it indeed exists, is one of confusion.

Firstly: having two distinct operators to represent identity is surely
redundant. I understand Walter has noted problems with misinterpretation
between '==' and '===', particularly with certain printer fonts, and there's
been past suggestions made to remove that token. There has also been ongoing
suggestions to add an inverse companion for 'is' ... many such candidates
have been put forward, such as 'isnot', 'aint', and 'is not'. I ran into a
situation which tended to amplify a need for such a companion, which is why
it's mentioned here. I'll reiterate said situation further on.

Secondly: the terms 'identity' and 'equality' are applied in D with
significant overlap between the two, and it can be hard to get these terms
straight when they are interchanged. For example, the D 'is' identity
operator becomes an equality operator when used with primitive types. The D
'==' equality operator morphs into an identity operator when used with
Objects that don't override the default opEquals() method.

Because of this confusing duality I'll, instead, use the terms "shallow
equality" and "deep equality" for the rest of this post. Shallow equality
does a simple comparison of primitive hardware types, including byte, short,
long, float, double, pointers/references, etc. Deep equality performs
whatever test are necessary to determine whether one entity is equivalent to
another. In extreme cases, the latter might result in a visit to the
internet, or to a database. In other cases, the equivalent of a C memcmp()
might be performed.

Thirdly: D uses the '==' operator in a manner that conflicts with
traditional/habitual use (particularly for C & Java users). That is, the
operator is traditionally used for shallow equality, whereas D purportedly
uses it for deep equality. This can only breed confusion, in that those new
to D will invariably apply '==' where they should not. Indeed, habitual use
of '==' for shallow comparison is handled in D via the 'is' operator
instead.

Summary point 1: newcomers to D should likely use 'is' instead of '==',
since those two are "equivalent" from a traditional standpoint (both perform
a shallow test).

Fourthly: the duality of the D '==' operator can lead to unexpected
circumstance. For example, the default behavior of '==' is actually a
shallow test for primitives, a deep test for arrays (such as char[]), a
shallow test for Objects (via the default opEquals), a deep test for structs
instances, and a shallow test for struct pointers. Those who blindly call
this 'equality' should question their faith.

The confusion here is amplified by the conflict with traditional use of
'=='. Suppose I, through force of habit, have applied '==' throughout my
code and get it debugged and operating correctly. Let's further suppose some
maintenance engineer comes along and adds an opEquals() to some existing
class, for whatever purpose. Suddenly my code breaks. Why? The original code
was operating using the default shallow comparison performed by Object and
now that has been changed, by the maintenance engineer, to be some kind of
deep comparison. One can argue the original developer (me) should have been
explicit about using a shallow test in the first place. Indeed, this is
true. Which is partly why Summary Point 1 is worth considering seriously.
However, D does not currently lend itself to avoiding this sort of thing. In
fact, D seems to embrace exactly this bug by making the default behaviour of
'==' be of the shallow variety. A combination of changing tradition, yet not
really, can actually increase maintenance costs.

Summary point 2: The default shallow test for '==' tends to exaggerate the
potential for confusion. Not only because it does a role-defying shallow-
rather than deep- comparison, but because it can lead directly to fragile
maintenance builds via its changing behaviour.


Let's move onto the scenario painted by the original post. I'm going to cut
and paste a large chunk of the original here, because the points are, IMO,
still valid. Additionally, it's worth getting back to the point, since this
thread seems to have fallen into the grasp of ideaologists:


<quote>

Food for thought:

Java is explicit about the distinction between equality and identity, just
as D is. However, where D uses '==' as an equivalence operator, Java uses an
equals() method. Where D uses (triple) '===' and 'is' for identity purposes,
Java uses the traditional double '==' instead.

So, what's that got to do with the price of tea in China?

While porting 125,000 lines of Java to D, and an interesting thing happened.
You'll perhaps not be surprised to hear Java identity style tests are far
more prevalent than equivalence tests, but you may be surprised to know that
the former comprised 98.75% of all explicit tests within those 125,000
lines. To embellish, equals() was applied just 1.25% of the time.

Please note that we're talking about high-quality Java code that makes
extensive use of OO practices, and does indeed use equals() appropriately
when doing class comparisons. It's just that there's relatively little call
for that kind of thing once you get beyond writing sorting-algorithms,
containers, and so on. What I'd classify as "user-level code" appears to
apply equivalence testing rather seldom.

The Java code was converted mechanically, so it was thankfully easy to
change all identity tests into the D equivalent, which is the word 'is', or
the triplet '==='. Likewise, the inversion was converted from '!=' to the D
triplet '!=='. Each equals() instance was translated into the more
traditional twin '==' equivalence operator.

This has some notable ramifications; of which I'll attempt to be brief:

1) The converted Java code now has reams of  'is' statements throughout the
code, which makes it look 'interesting', to say the least. Quite nice,
actually; and eminantly readable, even vaguely amusing at times. The '!=='
instances look suitably alien by comparison. This amplifies the need for a
sibling for the word 'is', such as the oft proposes 'not' or the colloquial
'aint'.

BTW, using 'is' generates optimal code for that 98.75% of tests within that
large body of code. That is absolutely not the case when applying the
traditional operators instead. Look at the emitted codegen.

2) Anyone used to C or Java will habitually use the traditional '==' and
'!=' all over their D code. This is actually the *wrong* thing to do, since
those operators in D are for equivalence testing instead of identity
testing. This has implications for both performance and for "expectations of
behaviour". For example, the subsequent addition of an opEquals() to some
aggregate may break the overall system in all manner of subtle and
unexpected ways, where the original developer used '==' by force of habit.

3) Just as importantly, this highlights a significant divergence of D from C
and, IMO, in a rather fundamental manner. Think about this: you should
actually be using 'is' most of the time instead of (twin) '=='. How many of
you even use 'is' at all?

One might perhaps argue the numbers above are artificially inflated since
many of those test are applied to native types rather than to classes and
structs ~ that may be true. But we're talking about something that's already
well-developed as a habit in the community (the double '==') and we're
talking about consistency in the majority case.

</quote>


As you can hopefully see, the illustrative example performs shallow tesing
for the overwhelming majority of cases. Deep testing is used for a meager
1.25%. To put this into perspective, there are almost 8000 equivalence tests
made within that body of code.

Given all that, this thread has noted D would become backward-compatible if
the functionality of '==' and 'is' were to be role-reversed. That is, if
'==' were to fully retain its shallow heritage (like 'is' does), newcomers
would not have to even consider switching to using 'is' for the majority
case. This would naturally eliminate the concern over both Summary Points 1
& 2 above. Of course, there's zero expectation that would ever happen to
D -- this role reversal notion is pure speculation, and exists simply a
means of clarifying the current situation.

I hope this summarizes the thread content thus far. I haven't touched on the
subject brought up by Brad ("how to bridge the gap between user defined
types and built in types?"), which could use some exploration.

- Kris

-------------------

A few personal notes.

This thread was started as an observation. A reflection on interaction with
D. With a tip of the hat to GW, I'll point out again that this is not about
making a case for change in D. And it is most certainly nothing to do with
blind ideological perspective, as one individual appears to have showered
upon it.

I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?

brad domain.invalid writes:

..big snip..
Kris - thank you for taking the time to explain that - very well done. 
I see your point, and agree with you to an extent.  My view is that "==" 
must be consistant with the other compare operators (<,>, etc).  Sp if 
x<y is false and x>y is false then x==y should be true.  Depending on 
the class we are comparing this may not hold - but for sortable classes 
I think that it really should.  To me that is the least surprising result.

To me (I don't program in Java), I expect "==" to be a deep compare.  In 
  C if I compare structs, I get a (admittedly broken) deep compare.  If 
I compare pointers to structs, well I compare pointers - but the type is 
destinguished.  The same goes for C++, if I compare pointers I know my 
type, if I compare objects I expect a deep copy.

Ha!  Perhaps the solution is to drop "is" and "===", make "==" always a 
deep compare, and if you want to compare references, do
if (&a == &b) {} ...
I'm not serious :)

For me it feels more natural to keep D the way it is, and encourage a D 
idiom of "use 'is' to compare references".  To encourage that idiom, 
perhaps the default Object.opEquals() should be dropped, so you cannot 
compare objects with the == operator until you explicity define it.

Cheers
Brad

"Kris" <fu bar.com> writes:

<brad domain.invalid> wrote in message
 ..big snip..
 Kris - thank you for taking the time to explain that - very well done.
 I see your point, and agree with you to an extent.  My view is that "=="
 must be consistant with the other compare operators (<,>, etc).  Sp if
 x<y is false and x>y is false then x==y should be true.  Depending on
 the class we are comparing this may not hold - but for sortable classes
 I think that it really should.  To me that is the least surprising result.

Where compatability is not an issue, I fully agree. Concern over sorting is
certainly warranted.

 To me (I don't program in Java), I expect "==" to be a deep compare.  In
   C if I compare structs, I get a (admittedly broken) deep compare.  If
 I compare pointers to structs, well I compare pointers - but the type is
 destinguished.  The same goes for C++, if I compare pointers I know my
 type, if I compare objects I expect a deep copy.

 Ha!  Perhaps the solution is to drop "is" and "===", make "==" always a
 deep compare, and if you want to compare references, do
 if (&a == &b) {} ...
 I'm not serious :)

But there /is/ merit there :-)

I think a large part of of the confusion stems from the deep/shallow
flip-flopping of '=='.


 For me it feels more natural to keep D the way it is, and encourage a D
 idiom of "use 'is' to compare references".  To encourage that idiom,
 perhaps the default Object.opEquals() should be dropped, so you cannot
 compare objects with the == operator until you explicity define it.

I've been deliberately avoiding suggesting that, but it would /really/ help
the situation. Of course, it's in the same boat as opCmp() since Objects
should not be comparable until the developer explicitly say's so, either. I
wish you good luck in getting that changed.

Aye;

- Kris

 Cheers
 Brad

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

For me it feels more natural to keep D the way it is, and encourage a D
idiom of "use 'is' to compare references".  To encourage that idiom,
perhaps the default Object.opEquals() should be dropped, so you cannot
compare objects with the == operator until you explicity define it.

 
 I've been deliberately avoiding suggesting that, but it would /really/ help
 the situation. Of course, it's in the same boat as opCmp() since Objects
 should not be comparable until the developer explicitly say's so, either. I
 wish you good luck in getting that changed.

Walter prefers to have the non-Sortable classes throw up at runtime.

http://www.digitalmars.com/d/operatoroverloading.html:

"For some objects, testing for less or greater makes no sense.
  For these, override opCmp() with:

	class A
	{
	    int opCmp(Object o)
	    {
		assert(0);	// comparison makes no sense
		return 0;
	    }
	}"

I kinda like the java.lang.Comparable approach better, myself...
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Comparable.html

Especially since the default opCmp() sorts by *reference value* !
("hmm, let's see, when did I last wanted them sorted by pointer?")

--anders

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3k8iu$2kse$1 digitaldaemon.com...
 Kris wrote:

For me it feels more natural to keep D the way it is, and 
encourage a D
idiom of "use 'is' to compare references".  To encourage that 
idiom,
perhaps the default Object.opEquals() should be dropped, so you 
cannot
compare objects with the == operator until you explicity define 
it.

 I've been deliberately avoiding suggesting that, but it would 
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since 
 Objects
 should not be comparable until the developer explicitly say's so, 
 either. I
 wish you good luck in getting that changed.

 Walter prefers to have the non-Sortable classes throw up at 
 runtime.

 http://www.digitalmars.com/d/operatoroverloading.html:

 "For some objects, testing for less or greater makes no sense.
  For these, override opCmp() with:

 class A
 {
     int opCmp(Object o)
     {
 assert(0); // comparison makes no sense
 return 0;
     }
 }"

Perhaps we should drop all strong typing, have a variant type, and 
just do all checks at runtime?

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Not all comparators are as simple as linear ones.

An ordered pair complex number implementation of a comparator operator should
return a pair of floating point numbers in the range of -1..1 such that both
are zero if the compared values are equal and the location of the ordered pair
has an absolute value of one in the direction of the difference, if the
compared values are not equal.

A vector based complex number comparator operator would give more useful
information by simply returning the difference between the two vectors as an
angle and a scalar, resulting in the scalar being zero if the compared values
are equal and positive otherwise while the angle would represent the direction
of the difference within the complex number plain.

Perhaps it would be a good idea to include an editor with the D compiler, that
color codes the difference between assignment operators, comparators that
compare the "contents" of things (when available to compare) and comparators
that compare the "identities" of things, so that common mistakes would be
easier to avoid or correct.

It is a well known that mix-ups between the "=" and "==" operators are
responsable for a huge number of errors in languages that use both of them.  In
fact, I can barely "see" the difference between them here in Outlook Express
where I'm typing this note, because there is absolutely no gap between the
characters on my screen so it looks like one is simple a slightly stretched
version of the other.

It is even harder to see the difference between "==" and "===" here, and I find
myself constantly selecting small sections of text to count the characters just
to be able to read this thread because of it.  It's unfortunate that the
mathematical identity symbol isn't on most (if any) keyboards, and that also
that it is missing from so many fonts.

Perhaps "===" could be replaced with "_=_" just to make it easier to tell from
"==" but then again, that would reduce the intuitiveness of it.  Personally
though, although I think it is important that the language be as intuitive as
practical, I also think that if a choice has to be made between intuitive and
trustworthy, being intuitive takes a back seat.

Okay, so let's look at this from another angle.   Perhaps it would be better to
have "is" should be returning "(is.equal && is.identical)" and "==" should be
returning "(is.equal || is.identical)" such that "is.equal" always returns true
if the contents or values represented are the same, and "is.identical" always
returns true is the identities are the same.  The other comparator operators
would still be handled by "opCmp()" and would work as they do now.  Okay, so
it's a compromise... but then again, what isn't?

Hmmm.... maybe start by adding something like "opCmp.identities()" and
"opCmp.values()" or "opCmp.contents()" and build on that?  This raises the
question.... is it too late?

TZ

 Kris wrote:


*snip
 http://www.digitalmars.com/d/operatoroverloading.html:


*snip*

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Matthew wrote:

Walter prefers to have the non-Sortable classes throw up at 
runtime.


[...]
 Perhaps we should drop all strong typing, have a variant type, and 
 just do all checks at runtime?

Hooray, it'll all be JavaScript then! :-)

Seriously, I liked the "Comparable" interface myself -
even if has the downside of requiring "Object" params ?

But that's for another discussion - on opCmp() itself.

--anders

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 For me it feels more natural to keep D the way it is, and 
 encourage a D
 idiom of "use 'is' to compare references".  To encourage that 
 idiom,
 perhaps the default Object.opEquals() should be dropped, so you 
 cannot
 compare objects with the == operator until you explicity define 
 it.

 I've been deliberately avoiding suggesting that, but it would 
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since 
 Objects
 should not be comparable until the developer explicitly say's so, 
 either. I
 wish you good luck in getting that changed.

I don't see there's any avoiding it, since it's the answer.

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

 "Kris" <fu bar.com> wrote in message news:d3k82r$2ktg$1 digitaldaemon.com...
 I've been deliberately avoiding suggesting that, but it would
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since
 Objects
 should not be comparable until the developer explicitly say's so,
 either. I
 wish you good luck in getting that changed.


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kpif$304m$1 digitaldaemon.com...
 I don't see there's any avoiding it, since it's the answer.

There is one other possibility that comes to mind.  An identity comparison
could be performed "first" and cause "true" to be returned if the objects are
one and the same, but rather than simply returning "false" otherwise, a second
comparison could be done between the sizes of the objects being compared, and
if they don't match, then return false.  If the sizes do match, then the
contents could be compared to see if they are the same, and of so, true would
be returned.  If not, false would be returned.  It's a bit more involved, but
it's not ambiguous.  The result would be logically the same as comparing the
contents, but much faster in cases where the objects either are identical, or
are different sizes.  A further speedup could be done by returning false
durring the comparison of contents at the first sign of any difference.  This
would result in the worst case being that where the two objects are not the
same object but do in fact have completely matching contents.

Of course, this solution doesn't take into account the other comparator
operators, but a simple conversion from boolean (bit) to numeric (int) could go
something like...

Compare identities and return 0 (equals) if identical. Compare sizes and scan
for the first difference within the smaller size number of bytes. If no
differences are found, return the sign of the difference between the sizes.
Otherwise return the sign of the difference at that location where the first
difference was found.

This would allow all of the comparator operators to function predictably on any
object with a default opCmp() function in an efficient manor that does not
duplicate the functionality of the "is" operator.

TZ

Kevin Bealer <Kevin_member pathlink.com> writes:

In article <d3l51c$8m5$3 digitaldaemon.com>, TechnoZeus says...
 "Kris" <fu bar.com> wrote in message news:d3k82r$2ktg$1 digitaldaemon.com...
 I've been deliberately avoiding suggesting that, but it would
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since
 Objects
 should not be comparable until the developer explicitly say's so,
 either. I
 wish you good luck in getting that changed.


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kpif$304m$1 digitaldaemon.com...
 I don't see there's any avoiding it, since it's the answer.

There is one other possibility that comes to mind.  An identity comparison 
could be performed "first" and cause "true" to be returned if the objects are 
one and the same, but rather than simply returning "false" otherwise, a second 
comparison could be done between the sizes of the objects being compared, and
if 
they don't match, then return false.  If the sizes do match, then the contents 
could be compared to see if they are the same, and of so, true would be 
returned.  If not, false would be returned.  It's a bit more involved, but it's 
not ambiguous.  The result would be logically the same as comparing the 
contents, but much faster in cases where the objects either are identical, or 
are different sizes.  A further speedup could be done by returning false 
durring the comparison of contents at the first sign of any difference.  This
>would 
result in the worst case being that where the two objects are not the same 
object but do in fact have completely matching contents.

Of course, this solution doesn't take into account the other comparator 
operators, but a simple conversion from boolean (bit) to numeric (int) could go 
something like...

Compare identities and return 0 (equals) if identical. Compare sizes and scan 
for the first difference within the smaller size number of bytes. If no 
differences are found, return the sign of the difference between the sizes. 
Otherwise return the sign of the difference at that location where the first 
difference was found.

This would allow all of the comparator operators to function predictably on any 
object with a default opCmp() function in an efficient manor that does not 
duplicate the functionality of the "is" operator.

TZ

This would be misleading though.  Let's say you have a class with a char[]
and a doubly linked list.

class foo { char[] a; SomeDLListClass foo; }

The char[] is effectively /struct { char * data; int length; }/, which means
that your 'bytewise comparison' would be an identity comparison, ie identical 
strings would not compare equal unless the address (char * data) of the text was

the same.

You could change it to 'follow' these objects, and compare string data.  But
the doubly linked list would not be followable, because it is a cyclical data
structure.  Following pointers would cause a cycle, and thus an infinite loop.

You can fix this too.  Follow pointers, keeping track of all the "marked" 
objects and comparing them.  Compare the nonpointer regions of every
referenced object bytewise, but compare the pointer regions by following 
pointers.  Never check the same conceptual "pair" of objects twice, because you 
are tracking all the examined pointers.

This would work - it defines a deep comparison for any pair of structures.

But, it is also essentially the same algorithm a garbage collector uses, so its
probably too heavy for a default deep compare.

(But it might make a nice "deep dup" if such as thing was desired.)

Now... the above deep compare can be made feasible again - each class has to
define a method that does a deep compare, and knows which pointers to follow
and which not to follow.

..... But we already have that; that's exactly how people usually write the
opCmp() method.

(Round and round we go....)


I think this debate is simply an exercize in "I'm used to this" and "I'm used to
that".

For primitives, everyone uses == for primitive (intrinsic) equality.  Java
and C (mostly) use "==" for object identity.  D and C++ use == for object value.

(C doesn't have struct equality, but everyone uses pointers everywhere, so it's
almost the same.)

As for me, I like C++ and D's way, and D's way better; the only thing I would do
is maybe create "isnt".  It might be nice to have "floating" comparisons for
objects, ie. objects that can act like NaN.  Not to throw gasoline on this
thread...

Kevin

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Yes, if part of the "contents" of an item is in fact a pointer, then that
pointer would be part of the comparison for the default "==" as well as for
comparisons like ">" or "<" as I have proposed it... but such an item isn't
really equal unless all of it's contents are equal, including the pointer
portion.  As for "what you are used to" keep in mind that this would be only a
"default" built in comparison, which you could still override.  The idea is to
have "is" compare zero levels deep and "==" compare 1 level deep by default...
consistantly.

It's not a matter of who's used to what, in my opinion, so much as the
importance of making it so that what someone "becomes used to" in their early
experience with D can be trusted to work with other parts of D without having
to re-learn in opposition to what they have already learned in the same
language simply because they are dealing with a different kind of items.

TZ

"Kevin Bealer" <Kevin_member pathlink.com> wrote in message
news:d3nl2b$2joc$1 digitaldaemon.com...
 In article <d3l51c$8m5$3 digitaldaemon.com>, TechnoZeus says...
 "Kris" <fu bar.com> wrote in message news:d3k82r$2ktg$1 digitaldaemon.com...
 I've been deliberately avoiding suggesting that, but it would
 /really/ help
 the situation. Of course, it's in the same boat as opCmp() since
 Objects
 should not be comparable until the developer explicitly say's so,
 either. I
 wish you good luck in getting that changed.


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kpif$304m$1 digitaldaemon.com...
 I don't see there's any avoiding it, since it's the answer.

There is one other possibility that comes to mind.  An identity comparison
could be performed "first" and cause "true" to be returned if the objects are
one and the same, but rather than simply returning "false" otherwise, a second
comparison could be done between the sizes of the objects being compared, and if
they don't match, then return false.  If the sizes do match, then the contents
could be compared to see if they are the same, and of so, true would be
returned.  If not, false would be returned.  It's a bit more involved, but it's
not ambiguous.  The result would be logically the same as comparing the
contents, but much faster in cases where the objects either are identical, or
are different sizes.  A further speedup could be done by returning false
durring the comparison of contents at the first sign of any difference.  This
>would
result in the worst case being that where the two objects are not the same
object but do in fact have completely matching contents.

Of course, this solution doesn't take into account the other comparator
operators, but a simple conversion from boolean (bit) to numeric (int) could go
something like...

Compare identities and return 0 (equals) if identical. Compare sizes and scan
for the first difference within the smaller size number of bytes. If no
differences are found, return the sign of the difference between the sizes.
Otherwise return the sign of the difference at that location where the first
difference was found.

This would allow all of the comparator operators to function predictably on any
object with a default opCmp() function in an efficient manor that does not
duplicate the functionality of the "is" operator.

TZ

 This would be misleading though.  Let's say you have a class with a char[]
 and a doubly linked list.

 class foo { char[] a; SomeDLListClass foo; }

 The char[] is effectively /struct { char * data; int length; }/, which means
 that your 'bytewise comparison' would be an identity comparison, ie identical
 strings would not compare equal unless the address (char * data) of the text
was

 the same.

 You could change it to 'follow' these objects, and compare string data.  But
 the doubly linked list would not be followable, because it is a cyclical data
 structure.  Following pointers would cause a cycle, and thus an infinite loop.

 You can fix this too.  Follow pointers, keeping track of all the "marked"
 objects and comparing them.  Compare the nonpointer regions of every
 referenced object bytewise, but compare the pointer regions by following
 pointers.  Never check the same conceptual "pair" of objects twice, because you
 are tracking all the examined pointers.

 This would work - it defines a deep comparison for any pair of structures.

 But, it is also essentially the same algorithm a garbage collector uses, so its
 probably too heavy for a default deep compare.

 (But it might make a nice "deep dup" if such as thing was desired.)

 Now... the above deep compare can be made feasible again - each class has to
 define a method that does a deep compare, and knows which pointers to follow
 and which not to follow.

 ..... But we already have that; that's exactly how people usually write the
 opCmp() method.

 (Round and round we go....)


 I think this debate is simply an exercize in "I'm used to this" and "I'm used
to
 that".

 For primitives, everyone uses == for primitive (intrinsic) equality.  Java
 and C (mostly) use "==" for object identity.  D and C++ use == for object
value.

 (C doesn't have struct equality, but everyone uses pointers everywhere, so it's
 almost the same.)

 As for me, I like C++ and D's way, and D's way better; the only thing I would
do
 is maybe create "isnt".  It might be nice to have "floating" comparisons for
 objects, ie. objects that can act like NaN.  Not to throw gasoline on this
 thread...

 Kevin

Sean Kelly <sean f4.ca> writes:

In article <d3k3tl$2hmq$1 digitaldaemon.com>, Kris says...
I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?

Good question.  I only read moderated C++ newsgroups for this very reason.  But
moderation means moderators which I suspect is unlikely here.  I also find it
increasingly difficult to separate signal from noise on this NG.  I tried
skipping threads once they started degrading but it wasn't uncommon for me to
read something interesting a few days later that references a post I'd skipped.
It might be bad to say so, but the best approach I've found is to just filter by
author.  That might be restricting myself to a subset of folks with a similar
background or experience, but I simply don't have the time to wade through reams
of antagonism for the few gems that lurk therein.  Perhaps it would be
sufficient to offer a few more newsgroups to separate interests: language,
library, advocacy, etc?  Mailing lists work as well, but I can understand the
desire to avoid such exclusivity.


Sean

brad domain.invalid writes:

Sean Kelly wrote:
 In article <d3k3tl$2hmq$1 digitaldaemon.com>, Kris says...
 
I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?

 

<>Snip<>
I've also noticed it physically tiring reading threads recently.  People 
on this NG tend (IMHO) to be overly verbose, overly sensitive, and 
overly abrasive.
Anyone else notice that Walter doesn't get involved in these discussions 
anymore?  Perhaps he is tired also.
I would prefer shorter, more on topic messages - a 300 word max perhaps? :)

Brad

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Newsgroup threads do tend to drift.  It's a fact that even moderation and
careful attention to staying on topic can't eliminate.  This point comming up
in this thread is a good example.  If your newsgroup viewer can arrange posts
according to their sub-thread hierarchy (which post someone responded to) you
can choose to simply skip branches that go off in a direction that you don't
care to follow.

As for keeping the posts short, I personally find it harder to communicate
clearly in few words... but I do like the idea of having a sort of "to the
point" newsgroup that would only allow posts of a certain number of characters
or less... in order to make sure that nothing in that newsgroup would take long
to read, and people who post there would have to choose carefully what is most
worth squeezing into the available space.

Maybe Walter would be able to find time to follow along in a group like that. 
In fact, when he first asked me to post some of my thoughts in here, I
expressed that same concern to him... following newsgroups and lacking time
generally don't go well together.

TZ

<brad domain.invalid> wrote in message news:d3k6v1$2k09$1 digitaldaemon.com...
 Sean Kelly wrote:
 In article <d3k3tl$2hmq$1 digitaldaemon.com>, Kris says...

I think this just highlights the difficulties surrounding clear
communication in an NG environment. There's language barriers, proximity-cue
barriers, social and educational barriers, along with barriers of purpose
and intent. The fact that not each and every thread is filled with
antagonism can be surprising to some, but many of them are. I find it to be
an increasingly painful and fruitless exercise to both read and initiate
threads here; even those relating my trivial experiences with D (such as
this one). Further, attempting to keep a thread on track is truly becoming
an impossible task (hence, the request for a summary).

I can't imagine I'm the only one who feels this way ~ which prompts a
question: what, if anything, can be done about it?


 <>Snip<>
 I've also noticed it physically tiring reading threads recently.  People
 on this NG tend (IMHO) to be overly verbose, overly sensitive, and
 overly abrasive.
 Anyone else notice that Walter doesn't get involved in these discussions
 anymore?  Perhaps he is tired also.
 I would prefer shorter, more on topic messages - a 300 word max perhaps? :)

 Brad

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

 The topic is /not/ a campaign to change the language. I'll repeat that: it
 is NOT a campaign, since it's been shown such causes, however well
 intentioned, and/or well supported, are naught but exercises in futility.

It does seem to be a campaign about preferring how '==' is done in Java?
(even if doing it not by a language change, but switching '==' for 'is')

 D supports the notions of equality and identity. Equality can be thought of
 as a test to see if two individual entities have equivalent 'value', whereas
 identity can be thought of as a test whether two entities are, in fact, one
 and the same. Identity is rarely discussed for primitive types (int, long,
 bool, etc) since they are typically dealt with via equality. However,
 pointers to primitive types are covered by the identity umbrella.

Pointers are being compared as integers, actually. Thus: equality ?

But I agree, it's pretty confusing in D that has both kinds (p/r).

 Firstly: having two distinct operators to represent identity is surely
 redundant. I understand Walter has noted problems with misinterpretation
 between '==' and '===', particularly with certain printer fonts, and there's
 been past suggestions made to remove that token. There has also been ongoing
 suggestions to add an inverse companion for 'is' ... many such candidates
 have been put forward, such as 'isnot', 'aint', and 'is not'. I ran into a
 situation which tended to amplify a need for such a companion, which is why
 it's mentioned here. I'll reiterate said situation further on.

Both '===' and 'is' map to TOKidentity, so it is the SAME thing.
I'm assuming that both '!==' and 'isnt' would be TOKnotidentity.

(I'm talking about the actual tokens used by the DMD lexer, here)

 Secondly: the terms 'identity' and 'equality' are applied in D with
 significant overlap between the two, and it can be hard to get these terms
 straight when they are interchanged. For example, the D 'is' identity
 operator becomes an equality operator when used with primitive types. The D
 '==' equality operator morphs into an identity operator when used with
 Objects that don't override the default opEquals() method.

The same definition of "equals()" is being implemented in 
java.lang.Object. It doesn't mean the operator morphs, IMHO.

However, the identity operator does "morph" with primitives.

 Because of this confusing duality I'll, instead, use the terms "shallow
 equality" and "deep equality" for the rest of this post. Shallow equality
 does a simple comparison of primitive hardware types, including byte, short,
 long, float, double, pointers/references, etc. Deep equality performs
 whatever test are necessary to determine whether one entity is equivalent to
 another. In extreme cases, the latter might result in a visit to the
 internet, or to a database. In other cases, the equivalent of a C memcmp()
 might be performed.

That's OK, "shallow equality" is normally used as a synonym for
identity and likewise "deep equality" is used for equality.

As you say above: identity/shallow is seldom used with primitive
types, it's normally called equality (which would be "deep" here!)

Without the drama, the deep equality normally calls opEquals.
(or does the memcmp, for structs/arrays/strings "primitives")

 Thirdly: D uses the '==' operator in a manner that conflicts with
 traditional/habitual use (particularly for C & Java users). That is, the
 operator is traditionally used for shallow equality, whereas D purportedly
 uses it for deep equality. This can only breed confusion, in that those new
 to D will invariably apply '==' where they should not. Indeed, habitual use
 of '==' for shallow comparison is handled in D via the 'is' operator
 instead.

How would an operator that only affects Objects cause problems
for C users, that doesn't have any objects ? It's only a problem
if the D references are regarded as being the *same* as C pointers ?

If they are instead regarded as types or something, they work the
same as the primitives do - when it comes to doing equality tests ?
i.e. an Int wrapper class would behave similiar to an int primitive

The pointers work the same way in D as in C: integer comparison.

 Summary point 1: newcomers to D should likely use 'is' instead of '==',
 since those two are "equivalent" from a traditional standpoint (both perform
 a shallow test).

We disagree in terminology here. Primitive types should use '==',
which I instead would classify as doing a "deep equality" test.

To me, a shallow equality test would be more like comparing
&i and &j for the fictional case of "int i,j;". But again,
one does not normally talk about the identity of primitives ?
(even if it's fully OK for the 'is' operator to fall back on it)

 Fourthly: the duality of the D '==' operator can lead to unexpected
 circumstance. For example, the default behavior of '==' is actually a
 shallow test for primitives, a deep test for arrays (such as char[]), a
 shallow test for Objects (via the default opEquals), a deep test for structs
 instances, and a shallow test for struct pointers. Those who blindly call
 this 'equality' should question their faith.

Pointers are an exception, that is true. The rest is terminology.

 The confusion here is amplified by the conflict with traditional use of
 '=='. Suppose I, through force of habit, have applied '==' throughout my
 code and get it debugged and operating correctly. Let's further suppose some
 maintenance engineer comes along and adds an opEquals() to some existing
 class, for whatever purpose. Suddenly my code breaks. Why? The original code
 was operating using the default shallow comparison performed by Object and
 now that has been changed, by the maintenance engineer, to be some kind of
 deep comparison. One can argue the original developer (me) should have been
 explicit about using a shallow test in the first place. Indeed, this is
 true. Which is partly why Summary Point 1 is worth considering seriously.
 However, D does not currently lend itself to avoiding this sort of thing. In
 fact, D seems to embrace exactly this bug by making the default behaviour of
 '==' be of the shallow variety. A combination of changing tradition, yet not
 really, can actually increase maintenance costs.

But not defining the opEquals, you are saying that the state of your 
objects does not make them into equal (i.e. that they are all unique)

If the "maintenance engineer" redefines this into adding state, say
by comparing the name of your class or whatever - he changes this...

And it breaks, since now all the objects with the same name are equal ?
(and again, we seem to be having a disagreement on Summary Point 1)

 Summary point 2: The default shallow test for '==' tends to exaggerate the
 potential for confusion. Not only because it does a role-defying shallow-
 rather than deep- comparison, but because it can lead directly to fragile
 maintenance builds via its changing behaviour.

I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e identity)

As someone else posted in this thread: it's somewhat confusing at
first, but it is also the only sane default that Object could have ?

[...snipped out the original post...]

 As you can hopefully see, the illustrative example performs shallow tesing
 for the overwhelming majority of cases. Deep testing is used for a meager
 1.25%. To put this into perspective, there are almost 8000 equivalence tests
 made within that body of code.

Q: Do you include equality between primitives into that number for 
"shallow" ? That would explain their high number, at least to me.

And how many of those are compares with null ? Those numbers would
be interesting to know (you said the translation was machine done)

 Given all that, this thread has noted D would become backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. That is, if
 '==' were to fully retain its shallow heritage (like 'is' does), newcomers
 would not have to even consider switching to using 'is' for the majority
 case. This would naturally eliminate the concern over both Summary Points 1
 & 2 above. Of course, there's zero expectation that would ever happen to
 D -- this role reversal notion is pure speculation, and exists simply a
 means of clarifying the current situation.

I think the only backwards compatibility involved here is with Java...
But that's mostly because our definitions differ, including SP 1 and 2.

 I hope this summarizes the thread content thus far. I haven't touched on the
 subject brought up by Brad ("how to bridge the gap between user defined
 types and built in types?"), which could use some exploration.

Thanks for summarizing this post up. Now I know what our difference is.
It seems to boil down to whether an Object is a regular type (like a
"struct" is), or if it's a hidden pointer type (like a "struct*" is)

And that's also why I said earlier that you wanted D to "treat the
references as pointers". Since that is what Java ends up doing ?
(that is: when talking about the '==' operator, nothing else here)

I like C, and I like Java. And, for the most part, I like D *a lot*.
And I would not want any of them to change their '==' operators...
(well, it's just a wee bit too late for Java to introduce '===' now)


As for the name of the tokens: if '===' and '!==' are causing confusion
and are hard to print, then they can be replaced by 'is' and 'isnt' ?
I would prefer if the old ones were left in, but can live without them.

But for what they do, *I* find it to be pretty straight-forward in D:

  == , Equality Expression, "deep equality" (primitive,memcmp,opEquals)
  !=

=== , Identity Expression, "shallow equality" (pointer/reference)
!==


And it doesn't seem much to argue about? Like you said all along, it's
not like Walter is going to change the D language on this point...

As for introducing "isnt", it's a trivial patch for an Open Source D
compiler. But it would be sad to have to translate it to '!==' for DMD ?

--anders

PS. Speaking of barriers, this timezone and I now bids you good night.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3k7jp$2jg7$1 digitaldaemon.com...
 Kris wrote:

 The topic is /not/ a campaign to change the language. I'll repeat 
 that: it
 is NOT a campaign, since it's been shown such causes, however 
 well
 intentioned, and/or well supported, are naught but exercises in 
 futility.

 It does seem to be a campaign about preferring how '==' is done in 
 Java?
 (even if doing it not by a language change, but switching '==' for 
 'is')

I don't think that's valid. Kris has pointed out a very disturbing 
design flaw in the syntax of the language, and has suggested _what 
he sees_ as the most pragmatic solution, based on his experience I 
happen to disagree with his solution, and favour a full and proper 
addressing of the flaw, but I agree with his main thesis 
nonetheless.

 Secondly: the terms 'identity' and 'equality' are applied in D 
 with
 significant overlap between the two, and it can be hard to get 
 these terms
 straight when they are interchanged. For example, the D 'is' 
 identity
 operator becomes an equality operator when used with primitive 
 types. The D
 '==' equality operator morphs into an identity operator when used 
 with
 Objects that don't override the default opEquals() method.

 The same definition of "equals()" is being implemented in 
 java.lang.Object. It doesn't mean the operator morphs, IMHO.

But Java does not allow operator overloading, so it cannot come up. 
The only problem with Java is, as you say "the identity operator 
does "morph" with primitives".


 Summary point 2: The default shallow test for '==' tends to 
 exaggerate the
 potential for confusion. Not only because it does a role-defying 
 shallow-
 rather than deep- comparison, but because it can lead directly to 
 fragile
 maintenance builds via its changing behaviour.

 I'm not sure how this is a change from Java... Both have the same
 implementation of equality for the top-level Object (i.e identity)

opEquals() again. Or am I missing something in your point?

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Matthew wrote:

The same definition of "equals()" is being implemented in 
java.lang.Object. It doesn't mean the operator morphs, IMHO.

 
 But Java does not allow operator overloading, so it cannot come up. 

I'm not sure I follow ? If I call equals() on two Java objects -
both using the default implementation of java.lang.Object.equals,
I get identity. To get something else, equals() must be overridden.

 The only problem with Java is, as you say "the identity operator 
 does "morph" with primitives".

Java does not have the '===' identity operator, so that "problem"
is all D's. It's pretty common to have such an identity silently fall
back on equality, though ? Just as the default equality being identity ?

I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e identity)

 
 opEquals() again. Or am I missing something in your point?

Not at all. D's opEquals and Java's equals are pretty much equivalent.
(including the default implementation of each, which calls on identity)

Will go ahead and read those CUJ articles and the longer responses now.

--anders

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

I think we're slipping past each other's understandings here. Let me 
try and get back on your rail, or you on mine. :-)

Basically, I understood you to have said that D and Java had 
identical issues wrt opEquals().

I was pointing out that, because D supports operator overloading, 
and specifically of == to translate to calls to opEquals() on class 

client code can be undermined by (non-compile-breaking) changes to a 
class's interface.

Thus, Java code saying obj1 == obj2 will always mean compare 
identity. With D, however, it can mean compare identity, unless and 
until the type of obj1/obj2 is overridden with opEquals().



"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3l3iu$6ov$1 digitaldaemon.com...
 Matthew wrote:

The same definition of "equals()" is being implemented in 
java.lang.Object. It doesn't mean the operator morphs, IMHO.

 But Java does not allow operator overloading, so it cannot come 
 up.

 I'm not sure I follow ? If I call equals() on two Java objects -
 both using the default implementation of java.lang.Object.equals,
 I get identity. To get something else, equals() must be 
 overridden.

 The only problem with Java is, as you say "the identity operator 
 does "morph" with primitives".

 Java does not have the '===' identity operator, so that "problem"
 is all D's. It's pretty common to have such an identity silently 
 fall
 back on equality, though ? Just as the default equality being 
 identity ?

I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e 
identity)

 opEquals() again. Or am I missing something in your point?

 Not at all. D's opEquals and Java's equals are pretty much 
 equivalent.
 (including the default implementation of each, which calls on 
 identity)

 Will go ahead and read those CUJ articles and the longer responses 
 now.

 --anders 

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Matthew wrote:

 I think we're slipping past each other's understandings here. Let me 
 try and get back on your rail, or you on mine. :-)
 
 Basically, I understood you to have said that D and Java had 
 identical issues wrt opEquals().

That was kinda obvious from reading article
http://www.cuj.com/documents/cuj0310wilson/,
but I'm afraid I can't use that material here.

Anyway, it's understood here too.

 I was pointing out that, because D supports operator overloading, 
 and specifically of == to translate to calls to opEquals() on class 

 client code can be undermined by (non-compile-breaking) changes to a 
 class's interface.

Assuming that you do use equals() to check two objects,
you have the same problem there. And if you don't, well:
couldn't you just check for identity in D too, then ?

It seems we differ in our view in the importance of opEquals.
(to me, it's an important part of the object / interface design)
But agree that Java decided to "flip" operators for reference types.

 Thus, Java code saying obj1 == obj2 will always mean compare 
 identity. With D, however, it can mean compare identity, unless and 
 until the type of obj1/obj2 is overridden with opEquals().

It's just semantics, and choice of "operators". (or lack of, in Java)

In D code, saying obj1 === obj2 will always mean compare identity.
With Java, when you use obj1.equals(obj2) it can mean compare identity, 
unless and until the default implementation of equals is overridden.

Potato, Potatoh.

--anders

PS.
It *would* be simpler if "null == this" did not segfault, as discussed
in that other thread. On the other hand, so does "null.equals(this)" ?
I haven't isolated all cases *when* "this == null" segv, but it does...
(in Java, equals(null) is defined to return false. Part of the contract)

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Anders F Björklund" <afb algonet.se> wrote in message 
news:d3l5e5$8h8$1 digitaldaemon.com...
 I was pointing out that, because D supports operator overloading, 
 and specifically of == to translate to calls to opEquals() on 

 robust client code can be undermined by (non-compile-breaking) 
 changes to a class's interface.

 Assuming that you do use equals() to check two objects,
 you have the same problem there.

Indeed.


 It seems we differ in our view in the importance of opEquals.
 (to me, it's an important part of the object / interface design)
 But agree that Java decided to "flip" operators for reference 
 types.

I don't like fat base classes, and, IMO, Object qualifies as such. 
The damnable bloated corpulent beast. One more waffer .... :-)

Others naturally see it differently.


 In D code, saying obj1 === obj2 will always mean compare identity.
 With Java, when you use obj1.equals(obj2) it can mean compare 
 identity, unless and until the default implementation of equals is 
 overridden.

 Potato, Potatoh.

No, I think they are materially different. I think that, unless 
there is a move for a fix, diligent D instructors will have to 
recommend that people use only 'is' and opEquals(), and even that 
won't be perfect. :-(

Kercrack!

What was that? Oh, someone just shot themselves in the foot again. 
;)

 --anders

 PS.
 It *would* be simpler if "null == this" did not segfault, as 
 discussed
 in that other thread. On the other hand, so does 
 "null.equals(this)" ?
 I haven't isolated all cases *when* "this == null" segv, but it 
 does...
 (in Java, equals(null) is defined to return false. Part of the 
 contract)

Agreed. And as for the platform-specific differences ... <g>

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Matthew wrote:

 It *would* be simpler if "null == this" did not segfault, as 
 discussed in that other thread. On the other hand, so does 
 "null.equals(this)" ? I haven't isolated all cases *when* "this ==
 null" segv, but it does... (in Java, equals(null) is defined to
 return false. Part of the contract) >

 
 Agreed. And as for the platform-specific differences ... <g>

I think it does segfault on Windows too ? And that the Windows
runtime Exception is just Walter catching this and wrapping it ?

I don't run Windows on a regular basis, but it does sound slow.

ie.
    if (object !== null) do_stuff(object);

vs.
    try { doStuff(object); } catch (NullError ex) {}

Not sure which one is the worst to clean up after... ?
(as GDB does point to the correct source line on *null)

--anders

Georg Wrede <georg.wrede nospam.org> writes:

Instead of talking about "D on windows" and "D on <unix, or linux or 
whatever>", could you be more specific in the future.

Like "DMD" and "GDC"? (If that's what you mean.)

And "DMD on windows" and "DMD on <unix, or linux or whatever>", when 
that's what you mean.

Anders F Björklund wrote:
 Matthew wrote:
 
 It *would* be simpler if "null == this" did not segfault, as 
 discussed in that other thread. On the other hand, so does 
 "null.equals(this)" ? I haven't isolated all cases *when* "this ==
 null" segv, but it does... (in Java, equals(null) is defined to
 return false. Part of the contract) >


 Agreed. And as for the platform-specific differences ... <g>

 
 
 I think it does segfault on Windows too ? And that the Windows
 runtime Exception is just Walter catching this and wrapping it ?
 
 I don't run Windows on a regular basis, but it does sound slow.
 
 ie.
    if (object !== null) do_stuff(object);
 
 vs.
    try { doStuff(object); } catch (NullError ex) {}
 
 Not sure which one is the worst to clean up after... ?
 (as GDB does point to the correct source line on *null)
 
 --anders

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Georg Wrede wrote:

 I think it does segfault on Windows too ? And that the Windows
 runtime Exception is just Walter catching this and wrapping it ?


 Instead of talking about "D on windows" and "D on <unix, or linux or 
 whatever>", could you be more specific in the future.

Will do, in this particular case I was talking about DMD however:

Dereferencing null causes some kind of hardware action on all,
be it called Access Violation, Segmentation Fault or Bus Error.

And it's currently being caught and handled only under Windows,
although there was a patch circulating to add it to Linux too ?


With GDC, it is not being caught on any platform yet (AFAIK).

--anders

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

right, but at the same time this is true of any function, and an operator is
afterall simply a function with an alternative syntax.

However, here is a good case for implicit importing.  Consider for example, if
it was decided somewhere along the way that then internal obj module should be
replaced by a new module named dobjects which handled such things as the opCmp
function differently.  The new module would be made internal, and it should
still be possible to explicitly import the older module to override it's
functionality.

Programs which call an explicit import to obj would therefore not run the risk
of getting broken when the new dobjects module supercedes it as an internal
module, but would also not benefit from the improvements made. Programs which
do not call an explicit import would benefit from the replacement module, but
would also run the risk of being broken by one or more of the changes.

Likewise, if a non-internal module isn't explicitly imported but is still used,
then it's functionality could be upgraded either through an upgrade to that
module, or by making a new and improved module the new default module for the
same functionality, but if a program explicitly imports a module, then only a
direct change to that module would effect it.

TZ

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3l4ab$7dm$1 digitaldaemon.com...
 I think we're slipping past each other's understandings here. Let me
 try and get back on your rail, or you on mine. :-)

 Basically, I understood you to have said that D and Java had
 identical issues wrt opEquals().

 I was pointing out that, because D supports operator overloading,
 and specifically of == to translate to calls to opEquals() on class

 client code can be undermined by (non-compile-breaking) changes to a
 class's interface.

 Thus, Java code saying obj1 == obj2 will always mean compare
 identity. With D, however, it can mean compare identity, unless and
 until the type of obj1/obj2 is overridden with opEquals().



 "Anders F Björklund" <afb algonet.se> wrote in message
 news:d3l3iu$6ov$1 digitaldaemon.com...
 Matthew wrote:

The same definition of "equals()" is being implemented in
java.lang.Object. It doesn't mean the operator morphs, IMHO.

 But Java does not allow operator overloading, so it cannot come
 up.

 I'm not sure I follow ? If I call equals() on two Java objects -
 both using the default implementation of java.lang.Object.equals,
 I get identity. To get something else, equals() must be
 overridden.

 The only problem with Java is, as you say "the identity operator
 does "morph" with primitives".

 Java does not have the '===' identity operator, so that "problem"
 is all D's. It's pretty common to have such an identity silently
 fall
 back on equality, though ? Just as the default equality being
 identity ?

I'm not sure how this is a change from Java... Both have the same
implementation of equality for the top-level Object (i.e
identity)

 opEquals() again. Or am I missing something in your point?

 Not at all. D's opEquals and Java's equals are pretty much
 equivalent.
 (including the default implementation of each, which calls on
 identity)

 Will go ahead and read those CUJ articles and the longer responses
 now.

 --anders

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 Secondly: the terms 'identity' and 'equality' are applied in D 
 with
 significant overlap between the two, and it can be hard to get 
 these terms
 straight when they are interchanged. For example, the D 'is' 
 identity
 operator becomes an equality operator when used with primitive 
 types.

Ok, I didn't realise that. That's not good.

 The D
 '==' equality operator morphs into an identity operator when used 
 with
 Objects that don't override the default opEquals() method.

Yes, I knew that. It's been a longstanding source of criticism from 
many sources, including me.

 Because of this confusing duality I'll, instead, use the terms 
 "shallow
 equality" and "deep equality" for the rest of this post.

Not sure that's helpful. I'll have to be translating 'em back to 
identity and equality while reading. ;/

 Shallow equality
 does a simple comparison of primitive hardware types, including 
 byte, short,
 long, float, double, pointers/references, etc. Deep equality 
 performs
 whatever test are necessary to determine whether one entity is 
 equivalent to
 another. In extreme cases, the latter might result in a visit to 
 the
 internet, or to a database. In other cases, the equivalent of a C 
 memcmp()
 might be performed.

I'm pretty dubious about these definitions, but maybe it clears up 
further on. Reading on ...

 Thirdly: D uses the '==' operator in a manner that conflicts with
 traditional/habitual use (particularly for C & Java users). That 
 is, the
 operator is traditionally used for shallow equality, whereas D 
 purportedly
 uses it for deep equality. This can only breed confusion, in that 
 those new
 to D will invariably apply '==' where they should not. Indeed, 
 habitual use
 of '==' for shallow comparison is handled in D via the 'is' 
 operator
 instead.

I disagree with this, no doubt because C++/Python/Ruby do not do 
this.

 Summary point 1: newcomers to D should likely use 'is' instead of 
 '==',
 since those two are "equivalent" from a traditional standpoint 
 (both perform
 a shallow test).

Given what you say about 'is' being applicable to built-in types, 
that's arguable, I guess, but it seems like two wrongs not making a 
right to me.

 Fourthly: the duality of the D '==' operator can lead to 
 unexpected
 circumstance. For example, the default behavior of '==' is 
 actually a
 shallow test for primitives, a deep test for arrays (such as 
 char[]), a
 shallow test for Objects (via the default opEquals), a deep test 
 for structs
 instances, and a shallow test for struct pointers. Those who 
 blindly call
 this 'equality' should question their faith.

Agreed

 The confusion here is amplified by the conflict with traditional 
 use of
 '=='. Suppose I, through force of habit, have applied '==' 
 throughout my
 code and get it debugged and operating correctly. Let's further 
 suppose some
 maintenance engineer comes along and adds an opEquals() to some 
 existing
 class, for whatever purpose. Suddenly my code breaks. Why? The 
 original code
 was operating using the default shallow comparison performed by 
 Object and
 now that has been changed, by the maintenance engineer, to be some 
 kind of
 deep comparison. One can argue the original developer (me) should 
 have been
 explicit about using a shallow test in the first place. Indeed, 
 this is
 true. Which is partly why Summary Point 1 is worth considering 
 seriously.
 However, D does not currently lend itself to avoiding this sort of 
 thing. In
 fact, D seems to embrace exactly this bug by making the default 
 behaviour of
 '==' be of the shallow variety. A combination of changing 
 tradition, yet not
 really, can actually increase maintenance costs.

Strongly agreed. A very powerful point. Another good argument for 
the removal of opEquals() from Object.

Note: I made some of these same points in "Identity and Equality: 
Syntax and Semantics" (CUJ, Oct 2003; 
http://www.cuj.com/articles/2003/0310/) and "Identity and Equality 
in .NET" (DDJ, June 2004; http://www.ddj.com/documents/ddj0406k/), 
though I discussed the dangerous behaviour you've outlined in terms 


If I may be so crass as to quote myself, it seems I said something 
that at least two of us would agree with:


operators on a per-class basis. (In fact, it mandates that if you 
overload == then you must overload !=, and vice versa, which is 
probably a good idea.) However, this is an accident waiting to 
happen. If your class does not overload these operators, and does 
not inherit from one that does, then using == will be translated to 
an identity check, i.e. equivalent to a call to 
Object.ReferenceEquals(). However, if your class, or one of its 
ancestors, does overload these operators, use of == will result in a 
call to that overloaded operator which, as we see below, will be 
implemented as a call to the instance/non-static Equals() method for 

Object.Equals() and Object.GetHashCode() if you overload == and !=. 
Again this is probably a good idea, though it does make writing 
simple test programs for article research somewhat tedious.)


I don't know if I'm the only one who thinks so, but this situation 
seems crazy. Testing for identity and equality are completely 
different things conceptually [5]. To not know which you are getting 
when you type in == is nonsensical. Having to resort to the 
documentation (should there be any) or the assembler on a per-class 
basis to elicit the semantics of basic syntactic elements doesn't 
stand up. Even worse, the class(es) you are working with may be 
redefined after your first version of code is written and working, 
resulting in both semantic and probably performance changes to your 

counter that C++ (which is, perhaps obviously, my language of 
choice) provides the same dangers. But this does not really hold 
water. In C++, the semantics of == are only changed from meaning a 

be shifted from identity to equality, or vice versa, by the informed 
action of experienced developers. (Of course, the .NET 
version-locking mechanisms are designed in part to prevent such 
potentially destructive changes in semantics from affecting client 
code, but that can only work when they are used. During development, 
or when using publicly available binaries/source, it is 
impractical/undesirable to operate these mechanisms, hence the risk 
is real.)

[5] Of course, equality testing is kind of a superset of identity 
testing in that when two object references refer to the same object 
it is axiomatic that the objects so referenced are equal."


 Summary point 2: The default shallow test for '==' tends to 
 exaggerate the
 potential for confusion. Not only because it does a role-defying 
 shallow-
 rather than deep- comparison, but because it can lead directly to 
 fragile
 maintenance builds via its changing behaviour.

Totally lost me on that one. Is it covered below? If not, will you 
rephrase?

 Let's move onto the scenario painted by the original post. I'm 
 going to cut
 and paste a large chunk of the original here, because the points 
 are, IMO,
 still valid. Additionally, it's worth getting back to the point, 
 since this
 thread seems to have fallen into the grasp of ideaologists:


 <quote>

 Food for thought:

 Java is explicit about the distinction between equality and 
 identity, just
 as D is. However, where D uses '==' as an equivalence operator, 
 Java uses an
 equals() method. Where D uses (triple) '===' and 'is' for identity 
 purposes,
 Java uses the traditional double '==' instead.

 So, what's that got to do with the price of tea in China?

 While porting 125,000 lines of Java to D, and an interesting thing 
 happened.
 You'll perhaps not be surprised to hear Java identity style tests 
 are far
 more prevalent than equivalence tests,

Well, yes, I am. Perhaps that's because I don't do much Java?

 but you may be surprised to know that
 the former comprised 98.75% of all explicit tests within those 
 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

Very surprised indeed. Is it plausible that this is skewed by 
application specificity? What is that code base doing?

<snip>

 This has some notable ramifications; of which I'll attempt to be 
 brief:

 1) The converted Java code now has reams of  'is' statements 
 throughout the
 code, which makes it look 'interesting', to say the least. Quite 
 nice,
 actually; and eminantly readable, even vaguely amusing at times. 
 The '!=='
 instances look suitably alien by comparison. This amplifies the 
 need for a
 sibling for the word 'is', such as the oft proposes 'not' or the 
 colloquial
 'aint'.

Sure. No brainer. 'is' and '!==' are odd little bedfellows.

 BTW, using 'is' generates optimal code for that 98.75% of tests 
 within that
 large body of code. That is absolutely not the case when applying 
 the
 traditional operators instead. Look at the emitted codegen.

 2) Anyone used to C or Java will habitually use the traditional 
 '==' and
 '!=' all over their D code. This is actually the *wrong* thing to 
 do, since
 those operators in D are for equivalence testing instead of 
 identity
 testing.

Do you mean "since those operators in D are [sometimes, depending on 
the types of the comparands, used ]for equivalence testing instead 
of identity testing."?

If not, what do you mean?

 This has implications for both performance and for "expectations 
 of
 behaviour". For example, the subsequent addition of an opEquals() 
 to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force 
 of habit.

Agree with the level of concern you're expressing with this.

This all stems from the use of references without pointer syntax,

 3) Just as importantly, this highlights a significant divergence 
 of D from C
 and, IMO, in a rather fundamental manner. Think about this: you 
 should
 actually be using 'is' most of the time instead of (twin) '=='. 
 How many of
 you even use 'is' at all?

Essentially you're saying that use of == for class types, or in 
generic code that may be applied to class types, is subject to 
hidden and potentially destructive change. This was the crux of my 

somewhat bemused/baffled why I didn't see that it also applies to D, 
and quite chagrined now to see that it does. Huge blunder.)

 One might perhaps argue the numbers above are artificially 
 inflated since
 many of those test are applied to native types rather than to 
 classes and
 structs ~ that may be true. But we're talking about something 
 that's already
 well-developed as a habit in the community (the double '==') and 
 we're
 talking about consistency in the majority case.

It's irrelevant whether it's likely to happen 90% of the time or 
0.9% of the time. It's a major design blunder in either case.

 </quote>

<snip>

 Given all that, this thread has noted D would become 
 backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. That 
 is, if
 '==' were to fully retain its shallow heritage (like 'is' does), 
 newcomers
 would not have to even consider switching to using 'is' for the 
 majority
 case. This would naturally eliminate the concern over both Summary 
 Points 1
 & 2 above. Of course, there's zero expectation that would ever 
 happen to
 D -- this role reversal notion is pure speculation, and exists 
 simply a
 means of clarifying the current situation.

I don't buy that. Or, rather, I don't think it's an attractive 
feature/change. Not sure what the answer is, as yet, but I am 100% 
with you that there's a problem that needs a solution.

 I hope this summarizes the thread content thus far. I haven't 
 touched on the
 subject brought up by Brad ("how to bridge the gap between user 
 defined
 types and built in types?"), which could use some exploration.

Also needs a full solution, IMO

 - Kris

 -------------------

 A few personal notes.

 This thread was started as an observation. A reflection on 
 interaction with
 D. With a tip of the hat to GW, I'll point out again that this is 
 not about
 making a case for change in D. And it is most certainly nothing to 
 do with
 blind ideological perspective, as one individual appears to have 
 showered
 upon it.

 I think this just highlights the difficulties surrounding clear
 communication in an NG environment. There's language barriers, 
 proximity-cue
 barriers, social and educational barriers, along with barriers of 
 purpose
 and intent. The fact that not each and every thread is filled with
 antagonism can be surprising to some, but many of them are. I find 
 it to be
 an increasingly painful and fruitless exercise to both read and 
 initiate
 threads here; even those relating my trivial experiences with D 
 (such as
 this one). Further, attempting to keep a thread on track is truly 
 becoming
 an impossible task (hence, the request for a summary).

 I can't imagine I'm the only one who feels this way ~ which 
 prompts a
 question: what, if anything, can be done about it?

Speaking for myself, I've certainly become far grumpier of late. It 
seems I take a break due to some pointless/bad experience, and 
foreswear any such future behaviour on my part or being sucked into 
fatuous debates by others, and yet within a couple of days of 
'coming back' it's happening again. Needless to say, I find this 
truly uncharacteristic - honest! <G> - behaviour of mine both 
appalling and intriguing. (I often think how embarrassed I'll be if 
my sons become software engineers and go and look up some of their 
cranky old fart of a father's semi-lucid ranting and pompous 
condescension.)

Why am I losing my temper? And why do I keep transgressing my 
otherwise golden rule of "Once the shouting starts, it's time to 
quit that job/friendship/debate/ ... /ng and remove the pain for all 
parties" ?

Knowing that I'm running the risk of being called flamer again, I 
submit that the two answers are the two sides of the same coin. I 
keep coming back because I believe D has *great* promise, and I am 
increasingly (and evidently!) frustrated by D because (i) nothing 
seems to change, and (ii) the "good enough" attitude is neither 
something I can relate to nor something that I think is going to 
fulfil the promise. To be frank, I think that, apart from slices, 
the _only_ thing about D that is currently great is its promise; the 
reality is quite dissatisfying.

So, yes, I'd like to see something change. Maybe it's moderation? 
Maybe it's a Phobos steering group? Maybe it's a language group? 
Maybe it's Walter participating in the threads criticising D, in 
which he seems perennially conspicuous by his absence? All of these 
are things that many different people have been asking for for 
literally years now.

Maybe the answer's in there, maybe not? I really don't know.

"Kris" <fu bar.com> writes:

Thanks for the considered repsonse, Matthew. More below:


"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote
 Secondly: the terms 'identity' and 'equality' are applied in D
 with
 significant overlap between the two, and it can be hard to get
 these terms
 straight when they are interchanged. For example, the D 'is'
 identity
 operator becomes an equality operator when used with primitive
 types.

 Ok, I didn't realise that. That's not good.

But it certainly is handy ;-)

Regardless, I think this one is small fry.


 Summary point 1: newcomers to D should likely use 'is' instead of
 '==',
 since those two are "equivalent" from a traditional standpoint
 (both perform
 a shallow test).

 Given what you say about 'is' being applicable to built-in types,
 that's arguable, I guess, but it seems like two wrongs not making a
 right to me.


Yep: I fully agree. But the compatability aspect is still up in the air
(more later)


 However, D does not currently lend itself to avoiding this sort of
 thing. In
 fact, D seems to embrace exactly this bug by making the default
 behaviour of
 '==' be of the shallow variety. A combination of changing
 tradition, yet not
 really, can actually increase maintenance costs.

 Strongly agreed. A very powerful point. Another good argument for
 the removal of opEquals() from Object.

 Note: I made some of these same points in "Identity and Equality:
 Syntax and Semantics" (CUJ, Oct 2003;
 http://www.cuj.com/articles/2003/0310/) and "Identity and Equality
 in .NET" (DDJ, June 2004; http://www.ddj.com/documents/ddj0406k/),
 though I discussed the dangerous behaviour you've outlined in terms


 If I may be so crass as to quote myself, it seems I said something
 that at least two of us would agree with:


<snip>
Hurrah! Yet you're still the the one and only person I know of on this NG
who cares about such things. Sad, isn't it, that most of the group isn't up
in arms over such things.


 Summary point 2: The default shallow test for '==' tends to
 exaggerate the
 potential for confusion. Not only because it does a role-defying
 shallow-
 rather than deep- comparison, but because it can lead directly to
 fragile
 maintenance builds via its changing behaviour.

 Totally lost me on that one. Is it covered below? If not, will you
 rephrase?


That itself is a rephrase of the "dangerous behaviour" we both discuss. Just
ignore it.


 While porting 125,000 lines of Java to D, and an interesting thing
 happened.
 You'll perhaps not be surprised to hear Java identity style tests
 are far
 more prevalent than equivalence tests,

 Well, yes, I am. Perhaps that's because I don't do much Java?

 but you may be surprised to know that
 the former comprised 98.75% of all explicit tests within those
 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.

 Very surprised indeed. Is it plausible that this is skewed by
 application specificity? What is that code base doing?


In this original section, I made the mistake of not using deep vs shallow.
This is because I wanted to isolate and compare the distinction between
'identity' and 'equality' operators in D and Java. That is, Java '==' is
identical to D 'is'. Java equals() is almost identical to D '==', with the
twist that D '==' is used with primitive types also.

So, for clarification, the percentage distinction is actually Java '==' vs
'equals()'. Using a direct conversion route, in D this would be 'is' vs '=='
... 'identity' vs 'equality' :-)

It is possible the results are skewed. But by that much? The code base is
doing what I'd expect typical business code to do. Not in the exact manner,
but in general terms. Lot's of branchy stuff, usage of containers, a few
specialized classes, varying degrees of inheritance, etc. Quite bland,
actually.


 2) Anyone used to C or Java will habitually use the traditional
 '==' and
 '!=' all over their D code. This is actually the *wrong* thing to
 do, since
 those operators in D are for equivalence testing instead of
 identity
 testing.

 Do you mean "since those operators in D are [sometimes, depending on
 the types of the comparands, used ]for equivalence testing instead
 of identity testing."?

Yes.


 This has implications for both performance and for "expectations
 of
 behaviour". For example, the subsequent addition of an opEquals()
 to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force
 of habit.

 Agree with the level of concern you're expressing with this.

 This all stems from the use of references without pointer syntax,

Thank you. I've been wrangling over a source for that one.


 Essentially you're saying that use of == for class types, or in
 generic code that may be applied to class types, is subject to
 hidden and potentially destructive change. This was the crux of my

 somewhat bemused/baffled why I didn't see that it also applies to D,
 and quite chagrined now to see that it does. Huge blunder.)

Yes.


 Given all that, this thread has noted D would become
 backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. That
 is, if
 '==' were to fully retain its shallow heritage (like 'is' does),
 newcomers
 would not have to even consider switching to using 'is' for the
 majority
 case. This would naturally eliminate the concern over both Summary
 Points 1
 & 2 above. Of course, there's zero expectation that would ever
 happen to
 D -- this role reversal notion is pure speculation, and exists
 simply a
 means of clarifying the current situation.

 I don't buy that. Or, rather, I don't think it's an attractive
 feature/change. Not sure what the answer is, as yet, but I am 100%
 with you that there's a problem that needs a solution.


I'm not surprised, as it was never intended to be a "solution". It's a shame
it got labeled as such.


 I hope this summarizes the thread content thus far. I haven't
 touched on the
 subject brought up by Brad ("how to bridge the gap between user
 defined
 types and built in types?"), which could use some exploration.

 Also needs a full solution, IMO

Aye.

-----------------


 Speaking for myself, I've certainly become far grumpier of late. It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be if
 my sons become software engineers and go and look up some of their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)

I'm totally with you, since I find the same thing happening.


 Knowing that I'm running the risk of being called flamer again, I
 submit that the two answers are the two sides of the same coin. I
 keep coming back because I believe D has *great* promise, and I am
 increasingly (and evidently!) frustrated by D because (i) nothing
 seems to change, and (ii) the "good enough" attitude is neither
 something I can relate to nor something that I think is going to
 fulfil the promise.

Exactly. It's truly frustrating, given the potential.

 So, yes, I'd like to see something change. Maybe it's moderation?
 Maybe it's a Phobos steering group? Maybe it's a language group?
 Maybe it's Walter participating in the threads criticising D, in
 which he seems perennially conspicuous by his absence? All of these
 are things that many different people have been asking for for
 literally years now.

 Maybe the answer's in there, maybe not? I really don't know.

Perhaps the NG (or D) is somehow better off without those who question the
status-quo?

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

 However, D does not currently lend itself to avoiding this sort 
 of
 thing. In
 fact, D seems to embrace exactly this bug by making the default
 behaviour of
 '==' be of the shallow variety. A combination of changing
 tradition, yet not
 really, can actually increase maintenance costs.

 Strongly agreed. A very powerful point. Another good argument for
 the removal of opEquals() from Object.

 Note: I made some of these same points in "Identity and Equality:
 Syntax and Semantics" (CUJ, Oct 2003;
 http://www.cuj.com/articles/2003/0310/) and "Identity and 
 Equality
 in .NET" (DDJ, June 2004; 
 http://www.ddj.com/documents/ddj0406k/),
 though I discussed the dangerous behaviour you've outlined in 
 terms


 If I may be so crass as to quote myself, it seems I said 
 something
 that at least two of us would agree with:


 <snip>
 Hurrah! Yet you're still the the one and only person I know of on 
 this NG
 who cares about such things. Sad, isn't it, that most of the group 
 isn't up
 in arms over such things.

But this is what I simply don't get. This 'industry' we're in is 
exactly what should attract people who genuinely care about the 
quality of their work. Lord knows, it's not for the chicks, or the 
money, or the doing-great-work-for-those-less-fortunate. Since it's 
somewhat related to maths, surely the "if it's not elegant, it's not 
correct/finished" ethos should pervade.

And yet, the older I get, or certainly since the "heady days of the 
internet", it seems like more and more people care less and less 
about the elegance. (Short-term) goal-based gratification is king, 
and, despite this probably having the highest average IQ of just 
about any profession, few seem to grok the power of the underlying 
truths, such as orthogonality, simplicity, elegance, etc. It's kind 
of the like the modern world's approach to health and wellbeing: 
your lifestyle is 'good enough' and we'll operate when you get ill, 
rather than caring about environment, social structure, mental 
health, hours worked vs hours played, etc. etc. Baffling.

Sometimes I think I was foolish not to take up my cousin's offer to 
go and work in The City (== London's financial community) when I got 
my PhD. He said he'd make me a millionnaire in less than 10 years. 
That was 10 years ago. ;/


 It is possible the results are skewed. But by that much? The code 
 base is
 doing what I'd expect typical business code to do. Not in the 
 exact manner,
 but in general terms. Lot's of branchy stuff, usage of containers, 
 a few
 specialized classes, varying degrees of inheritance, etc. Quite 
 bland,
 actually.

k. I am willing to take your word for it. Not doubting, just 
surprised. :-)


 This has implications for both performance and for 
 "expectations
 of
 behaviour". For example, the subsequent addition of an 
 opEquals()
 to some
 aggregate may break the overall system in all manner of subtle 
 and
 unexpected ways, where the original developer used '==' by 
 force
 of habit.

 Agree with the level of concern you're expressing with this.

 This all stems from the use of references without pointer syntax,

 Thank you. I've been wrangling over a source for that one.

"twas an honour.


 Given all that, this thread has noted D would become
 backward-compatible if
 the functionality of '==' and 'is' were to be role-reversed. 
 That
 is, if
 '==' were to fully retain its shallow heritage (like 'is' 
 does),
 newcomers
 would not have to even consider switching to using 'is' for the
 majority
 case. This would naturally eliminate the concern over both 
 Summary
 Points 1
 & 2 above. Of course, there's zero expectation that would ever
 happen to
 D -- this role reversal notion is pure speculation, and exists
 simply a
 means of clarifying the current situation.

 I don't buy that. Or, rather, I don't think it's an attractive
 feature/change. Not sure what the answer is, as yet, but I am 
 100%
 with you that there's a problem that needs a solution.


 I'm not surprised, as it was never intended to be a "solution". 
 It's a shame
 it got labeled as such.

nw.


 Speaking for myself, I've certainly become far grumpier of late. 
 It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked 
 into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be 
 if
 my sons become software engineers and go and look up some of 
 their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)

 I'm totally with you, since I find the same thing happening.

Something's gotta change. I hope it'll be something organisationally 
with D, but I suspect it'll be my conscience making me leave in 
response to increasing number of reasonable complaints about my 
curmudgeon. :-(


 Knowing that I'm running the risk of being called flamer again, I
 submit that the two answers are the two sides of the same coin. I
 keep coming back because I believe D has *great* promise, and I 
 am
 increasingly (and evidently!) frustrated by D because (i) nothing
 seems to change, and (ii) the "good enough" attitude is neither
 something I can relate to nor something that I think is going to
 fulfil the promise.

 Exactly. It's truly frustrating, given the potential.

This is what totally baffles me.

Walter had a go at me some time back for being abstraction-obsessed. 
Ironically, he used as an example what IMO is the starkest example 
of the stupidity of the "gooD enough" attitude: the opApply() return 
value.

He thinks I'm asking for something pointless, because no-one's yet 
fallen afoul of it.
I want something that is meaningless (i.e. 
any-other-explicit-value-than-0) and _potentially_ dangerous and, 
importantly, incredibly simple to fix, to be fixed.

My feeling is that such conflicts are just unresolveable, which 
doesn't attenuate the frustrations any.

 So, yes, I'd like to see something change. Maybe it's moderation?
 Maybe it's a Phobos steering group? Maybe it's a language group?
 Maybe it's Walter participating in the threads criticising D, in
 which he seems perennially conspicuous by his absence? All of 
 these
 are things that many different people have been asking for for
 literally years now.

 Maybe the answer's in there, maybe not? I really don't know.

 Perhaps the NG (or D) is somehow better off without those who 
 question the
 status-quo?

Am answering this with a new post.

Brad Anderson <brad dsource.dot.org> writes:

Speaking for myself, I've certainly become far grumpier of late. 
It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked 
into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be 
if
my sons become software engineers and go and look up some of 
their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

 
 
 Something's gotta change. I hope it'll be something organisationally 
 with D, but I suspect it'll be my conscience making me leave in 
 response to increasing number of reasonable complaints about my 
 curmudgeon. :-(

This would truly be a shame.  The way a technology advances, IMO, is the 
conflict resolution between knowledgeable, passionate, and boisterous 
people who are fully engaged in the birthing of the technology.  If the 
conflict is fully vetted, and reasonable compromises can be made, in 
addition to minds being kept open to future change, then advancement is 
realized.

I hate to name names, and forgive me if I've omitted you, but for D and 
this NG to lose the voices of Matthew, Kris, Sean and others would be a 
HUGE loss.  They've already been quiet recently as it is.  This is a 
direct result of Walter not finding compromise or recognizing the value 
of other expert opinions that may differ from his own.  Not sure who 
said this, but maybe ESR? and it's paraphrased...  "Thrill your users. 
At first, it will be the early adopters.  Make the experts / power users 
happy..."

This would be a bit more powerful from someone writing a lot of D code 
on a consistent basis, but I've lurked for 2+ years, and have seen smart 
people jump up and volunteer some great ideas.  I don't care if they get 
shot down ... to a point.  Some of them are now gone because of the 
problem noted above.

Over and over again, it's been proposed that some organization be formed 
to augment Walter's efforts, whether library or lang standard.  Let me 
say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to 
happen, then get David Friedman on board, or do it yourselves, but fork 
the damn language and fix the warts you guys want to fix!  If you come 
up with something better, then maybe Walter will want to merge back with 
you.  When he holds the keys to the kingdom, however, the advancement 
made will not be sufficient in your minds.

One effort that holds my respect is Ares, because it's the only thing 
those guys can do to compensate for their perceived shortcomings of 
Phobos.  Even if they've stopped (slowed) participating in the NG, they 
are still coding that lib.  Compiler warts and all.  It's all that they 
can control.

<somewhat-random-tangent>
If none of this works, and you truly want to leave D, then come join me 
in the world of Common Lisp.  Talk about a powerful language devoid of 
lots of the warts you speak of.  (btw, don't tell me it's interpreted, 
slow, full of parentheses, and its developers talk funny.  All of that's 
bull, except for the parens, and they're manageable.)  All of the Design 
Patterns you OO guys work with daily are basically to make up for 
Java/C/C++/D's lack of late binding, and there's nothing like the macros 
or closures in Lisp.
</somewhat-random-tangent>

I have learned a ton from this NG, watching the more experienced 
developers debate, and firmly believe that D would be worse off without 
the powerful voices that chime in regularly.  But I empathize with them 
in their frustration to affect change recently (i.e. before 1.0).

WTF, Walter?  Don't answer my post.  Answer theirs...

And if he doesn't answer, boys, go ahead and fork it.  There has to be 
some way to affect change and realize the great promise that keeps you 
coming back to the current quagmire.

BA

kris <fu bar.org> writes:

Now this ... is the best post I've read here in a rather long time.


Brad Anderson wrote:
 Speaking for myself, I've certainly become far grumpier of late. It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be if
 my sons become software engineers and go and look up some of their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)


 I'm totally with you, since I find the same thing happening.



 Something's gotta change. I hope it'll be something organisationally 
 with D, but I suspect it'll be my conscience making me leave in 
 response to increasing number of reasonable complaints about my 
 curmudgeon. :-(

 
 
 This would truly be a shame.  The way a technology advances, IMO, is the 
 conflict resolution between knowledgeable, passionate, and boisterous 
 people who are fully engaged in the birthing of the technology.  If the 
 conflict is fully vetted, and reasonable compromises can be made, in 
 addition to minds being kept open to future change, then advancement is 
 realized.
 
 I hate to name names, and forgive me if I've omitted you, but for D and 
 this NG to lose the voices of Matthew, Kris, Sean and others would be a 
 HUGE loss.  They've already been quiet recently as it is.  This is a 
 direct result of Walter not finding compromise or recognizing the value 
 of other expert opinions that may differ from his own.  Not sure who 
 said this, but maybe ESR? and it's paraphrased...  "Thrill your users. 
 At first, it will be the early adopters.  Make the experts / power users 
 happy..."
 
 This would be a bit more powerful from someone writing a lot of D code 
 on a consistent basis, but I've lurked for 2+ years, and have seen smart 
 people jump up and volunteer some great ideas.  I don't care if they get 
 shot down ... to a point.  Some of them are now gone because of the 
 problem noted above.
 
 Over and over again, it's been proposed that some organization be formed 
 to augment Walter's efforts, whether library or lang standard.  Let me 
 say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to 
 happen, then get David Friedman on board, or do it yourselves, but fork 
 the damn language and fix the warts you guys want to fix!  If you come 
 up with something better, then maybe Walter will want to merge back with 
 you.  When he holds the keys to the kingdom, however, the advancement 
 made will not be sufficient in your minds.
 
 One effort that holds my respect is Ares, because it's the only thing 
 those guys can do to compensate for their perceived shortcomings of 
 Phobos.  Even if they've stopped (slowed) participating in the NG, they 
 are still coding that lib.  Compiler warts and all.  It's all that they 
 can control.
 
 <somewhat-random-tangent>
 If none of this works, and you truly want to leave D, then come join me 
 in the world of Common Lisp.  Talk about a powerful language devoid of 
 lots of the warts you speak of.  (btw, don't tell me it's interpreted, 
 slow, full of parentheses, and its developers talk funny.  All of that's 
 bull, except for the parens, and they're manageable.)  All of the Design 
 Patterns you OO guys work with daily are basically to make up for 
 Java/C/C++/D's lack of late binding, and there's nothing like the macros 
 or closures in Lisp.
 </somewhat-random-tangent>
 
 I have learned a ton from this NG, watching the more experienced 
 developers debate, and firmly believe that D would be worse off without 
 the powerful voices that chime in regularly.  But I empathize with them 
 in their frustration to affect change recently (i.e. before 1.0).
 
 WTF, Walter?  Don't answer my post.  Answer theirs...
 
 And if he doesn't answer, boys, go ahead and fork it.  There has to be 
 some way to affect change and realize the great promise that keeps you 
 coming back to the current quagmire.
 
 BA

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

In defense of Walter, he's in a tough position here. We're all wanting his
time, but what are we able to offer him for it other than some of our own time
in return?  We all want him to see things in a certain light, accomplish
certain goals, solve certain problems, and so on.

My first contact with him was basically a complaint... and rather than word it
as an observation, I worded it as just what it was... a complaint.  Well,
realistically, I had no right to complain.  The problem was that the
installation and setup of the D compiler on my system to a useable condition
turned out not to work the way the documentation said it would, and I spent a
lot of time working around one problem after another.  Well... I paid nothing
for it, and from what I can see (although I didn't know this at the time) it is
technically pre-release software... still in development.  With that in mind,
I'm now simply happy that I got it running at all.  Beyond that, I can honestly
say that even in it's current beta-like state, I like it enough that I have
decided on a project to write and have chosen D as the language to write it in.

Now, looking back on it, I "should have" been more considerate of his feelings
when I wrote that first letter.  Of course, since I didn't know him at all and
I was extremely frustrated at the time, I handled the situation poorly.

By the way, Walter, if you're reading this... please accept my sincere and
humble apology.

Okay, so there are things that need worked out.  We'll get through them. 
Overall, I would say we're a good group of people, and capable on the whole of
being supportive of each other, of the D language that we all share an interest
in, and of anyone who stands behind us or our shared interest.  Sometimes, it
may not look that way, and Walter is probably seeing the worst of it more than
any of us... so I suggest we cut him some slack, and try to be encouraging
without setting our cumulative expectations of him higher than we can expect of
ourselves.

From what I can see... in this arena, he's got more lions to fight off than the
rest of us... so if we're going to be in the audience from time to time, it
should be cheering him on... and when the opportunity arises, perhaps we can
pull a lion or two off his back and help give him a fighting chance at victory.
 :)

TZ

"kris" <fu bar.org> wrote in message news:d3l4mb$8eh$1 digitaldaemon.com...
 Now this ... is the best post I've read here in a rather long time.


 Brad Anderson wrote:
 Speaking for myself, I've certainly become far grumpier of late. It
 seems I take a break due to some pointless/bad experience, and
 foreswear any such future behaviour on my part or being sucked into
 fatuous debates by others, and yet within a couple of days of
 'coming back' it's happening again. Needless to say, I find this
 truly uncharacteristic - honest! <G> - behaviour of mine both
 appalling and intriguing. (I often think how embarrassed I'll be if
 my sons become software engineers and go and look up some of their
 cranky old fart of a father's semi-lucid ranting and pompous
 condescension.)


 I'm totally with you, since I find the same thing happening.



 Something's gotta change. I hope it'll be something organisationally
 with D, but I suspect it'll be my conscience making me leave in
 response to increasing number of reasonable complaints about my
 curmudgeon. :-(


 This would truly be a shame.  The way a technology advances, IMO, is the
 conflict resolution between knowledgeable, passionate, and boisterous
 people who are fully engaged in the birthing of the technology.  If the
 conflict is fully vetted, and reasonable compromises can be made, in
 addition to minds being kept open to future change, then advancement is
 realized.

 I hate to name names, and forgive me if I've omitted you, but for D and
 this NG to lose the voices of Matthew, Kris, Sean and others would be a
 HUGE loss.  They've already been quiet recently as it is.  This is a
 direct result of Walter not finding compromise or recognizing the value
 of other expert opinions that may differ from his own.  Not sure who
 said this, but maybe ESR? and it's paraphrased...  "Thrill your users.
 At first, it will be the early adopters.  Make the experts / power users
 happy..."

 This would be a bit more powerful from someone writing a lot of D code
 on a consistent basis, but I've lurked for 2+ years, and have seen smart
 people jump up and volunteer some great ideas.  I don't care if they get
 shot down ... to a point.  Some of them are now gone because of the
 problem noted above.

 Over and over again, it's been proposed that some organization be formed
 to augment Walter's efforts, whether library or lang standard.  Let me
 say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to
 happen, then get David Friedman on board, or do it yourselves, but fork
 the damn language and fix the warts you guys want to fix!  If you come
 up with something better, then maybe Walter will want to merge back with
 you.  When he holds the keys to the kingdom, however, the advancement
 made will not be sufficient in your minds.

 One effort that holds my respect is Ares, because it's the only thing
 those guys can do to compensate for their perceived shortcomings of
 Phobos.  Even if they've stopped (slowed) participating in the NG, they
 are still coding that lib.  Compiler warts and all.  It's all that they
 can control.

 <somewhat-random-tangent>
 If none of this works, and you truly want to leave D, then come join me
 in the world of Common Lisp.  Talk about a powerful language devoid of
 lots of the warts you speak of.  (btw, don't tell me it's interpreted,
 slow, full of parentheses, and its developers talk funny.  All of that's
 bull, except for the parens, and they're manageable.)  All of the Design
 Patterns you OO guys work with daily are basically to make up for
 Java/C/C++/D's lack of late binding, and there's nothing like the macros
 or closures in Lisp.
 </somewhat-random-tangent>

 I have learned a ton from this NG, watching the more experienced
 developers debate, and firmly believe that D would be worse off without
 the powerful voices that chime in regularly.  But I empathize with them
 in their frustration to affect change recently (i.e. before 1.0).

 WTF, Walter?  Don't answer my post.  Answer theirs...

 And if he doesn't answer, boys, go ahead and fork it.  There has to be
 some way to affect change and realize the great promise that keeps you
 coming back to the current quagmire.

 BA

James Dunne <jdunne4 bradley.edu> writes:

I agree.  I just find it amazing that he has time to troll the forums and
respond to user feedback as well as keeping a relatively consistent release
schedule going.  I'm very appreciative of all his hard work over the years and D
is primarily my language of choice now.

I really don't have any significant gripes with any technical issues, except
where strange bugs pop up once in a while, but technically this is "beta"
software, like you said, and you get what you pay for. :-P.  Frankly I think
we're getting amazing feedback and support for what we pay.

I don't know about all you guys, but I've never had anywhere near this close of
contact with a language developer working on a new language.  I find it exciting
to see new features and bug fixes come out regularly.  I trust Walter's
decisions on the language for the most part, and think he's taking it in the
right directions it needs to go in to succeed.

I'm sure others agree with me here, but all you hear about on the forums is the
select few individuals who have strong opinions on the issues debating back and
forth.  I think things may be better if we actually told Walter what we *like*
about the language in addition to what should be fixed/changed.

Here's my list of things I like about D:
- builtin associative arrays
- breaking down the barrier between -> and . field access operators.  honestly,
who cares if the damn thing's a pointer to a structure??
- no funky syntax for referring to objects like * and &.
of course, i still use pointers where appropriate in order to communicate with C
and do some other cool low-level things, but i really hate the & syntax of C++.
Just recently I was asked to help out with a C++ project, and I completely
forgot how to use the language since I've been using D so much!
- operator overload syntax is certainly wonderful!
- declaring all your methods and variables in one single class definition,
rather than the tiresome .h/.cpp duplication of effort and creator of bugs
- imports and modules are a Godsend to maintainability and code reuse (except
when you change the package name of a module to move to a different project -
the endless barrage of import- and module-line changes is enough to drive one
insane)
- properties!!! default arrays, basic types.
however for classes, a get/set syntax really should be used here to define

- array copy / slicing syntax is absolutely beautiful and I cannot live without
it now.  memcpy just looks so ugly to me now!
- array concatenation
- mixins and templates (except limits of template inheritance in classes as well
as using templates as types)
- free source code to phobos library for complete modification
+ my no-gc patch!
+ most advanced language features boil down to C function calls - now THAT is
true power!!
- the D calling convention is just brilliant and feels like a necessary
evolution of calling conventions.  in, out, inout are truly genious as well as
the variadic parameter approach
? Garbage collection ... I could take it or leave it.  It feels like a crutch to
me.
- readability.  The readability of this language is just through the roof (in
the good sense)!  I love reading through D code, it looks to me like what C has
meant to read like for a long time, but couldn't quite get there.  It is much
cleaner than C++, for sure.

Regards,
James Dunne

Brad Anderson <brad dsource.dot.org> writes:

James Dunne wrote:
 I agree.  I just find it amazing that he has time to troll the forums and
 respond to user feedback as well as keeping a relatively consistent release
 schedule going.  I'm very appreciative of all his hard work over the years and
D
 is primarily my language of choice now.
 
 I really don't have any significant gripes with any technical issues, except
 where strange bugs pop up once in a while, but technically this is "beta"
 software, like you said, and you get what you pay for. :-P.  Frankly I think
 we're getting amazing feedback and support for what we pay.
 
 I don't know about all you guys, but I've never had anywhere near this close of
 contact with a language developer working on a new language.  I find it
exciting
 to see new features and bug fixes come out regularly.  I trust Walter's
 decisions on the language for the most part, and think he's taking it in the
 right directions it needs to go in to succeed.

I don't think my post should be taken as a slight against Walter and his 
efforts poured into D.  I am as appreciative as you, TZ, bobef, and 
scores of others.  My issue is with the process of affecting change 
recently.

You may not have any significant gripes, and I only have a few.  But 
seasoned developers with more experience than most of us put together 
seem to be fixated on a few warts of the language.  I have to believe 
that if I ever get as deep into development as they have, I will see the 
warts, too.  These guys know more about language use and how moderately 
skilled developers get trapped than This is why I'm criticizing the 
methods or processes Walter is (not) implementing as the language grows. 
  We simply don't hear from him after he disagrees with a thread.

 
 I'm sure others agree with me here, but all you hear about on the forums is the
 select few individuals who have strong opinions on the issues debating back and
 forth.  I think things may be better if we actually told Walter what we *like*
 about the language in addition to what should be fixed/changed.

As for your list of things we like about D, it's a good exercise.  But I 
imagine it's equally long for all of us.  Remember, even the curmudgeons 
keep coming back for the great promise...

BA

 
 Here's my list of things I like about D:
 - builtin associative arrays
 - breaking down the barrier between -> and . field access operators.  honestly,
 who cares if the damn thing's a pointer to a structure??
 - no funky syntax for referring to objects like * and &.
 of course, i still use pointers where appropriate in order to communicate with
C
 and do some other cool low-level things, but i really hate the & syntax of C++.
 Just recently I was asked to help out with a C++ project, and I completely
 forgot how to use the language since I've been using D so much!
 - operator overload syntax is certainly wonderful!
 - declaring all your methods and variables in one single class definition,
 rather than the tiresome .h/.cpp duplication of effort and creator of bugs
 - imports and modules are a Godsend to maintainability and code reuse (except
 when you change the package name of a module to move to a different project -
 the endless barrage of import- and module-line changes is enough to drive one
 insane)
 - properties!!! default arrays, basic types.
 however for classes, a get/set syntax really should be used here to define

 - array copy / slicing syntax is absolutely beautiful and I cannot live without
 it now.  memcpy just looks so ugly to me now!
 - array concatenation
 - mixins and templates (except limits of template inheritance in classes as
well
 as using templates as types)
 - free source code to phobos library for complete modification
 + my no-gc patch!
 + most advanced language features boil down to C function calls - now THAT is
 true power!!
 - the D calling convention is just brilliant and feels like a necessary
 evolution of calling conventions.  in, out, inout are truly genious as well as
 the variadic parameter approach
 ? Garbage collection ... I could take it or leave it.  It feels like a crutch
to
 me.
 - readability.  The readability of this language is just through the roof (in
 the good sense)!  I love reading through D code, it looks to me like what C has
 meant to read like for a long time, but couldn't quite get there.  It is much
 cleaner than C++, for sure.
 
 Regards,
 James Dunne

"Carlos Santander B." <csantander619 gmail.com> writes:

James Dunne wrote:
 I agree.  I just find it amazing that he has time to troll the forums
 and respond to user feedback as well as keeping a relatively
 consistent release schedule going.  I'm very appreciative of all his
 hard work over the years and D is primarily my language of choice
 now.
 
 I really don't have any significant gripes with any technical issues,
 except where strange bugs pop up once in a while, but technically
 this is "beta" software, like you said, and you get what you pay for.
 :-P.  Frankly I think we're getting amazing feedback and support for
 what we pay.
 
 I don't know about all you guys, but I've never had anywhere near
 this close of contact with a language developer working on a new
 language.  I find it exciting to see new features and bug fixes come
 out regularly.  I trust Walter's decisions on the language for the
 most part, and think he's taking it in the right directions it needs
 to go in to succeed.
 
 I'm sure others agree with me here, but all you hear about on the
 forums is the select few individuals who have strong opinions on the
 issues debating back and forth.  I think things may be better if we
 actually told Walter what we *like* about the language in addition to
 what should be fixed/changed.
 
 Here's my list of things I like about D: - builtin associative arrays
  - breaking down the barrier between -> and . field access operators.
 honestly, who cares if the damn thing's a pointer to a structure?? -
 no funky syntax for referring to objects like * and &. of course, i
 still use pointers where appropriate in order to communicate with C 
 and do some other cool low-level things, but i really hate the &
 syntax of C++. Just recently I was asked to help out with a C++
 project, and I completely forgot how to use the language since I've
 been using D so much! - operator overload syntax is certainly
 wonderful! - declaring all your methods and variables in one single
 class definition, rather than the tiresome .h/.cpp duplication of
 effort and creator of bugs - imports and modules are a Godsend to
 maintainability and code reuse (except when you change the package
 name of a module to move to a different project - the endless barrage
 of import- and module-line changes is enough to drive one insane) -
 properties!!! default arrays, basic types. however for classes, a
 get/set syntax really should be used here to define properties, much

 beautiful and I cannot live without it now.  memcpy just looks so
 ugly to me now! - array concatenation - mixins and templates (except
 limits of template inheritance in classes as well as using templates
 as types) - free source code to phobos library for complete
 modification + my no-gc patch! + most advanced language features boil
 down to C function calls - now THAT is true power!! - the D calling
 convention is just brilliant and feels like a necessary evolution of
 calling conventions.  in, out, inout are truly genious as well as the
 variadic parameter approach ? Garbage collection ... I could take it
 or leave it.  It feels like a crutch to me. - readability.  The
 readability of this language is just through the roof (in the good
 sense)!  I love reading through D code, it looks to me like what C
 has meant to read like for a long time, but couldn't quite get there.
 It is much cleaner than C++, for sure.
 
 Regards, James Dunne

I very much feel like James here, but there's something else:

Brad Anderson wrote:
 You may not have any significant gripes, and I only have a few.  But
 seasoned developers with more experience than most of us put together
 seem to be fixated on a few warts of the language.  I have to believe
 that if I ever get as deep into development as they have, I will see
 the warts, too.  These guys know more about language use and how
 moderately skilled developers get trapped than This is why I'm
 criticizing the methods or processes Walter is (not) implementing as
 the language grows.  We simply don't hear from him after he disagrees
 with a thread.

I also agree with Brad with this.

-- 
Carlos Santander Bernal

JP2, you'll always live in our minds

bobef <bobef_member pathlink.com> writes:

In article <d3l33k$6fr$1 digitaldaemon.com>, Brad Anderson says...
Speaking for myself, I've certainly become far grumpier of late. 
It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked 
into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be 
if
my sons become software engineers and go and look up some of 
their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.

 
 
 Something's gotta change. I hope it'll be something organisationally 
 with D, but I suspect it'll be my conscience making me leave in 
 response to increasing number of reasonable complaints about my 
 curmudgeon. :-(

This would truly be a shame.  The way a technology advances, IMO, is the 
conflict resolution between knowledgeable, passionate, and boisterous 
people who are fully engaged in the birthing of the technology.  If the 
conflict is fully vetted, and reasonable compromises can be made, in 
addition to minds being kept open to future change, then advancement is 
realized.

I hate to name names, and forgive me if I've omitted you, but for D and 
this NG to lose the voices of Matthew, Kris, Sean and others would be a 
HUGE loss.  They've already been quiet recently as it is.  This is a 
direct result of Walter not finding compromise or recognizing the value 
of other expert opinions that may differ from his own.  Not sure who 
said this, but maybe ESR? and it's paraphrased...  "Thrill your users. 
At first, it will be the early adopters.  Make the experts / power users 
happy..."

This would be a bit more powerful from someone writing a lot of D code 
on a consistent basis, but I've lurked for 2+ years, and have seen smart 
people jump up and volunteer some great ideas.  I don't care if they get 
shot down ... to a point.  Some of them are now gone because of the 
problem noted above.

Over and over again, it's been proposed that some organization be formed 
to augment Walter's efforts, whether library or lang standard.  Let me 
say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to 
happen, then get David Friedman on board, or do it yourselves, but fork 
the damn language and fix the warts you guys want to fix!  If you come 
up with something better, then maybe Walter will want to merge back with 
you.  When he holds the keys to the kingdom, however, the advancement 
made will not be sufficient in your minds.

One effort that holds my respect is Ares, because it's the only thing 
those guys can do to compensate for their perceived shortcomings of 
Phobos.  Even if they've stopped (slowed) participating in the NG, they 
are still coding that lib.  Compiler warts and all.  It's all that they 
can control.

<somewhat-random-tangent>
If none of this works, and you truly want to leave D, then come join me 
in the world of Common Lisp.  Talk about a powerful language devoid of 
lots of the warts you speak of.  (btw, don't tell me it's interpreted, 
slow, full of parentheses, and its developers talk funny.  All of that's 
bull, except for the parens, and they're manageable.)  All of the Design 
Patterns you OO guys work with daily are basically to make up for 
Java/C/C++/D's lack of late binding, and there's nothing like the macros 
or closures in Lisp.
</somewhat-random-tangent>

I have learned a ton from this NG, watching the more experienced 
developers debate, and firmly believe that D would be worse off without 
the powerful voices that chime in regularly.  But I empathize with them 
in their frustration to affect change recently (i.e. before 1.0).

WTF, Walter?  Don't answer my post.  Answer theirs...

And if he doesn't answer, boys, go ahead and fork it.  There has to be 
some way to affect change and realize the great promise that keeps you 
coming back to the current quagmire.

BA




I am sorry for the rude language but some things have to be said as they are.

First I want to ask what does the subject means? The F Word? What is that? Fuck
Walter? Fuck D? Fuck this community? Fuck the world? Which of them? Or it is a
joke because only fuck is called the f word but it could be any F-word? And if
it is fuck then say it rebel boy! Loudly and proudly. If this is your position
stand for it. This is not a kids forum after all.

Now my opinion:

I totaly stand behind Walter. What he does is great and I deeply respect it and
him too. I'm not here from 2 years, but it is almost a year since I found D, so
I believe I could say that. What Walter did (the D language) is something great.
No need to say why, hope everyone here knows why. And it is true that Walter is
not listening about some things. I want this or that. I don't like Walter has
different opinion from mine, but this is his product. It will be what he decides
and I respect that. And I believe he is a wise man and he will not decide
something stupid. And even if I believe something is stupid it is not up to me.
If I disagree so much I will take D as a base and make E language as Walter did
with C++. If you want something --- it is open source god damn it. Go there and
fix it.

And I am glad Walter keeps to his opinion only. Otherwise D will end up like
linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
touches here, someone touches there and it becomes useless. If you want it to be
useless you have to start over and modify all the software...
It can't be good for everyone. People are different and thats cool about it.

Walter is sparing so much time doing D and I think it's DAMN good! It is not
flawless of course. It has flaw in design and it has flaws in implementation but
what the fuck??!? IT IS STILL THE BEST LANGUAGE TO THIS DATE!

That does not mean I'm resigned to it. I hope after some time Walter will
reconsider parts of D so it will become flawless. But lets get down to earth. I
know everyone wants D 1.0. But we are light years away. And still we can't just
say D is not 1.0 because Walter doesn't want to do what we say. And if D is so
good in version 0.120 in 1.0 it WILL BE flawless!

David Medlock <amedlock nospam.org> writes:

bobef wrote:

 I am sorry for the rude language but some things have to be said as they are.
 
 First I want to ask what does the subject means? The F Word? 

I think they were referring to 'Fork'...

-David

pragma <pragma_member pathlink.com> writes:

In article <d3lrk9$umr$1 digitaldaemon.com>, David Medlock says...
bobef wrote:

 I am sorry for the rude language but some things have to be said as they are.
 
 First I want to ask what does the subject means? The F Word? 

I think they were referring to 'Fork'...

Thank you for clarifying things.  Its an important topic, so allow me to shed
some light on the notion for the unintiated:

By "F-Word", the OP means "Fork".  Saying "F-word" here is clever word-play
since many view forking as, well, dirty and undesirable.

http://en.wikipedia.org/wiki/Fork_(software)

"In software, a project fork or branch happens when a developer (or a group of
them) takes code from a project and starts to develop independently of the rest.
The term is also used more loosely to represent a similar branching of any work
(for example, there are several forks of the English language Wikipedia)."

"The term is particularly used in free or open source software, when a schism
occurs because of different goals or personality clashes. Some see forks as a
weakness in open source, but they can demonstrate the adaptability of the model.
The relationship between the different teams can be cordial or very bitter (see
xMule and its fork aMule)."


The following is largely IMO.  Please read, thank you.


Forking isn't always a bad thing.  Unfortunately, I cannot speak from experience
here.  The worst that forking can do is divide the resources of a given
community so that no branch of the project tree succeeds.  It also can be viewed
externally as a weakness in the strength of the current offerings behind the
overall project... but your mileage may vary.  It can also be extremely damaging
to developer egos, and can deepend community schisms by becomming a dividing
line.

So you only really want to fork unless there's absolutely nowhere else to go,
since it's so risky.

If one looks at the D language as an open specification, with Digital Mars as
merely a compiler vendor, then forking makes some sense.  other compilers could
easily push the envelope of the spec and reccomend updates to Walter so DMD
continues to be a part of the pack.  

As to whom controls the actual D spec, that's the rub.  A true fork would
indicate that there would be competing D specifications out there, which could
be a very bad thing; it could re-invent the problem with C and C++ which is what
D was supposed to fix.

And besides, nobody is impressed by the "our wheel is rounder" approach. <j/k>


An interim solution:

Instead of outright saying "D is ours, and we'll go make it our way", perhaps a
compromise should be struck instead?  

First of all, GDC is a very capable rendition of D and is dire need of
additional support.  It is presently 7 (going on 8) releases behind DMD.  If
you're looking to get D to make an impact, then get hacking!  

Second, I strongly reccomend that everyone get a copy of either GDC or Ben
Hinkle's DMDFE distribution.  The current front end is intimidating, but
enabling some of the debug printf statements can yield a lot of insight as to
how source is modeled and used to drive the actual compiler***.  A determined
hacker can easily start adding their own customizations to the language within a
mere week, possibly less.

Third, after you are familiar with the front-end, start test-bedding new
language concepts.  Build working groups, and encourage the community to try the
new features on for size.  Nothing says "this works better" than being able to
point at code that compiles on *something*.  Its far and away better than all
the theory and "this works in forth/lisp/perl" discussions we've seen so far.
Plus, the process will inevidably weed out concepts that are simply too hard to
implement.

I would like to think that publishing compiler patches, to GDC and possibly DMD,
would *accelerate* the overall state of the language in a way that Forking
couldn't possibly achieve.  At worst, the testbed compiler patches will get
folded into GDC first, which will (later on) fork quite naturally on its own
under the weight of these enhancements.

This is the model currently adopted for Ares, and is working quite well.

Another exmaple: what if Georg and friends formed a Vectorization working group
for D?  They could acutally implement vectorization for D and pound out all the
kinks.  Then they can just supply the community with a reference implementation,
documentation, and possibly furnish Walter with a diff/patch so DMD could fully
implement the feature.  No forking, just collaborating with the community as a
whole (Walter included) to get the *implemented enhancements* included in GDC
and/or DMD.

It seems like a lot, and is certainly more effort than begging for language
enhancements from Walter.  But it is *orders of magnitude* less complicated and
less cumbersome than starting up an over-arching new project to steer the entire
state of the language, *and* compete with DMD.  People will all want to go their
own way at some point anyhow, so why not encourage and leverage that behavior
instead?


The bottom line here is: why offically fork, when you can form nimble task
groups that can build proof-of-concepts for consumption by Walter et al, all by
hacking the front-end source.  The tools are there, the talent is there, and the
ambition is there.  In other words, get it done today instead of after
everything goes through a (forked) committee that may very well frustrate people
as much as Walter has.

(*** A doxygen replacement, and a myriad of other tools, could also consume data
generated by the front-end)

- EricAnderton at yahoo

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

pragma wrote:

 If one looks at the D language as an open specification, with Digital Mars as
 merely a compiler vendor, then forking makes some sense.  other compilers could
 easily push the envelope of the spec and reccomend updates to Walter so DMD
 continues to be a part of the pack.  
 
 As to whom controls the actual D spec, that's the rub.  A true fork would
 indicate that there would be competing D specifications out there, which could
 be a very bad thing; it could re-invent the problem with C and C++ which is
what
 D was supposed to fix.
 
 And besides, nobody is impressed by the "our wheel is rounder" approach. <j/k>

The D specification is copyrighted by Digital Mars, so it's not "open".
Then again, it seems silly to fork a language that's so small to begin 


Here's hoping that it stays one "project", and that most of the changes 
needed for GDC are implemented in the upstream DMD front-end itself...
(for instance, it seems silly to have two different versions of Phobos?)

 First of all, GDC is a very capable rendition of D and is dire need of
 additional support.  It is presently 7 (going on 8) releases behind DMD.  If
 you're looking to get D to make an impact, then get hacking!  

There's a lot of *impressive* changes in GDC 0.11 already.
And for next version, David is even synching with DMD 0.120...

Seems like both Walter and David are making good progress,
while the intense discussions rages back and forth here ? :-)

--anders

Brad Anderson <brad dsource.dot.org> writes:

pragma wrote:
 In article <d3lrk9$umr$1 digitaldaemon.com>, David Medlock says...
 
bobef wrote:


I am sorry for the rude language but some things have to be said as they are.

First I want to ask what does the subject means? The F Word? 

I think they were referring to 'Fork'...

 
 
 Thank you for clarifying things.  Its an important topic, so allow me to shed
 some light on the notion for the unintiated:
 
 By "F-Word", the OP means "Fork".  Saying "F-word" here is clever word-play
 since many view forking as, well, dirty and undesirable.
 
 http://en.wikipedia.org/wiki/Fork_(software)
 
 "In software, a project fork or branch happens when a developer (or a group of
 them) takes code from a project and starts to develop independently of the
rest.
 The term is also used more loosely to represent a similar branching of any work
 (for example, there are several forks of the English language Wikipedia)."
 
 "The term is particularly used in free or open source software, when a schism
 occurs because of different goals or personality clashes. Some see forks as a
 weakness in open source, but they can demonstrate the adaptability of the
model.
 The relationship between the different teams can be cordial or very bitter (see
 xMule and its fork aMule)."
 
 
 The following is largely IMO.  Please read, thank you.
 
 
 Forking isn't always a bad thing.  Unfortunately, I cannot speak from
experience
 here.  The worst that forking can do is divide the resources of a given
 community so that no branch of the project tree succeeds.  It also can be
viewed
 externally as a weakness in the strength of the current offerings behind the
 overall project... but your mileage may vary.  It can also be extremely
damaging
 to developer egos, and can deepend community schisms by becomming a dividing
 line.
 
 So you only really want to fork unless there's absolutely nowhere else to go,
 since it's so risky.
 
 If one looks at the D language as an open specification, with Digital Mars as
 merely a compiler vendor, then forking makes some sense.  other compilers could
 easily push the envelope of the spec and reccomend updates to Walter so DMD
 continues to be a part of the pack.  
 
 As to whom controls the actual D spec, that's the rub.  A true fork would
 indicate that there would be competing D specifications out there, which could
 be a very bad thing; it could re-invent the problem with C and C++ which is
what
 D was supposed to fix.
 
 And besides, nobody is impressed by the "our wheel is rounder" approach. <j/k>
 
 
 An interim solution:
 
 Instead of outright saying "D is ours, and we'll go make it our way", perhaps a
 compromise should be struck instead?  
 
 First of all, GDC is a very capable rendition of D and is dire need of
 additional support.  It is presently 7 (going on 8) releases behind DMD.  If
 you're looking to get D to make an impact, then get hacking!  
 
 Second, I strongly reccomend that everyone get a copy of either GDC or Ben
 Hinkle's DMDFE distribution.  The current front end is intimidating, but
 enabling some of the debug printf statements can yield a lot of insight as to
 how source is modeled and used to drive the actual compiler***.  A determined
 hacker can easily start adding their own customizations to the language within
a
 mere week, possibly less.
 
 Third, after you are familiar with the front-end, start test-bedding new
 language concepts.  Build working groups, and encourage the community to try
the
 new features on for size.  Nothing says "this works better" than being able to
 point at code that compiles on *something*.  Its far and away better than all
 the theory and "this works in forth/lisp/perl" discussions we've seen so far.
 Plus, the process will inevidably weed out concepts that are simply too hard to
 implement.
 
 I would like to think that publishing compiler patches, to GDC and possibly
DMD,
 would *accelerate* the overall state of the language in a way that Forking
 couldn't possibly achieve.  At worst, the testbed compiler patches will get
 folded into GDC first, which will (later on) fork quite naturally on its own
 under the weight of these enhancements.
 
 This is the model currently adopted for Ares, and is working quite well.
 
 Another exmaple: what if Georg and friends formed a Vectorization working group
 for D?  They could acutally implement vectorization for D and pound out all the
 kinks.  Then they can just supply the community with a reference
implementation,
 documentation, and possibly furnish Walter with a diff/patch so DMD could fully
 implement the feature.  No forking, just collaborating with the community as a
 whole (Walter included) to get the *implemented enhancements* included in GDC
 and/or DMD.
 
 It seems like a lot, and is certainly more effort than begging for language
 enhancements from Walter.  But it is *orders of magnitude* less complicated and
 less cumbersome than starting up an over-arching new project to steer the
entire
 state of the language, *and* compete with DMD.  People will all want to go
their
 own way at some point anyhow, so why not encourage and leverage that behavior
 instead?
 
 
 The bottom line here is: why offically fork, when you can form nimble task
 groups that can build proof-of-concepts for consumption by Walter et al, all by
 hacking the front-end source.  The tools are there, the talent is there, and
the
 ambition is there.  In other words, get it done today instead of after
 everything goes through a (forked) committee that may very well frustrate
people
 as much as Walter has.
 
 (*** A doxygen replacement, and a myriad of other tools, could also consume
data
 generated by the front-end)
 
 - EricAnderton at yahoo

Eric,

Thanks for your "middle-of-the-road" suggestion.  In many ways, I was
thinking along these lines when I said that maybe Walter sees some
goodness in this effort and incorporates it back into DMD.  I was indeed
thinking of an amicable fork, but maybe a proof-of-concept approach
would work better.  I agree with Anders that anything would be better
than arguing in the NG.  However, this group needs to be prepared for
continued silence from Walter and go their own way.

BA

"Kris" <fu bar.com> writes:

That is how I read your initial post, Brad.

i.e. "the NG has little or zero impact anyway, so get over it, people, and
take control of your own destiny"

There's no slight to Walter, or anyone else for that matter. To me, it's
simply noting "the emperor has no clothes on", where the emperor is the NG.
I think you were right on the money.

- Kris


"Brad Anderson" <brad dsource.dot.org> wrote in message
news:d3m7gi$1bd9$1 digitaldaemon.com...
 The bottom line here is: why offically fork, when you can form nimble


task
 groups that can build proof-of-concepts for consumption by Walter et al,


all by
 hacking the front-end source.  The tools are there, the talent is there,


and the
 ambition is there.  In other words, get it done today instead of after
 everything goes through a (forked) committee that may very well


frustrate people
 as much as Walter has.

 (*** A doxygen replacement, and a myriad of other tools, could also


consume data
 generated by the front-end)

 - EricAnderton at yahoo

 Eric,

 Thanks for your "middle-of-the-road" suggestion.  In many ways, I was
 thinking along these lines when I said that maybe Walter sees some
 goodness in this effort and incorporates it back into DMD.  I was indeed
 thinking of an amicable fork, but maybe a proof-of-concept approach
 would work better.  I agree with Anders that anything would be better
 than arguing in the NG.  However, this group needs to be prepared for
 continued silence from Walter and go their own way.

 BA

"Matthew" <admin.hat stlsoft.dot.org> writes:

 And I am glad Walter keeps to his opinion only. Otherwise D will end up like
 linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
 touches here, someone touches there and it becomes useless. If you want it to
be
 useless you have to start over and modify all the software...
 It can't be good for everyone. People are different and thats cool about it.

This implies either that Walter knows more about *every* issue than any person
here, or that embracing opinion from any 
parties, however qualified, is too dangerous to be not worth the manifest
improvement in the language.

Neither of these hold up to scrutiny.

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

"Matthew" <admin.hat stlsoft.dot.org> wrote in message
news:d3mlf0$1pkj$4 digitaldaemon.com...
 And I am glad Walter keeps to his opinion only. Otherwise D will end up like
 linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
 touches here, someone touches there and it becomes useless. If you want it to
be
 useless you have to start over and modify all the software...
 It can't be good for everyone. People are different and thats cool about it.

 This implies either that Walter knows more about *every* issue than any person
here, or that embracing opinion from any
 parties, however qualified, is too dangerous to be not worth the manifest
improvement in the language.

 Neither of these hold up to scrutiny.

Those aren't the only possible ways of looking at it.  The way I see it, the D
language is his baby.  We should respect it as such.  It will grow up and get
out on it's own, but for now we should be content to give him suggestions on
how to raise it, and the information that we feel he needs to make informed
choices, but accept his decisions.  This is my "opinion" and I won't hold
anyone else to it... but I point it out here because I believe it has merit. 
Change is good, but too much ungoverned change too quickly can be catastrophic.
 This is a lesson taught by the extremes of evolution and war.  Encourage
evolution.  Discourage war.  :)

TZ

Brad Anderson <brad dsource.dot.org> writes:

bobef wrote:
 I am sorry for the rude language but some things have to be said as 

they are.
 First I want to ask what does the subject means? The F Word? What is 

that? Fuck
 Walter? Fuck D? Fuck this community? Fuck the world? Which of them? 

Or it is a
 joke because only fuck is called the f word but it could be any 

F-word? And if
 it is fuck then say it rebel boy! Loudly and proudly. If this is your 

position
 stand for it. This is not a kids forum after all.


[snip]

 And I am glad Walter keeps to his opinion only. Otherwise D will end 

up like
 linux - a useless bag of SHIT. In matter of fact everyone's shit. Someone
 touches here, someone touches there and it becomes useless. If you 

want it to be
 useless you have to start over and modify all the software...

[snip]

 This is sick you know. Somebody do something. And someone else makes
 organization to take over his work. And force him to do it not in his 

way.
 Americans could think of such sick crap... Are you americans? Why 

don't you just
 let Walter do what he believes is best?



So now you want space at dsource.org.  It's a good thing I'm a nice 
F'ing guy.

Oh, and btw, bobef, this is a Linux server running in America.  Enjoy.

BA

John Reimer <brk_6502 yahoo.com> writes:

Brad Anderson wrote:
 
 So now you want space at dsource.org.  It's a good thing I'm a nice 
 F'ing guy.
 
 Oh, and btw, bobef, this is a Linux server running in America.  Enjoy.
 
 BA

You know what, Brad?  I think this is a case of "foot-in-the-mouth" for 
bobef.  He had no idea who you were, did he? ;-P

He sure didn't help himself here.  All I can say is he had it coming. 
I'm afraid as interesting as his project looks, I quickly got turned off 
when I started browsing the beginnings of his forum....

Sorry, bobef... wisdom and discretion are important attributes even on 
the internet.  Be careful what you say...

- JJR

A series of unfortunate events...

Georg Wrede <georg.wrede nospam.org> writes:

Brad Anderson wrote:
 Over and over again, it's been proposed that some organization be
 formed to augment Walter's efforts, whether library or lang standard.
 Let me say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not
 going to happen, then get David Friedman on board, or do it
 yourselves, but fork the damn language and fix the warts you guys
 want to fix!  If you come up with something better, then maybe Walter
 will want to merge back with you.  When he holds the keys to the
 kingdom, however, the advancement made will not be sufficient in your
 minds.

The thought has increasingly been on my mind too.
But I've tried not to take it up. :-)

bobef <bobef_member pathlink.com> writes:

In article <425E626B.8000602 nospam.org>, Georg Wrede says...
Brad Anderson wrote:
 Over and over again, it's been proposed that some organization be
 formed to augment Walter's efforts, whether library or lang standard.
 Let me say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not
 going to happen, then get David Friedman on board, or do it
 yourselves, but fork the damn language and fix the warts you guys
 want to fix!  If you come up with something better, then maybe Walter
 will want to merge back with you.  When he holds the keys to the
 kingdom, however, the advancement made will not be sufficient in your
 minds.

The thought has increasingly been on my mind too.
But I've tried not to take it up. :-)


This is sick you know. Somebody do something. And someone else makes
organization to take over his work. And force him to do it not in his way.
Americans could think of such sick crap... Are you americans? Why don't you just
let Walter do what he believes is best? Sorry if my words are too strong or if I
missunderstood something...

nod <nod_member pathlink.com> writes:

In article <d3lsgu$vps$1 digitaldaemon.com>, bobef says...
In article <425E626B.8000602 nospam.org>, Georg Wrede says...
Brad Anderson wrote:
 Over and over again, it's been proposed that some organization be
 formed to augment Walter's efforts, whether library or lang standard.
 Let me say this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not
 going to happen, then get David Friedman on board, or do it
 yourselves, but fork the damn language and fix the warts you guys
 want to fix!  If you come up with something better, then maybe Walter
 will want to merge back with you.  When he holds the keys to the
 kingdom, however, the advancement made will not be sufficient in your
 minds.

The thought has increasingly been on my mind too.
But I've tried not to take it up. :-)


This is sick you know. Somebody do something. And someone else makes
organization to take over his work. And force him to do it not in his way.
Americans could think of such sick crap... Are you americans? Why don't you just
let Walter do what he believes is best? Sorry if my words are too strong or if I
missunderstood something...

I do think you are misunderstanding and overreacting. The people here seem smart
and (mostly) friendly, and would not "take over" Walters or anyone elses work. A
fork would be very much less dramatic than you seem to believe.

A "fork" could merely be an effort to take some of the weight off Walters (way
to burdened imo) shoulders, and give us others a chance to directly impact the
language itself. By being an "experimental" spec of the language where features
are tested and  bugs stamped out, I believe it could only benefit the language
(the original one) as a whole . Walter could of course participate, if he chose
to, and could merge back features that work out at his own leisure.

And "Americans could think of such sick crap"? WTF? I am not from America, and
although some Americans are undoubtedly rather arrogant, so are many Europeans.
Singling out any group of people based on nationality (or race, or belief) is
ignorant, please refrain from this.

"Matthew" <admin.hat stlsoft.dot.org> writes:

 Americans could think of such sick crap... Are you americans?

Wow! That's fighting talk, to be sure.

I'm not American. I'm an English-Australian. But lots of my friends are
American (i.e from the US). Whatever one might 
think of "America" at the moment, I have to tell you that Americans are, in my
experience, extremely kind and friendly 
people.

If your comment has a geo-political influence, then I can see where you're
coming from. Unfortunately, I don't see much 
spitting distance between America and England or America and Australia, so I
for one cannot single out America. Same 
goes for any of the major powers. In fact, apart from Bhutan, I pretty much
think every government and political system 
is a stinking heap of corruption.

So I'd advise you keep your broad-brush bias to yourself, as you'll offend
individuals who don't deserve it, and have no 
effect on any governments who might.

"Dave" <Dave_member pathlink.com> writes:

Ok - Let's try and cut through all of the bullshit here. Fork the language, 
C'MON!! Sounds like a slow and sure death to me.

Don't get me wrong Brad, I do appreciate that the threat of the 'F-word' is 
sometimes needed to get things moving, especially since some very talented 
and smart people seem to be at an impass here, but F'ing D now really would, 
well "F" D for good, IMO.

Below is what I propose should be done.. I apologize beforehand if I hurt 
any feelings here by leaving people out (many of you have put a lot of 
effort into building/testing/fixing things, and all of it is valued), or by 
putting five people on the spot.

Matthew, Kris, Ben and David Friedman:

From your posts, I can surmise that the first three have:
1) All done serious library development with D.
2) Been the most substantively vocal on D language issues.
3) All worked extensively with a lot of applications done w/ other 
languages.

And of course you, David, have actually implemented another working D 
compiler.

What I would suggest is each list their top 3 (and only 3) shortcomings of 
the D language itself (not bugs, not library). Keep it short and number the 
issues please.

Then, I suggest that out of these 12 submissions, 6 could be agreed upon by 
you four as top priority and something that would make sense for compiler 
developers. There may well be some overlap in the original 12 and the idea 
is to boil things down to a handful of the most important issues.

I figure once the language spec. is solid enough for major library and 
compiler development, fixing compiler bugs and fixing/developing the library 
will more easily follow.

Is this something that could be of any value?? If so, who will start?

Once it is done, there will be 6 major issues for Walter to (hopefully) 
focus and comment on, even that comment happens to be "get F'd".

- Dave

(I cross-posted to D.gnu because that seems relevant here).

"Brad Anderson" <brad dsource.dot.org> wrote in message 
news:d3l33k$6fr$1 digitaldaemon.com...
Speaking for myself, I've certainly become far grumpier of late. It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be if
my sons become software engineers and go and look up some of their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.


 Something's gotta change. I hope it'll be something organisationally with 
 D, but I suspect it'll be my conscience making me leave in response to 
 increasing number of reasonable complaints about my curmudgeon. :-(

 This would truly be a shame.  The way a technology advances, IMO, is the 
 conflict resolution between knowledgeable, passionate, and boisterous 
 people who are fully engaged in the birthing of the technology.  If the 
 conflict is fully vetted, and reasonable compromises can be made, in 
 addition to minds being kept open to future change, then advancement is 
 realized.

 I hate to name names, and forgive me if I've omitted you, but for D and 
 this NG to lose the voices of Matthew, Kris, Sean and others would be a 
 HUGE loss.  They've already been quiet recently as it is.  This is a 
 direct result of Walter not finding compromise or recognizing the value of 
 other expert opinions that may differ from his own.  Not sure who said 
 this, but maybe ESR? and it's paraphrased...  "Thrill your users. At 
 first, it will be the early adopters.  Make the experts / power users 
 happy..."

 This would be a bit more powerful from someone writing a lot of D code on 
 a consistent basis, but I've lurked for 2+ years, and have seen smart 
 people jump up and volunteer some great ideas.  I don't care if they get 
 shot down ... to a point.  Some of them are now gone because of the 
 problem noted above.

 Over and over again, it's been proposed that some organization be formed 
 to augment Walter's efforts, whether library or lang standard.  Let me say 
 this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to 
 happen, then get David Friedman on board, or do it yourselves, but fork 
 the damn language and fix the warts you guys want to fix!  If you come up 
 with something better, then maybe Walter will want to merge back with you. 
 When he holds the keys to the kingdom, however, the advancement made will 
 not be sufficient in your minds.

 One effort that holds my respect is Ares, because it's the only thing 
 those guys can do to compensate for their perceived shortcomings of 
 Phobos.  Even if they've stopped (slowed) participating in the NG, they 
 are still coding that lib.  Compiler warts and all.  It's all that they 
 can control.

 <somewhat-random-tangent>
 If none of this works, and you truly want to leave D, then come join me in 
 the world of Common Lisp.  Talk about a powerful language devoid of lots 
 of the warts you speak of.  (btw, don't tell me it's interpreted, slow, 
 full of parentheses, and its developers talk funny.  All of that's bull, 
 except for the parens, and they're manageable.)  All of the Design 
 Patterns you OO guys work with daily are basically to make up for 
 Java/C/C++/D's lack of late binding, and there's nothing like the macros 
 or closures in Lisp.
 </somewhat-random-tangent>

 I have learned a ton from this NG, watching the more experienced 
 developers debate, and firmly believe that D would be worse off without 
 the powerful voices that chime in regularly.  But I empathize with them in 
 their frustration to affect change recently (i.e. before 1.0).

 WTF, Walter?  Don't answer my post.  Answer theirs...

 And if he doesn't answer, boys, go ahead and fork it.  There has to be 
 some way to affect change and realize the great promise that keeps you 
 coming back to the current quagmire.

 BA 

brad domain.invalid writes:

Dave wrote:
<SNIP>
 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by 
 you four as top priority and something that would make sense for compiler 
 developers. There may well be some overlap in the original 12 and the idea 
 is to boil things down to a handful of the most important issues.
 
 I figure once the language spec. is solid enough for major library and 
 compiler development, fixing compiler bugs and fixing/developing the library 
 will more easily follow.
 
 Is this something that could be of any value?? If so, who will start?
 
 Once it is done, there will be 6 major issues for Walter to (hopefully) 
 focus and comment on, even that comment happens to be "get F'd".
 
 - Dave
 

I think this is the best idea I've heard in a long long time.  Fork IMHO 
is too strong of a word, but an open group that tinkers with features 
they'd like to see in D - that sounds like a plan.  It sounds like a lot 
of work, but I am sure that most features could be implemented in less 
lines than the arguments that happen on this NG :)

Brad

"Matthew" <admin.hat stlsoft.dot.org> writes:

<brad domain.invalid> wrote in message news:d3ml1c$1p77$1 digitaldaemon.com...
 Dave wrote:
 <SNIP>
 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by
you four as top priority and something 
 that would make sense for compiler developers. There may well be some overlap
in the original 12 and the idea is to 
 boil things down to a handful of the most important issues.

 I figure once the language spec. is solid enough for major library and
compiler development, fixing compiler bugs and 
 fixing/developing the library will more easily follow.

 Is this something that could be of any value?? If so, who will start?

 Once it is done, there will be 6 major issues for Walter to (hopefully) focus
and comment on, even that comment 
 happens to be "get F'd".

 - Dave

 I think this is the best idea I've heard in a long long time.  Fork IMHO is
too strong of a word, but an open group 
 that tinkers with features they'd like to see in D - that sounds like a plan. 
It sounds like a lot of work, but I am 
 sure that most features could be implemented in less lines than the arguments
that happen on this NG :)

I'd be keen to get hold of the necessary stuff to be able to effect changes to
the language and try them out. Can anyone 
summarise the steps to do this? I'd prefer Win32, but can live with doing it on
Linux.

brad domain.invalid writes:

 
 I'd be keen to get hold of the necessary stuff to be able to effect changes to
the language and try them out. Can anyone 
 summarise the steps to do this? I'd prefer Win32, but can live with doing it
on Linux.
 
 
 

The first step would be to go to http://home.earthlink.net/~dvdfrdmn/d/, 
follow the instructions and see how far you get.  I've managed to build 
GDC on x86 Linux and MacOSX with little trouble & a cross compiled ARM 
version with a little more trouble.  I don't see why a Cygwin build 
couldn't be fought with and made to work - but the easiest out of the 
box behaviour will be x86 Linux I think.
If you run into problems the D.gnu list has helpful people in it.

Brad

pragma <pragma_member pathlink.com> writes:

In article <d3mlf1$1pkj$5 digitaldaemon.com>, Matthew says...
<brad domain.invalid> wrote in message news:d3ml1c$1p77$1 digitaldaemon.com...
 Dave wrote:
 <SNIP>
 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by
you four as top priority and something 
 that would make sense for compiler developers. There may well be some overlap
in the original 12 and the idea is to 
 boil things down to a handful of the most important issues.

 I figure once the language spec. is solid enough for major library and
compiler development, fixing compiler bugs and 
 fixing/developing the library will more easily follow.

 Is this something that could be of any value?? If so, who will start?

 Once it is done, there will be 6 major issues for Walter to (hopefully) focus
and comment on, even that comment 
 happens to be "get F'd".

 - Dave

 I think this is the best idea I've heard in a long long time.  Fork IMHO is
too strong of a word, but an open group 
 that tinkers with features they'd like to see in D - that sounds like a plan. 
It sounds like a lot of work, but I am 
 sure that most features could be implemented in less lines than the arguments
that happen on this NG :)

I'd be keen to get hold of the necessary stuff to be able to effect changes to
the language and try them out. Can anyone 
summarise the steps to do this? I'd prefer Win32, but can live with doing it on
Linux.

As far as I know you'd have to go with GDC on top of Cygwin if you want to
continue to run windows.  If you mean "compiles and links against win32", then I
think we're all out of luck.

- EricAnderton at yahoo

Georg Wrede <georg.wrede nospam.org> writes:

Matthew wrote:
 <brad domain.invalid> wrote in message
 news:d3ml1c$1p77$1 digitaldaemon.com...
 
 Dave wrote: <SNIP>
 
 Then, I suggest that out of these 12 submissions, 6 could be
 agreed upon by you four as top priority and something that would
 make sense for compiler developers. There may well be some
 overlap in the original 12 and the idea is to boil things down to
 a handful of the most important issues.
 
 I figure once the language spec. is solid enough for major
 library and compiler development, fixing compiler bugs and 
 fixing/developing the library will more easily follow.
 
 Is this something that could be of any value?? If so, who will
 start?
 
 Once it is done, there will be 6 major issues for Walter to
 (hopefully) focus and comment on, even that comment happens to be
 "get F'd".
 
 - Dave
 

 
 I think this is the best idea I've heard in a long long time.  Fork
 IMHO is too strong of a word, but an open group that tinkers with
 features they'd like to see in D - that sounds like a plan.  It
 sounds like a lot of work, but I am sure that most features could
 be implemented in less lines than the arguments that happen on this
 NG :)

 
 
 I'd be keen to get hold of the necessary stuff to be able to effect
 changes to the language and try them out. Can anyone summarise the
 steps to do this? I'd prefer Win32, but can live with doing it on
 Linux.

Even better, maybe someone could create a TinkeringDistro ?

pragma <pragma_member pathlink.com> writes:

In article <d3ml1c$1p77$1 digitaldaemon.com>, brad domain.invalid says...
It sounds like a lot 
of work, but I am sure that most features could be implemented in less 
lines than the arguments that happen on this NG :)

I'll add that not only would it take less lines, but it would take less time
too.

Even if Walter could implement compiler changes three times as fast as the
average developer here, four or more people on a single task could out pace him.
Multiply that by three or so task-teams and you have a similar increase in
productivity, and a similar reduction in time-to-concept.  

Furthermore, you only need *one* language-addendum project to be accepted for
inclusion to D, at such a team size to call the exercise a success. Since in
theory, they arrived at a solution faster than Walter ever could have.


- EricAnderton at yahoo

nod <nod_member pathlink.com> writes:

In article <d3ml1c$1p77$1 digitaldaemon.com>, brad domain.invalid says...
I think this is the best idea I've heard in a long long time.  Fork IMHO 
is too strong of a word, but an open group that tinkers with features 
they'd like to see in D - that sounds like a plan.  It sounds like a lot 
of work, but I am sure that most features could be implemented in less 
lines than the arguments that happen on this NG :)

Brad

I would like to see this! I know I am a bit of a newbie on these newsgroups, so
I an not sure people will even listen to me. I will try anyways though because
as the rest of you all, I too like the D language and would love to see it
become the great language it has the potential to become.

So, instead of bickering about whether this is a good idea or not, I say we try
it out. I will now start "The GDC Hackers Guild", a place for us who want to try
and help Walter out more than by just giving opinions. I have made a page for it
on the wiki4d (see link below), but I hope we can create our own homepage,
because I believe that infrastructure and communication is important. For now
though, well make do with the D.gnu NG and the wiki.

The first thing we need to do is to learn to hack the GDC sources, and try and
help David out. I am not very strong at this myself, but I believe that we can
do it if we help eachother out. When we get somewhat acquainted with the
sources, we may want to start adding some features... but lets take it one step
at a time. :)

For myself, I will try to start creating some infrastructure, and helping out...

If anyone wants help getting GDC installed (or linux for that matter) please
dont hesitate to ask in the D.gnu newsgroup.

Only the best of intentions
-Nod-

(linky: http://www.prowiki.org/wiki4d/wiki.cgi?GdcHacking )
(ps, I added a link to the frontpage too, if no one objects...)

John Reimer <John_member pathlink.com> writes:

*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

As benevolent as Walter has been with putting such a wonderful effort into the D
language, I doubt the language can ever completely "break out" until he realizes
it will eventually have to be opened up to more outside influence...someday,
sometime.  He can do it gradually, but I think it's inevitable for D's success
for many of the reasons already discribed. Many, many suggestions on how and why
this should happen have been put forth numerous times.

Morever, this kind of topic seems to make it's rounds multiple times during the
year with what looks like an approaching critical mass on the horizon.

I don't know if forking is the solution, but I can really understand why the
temptation to do so is there.  D could collapse whether or not a fork is
initiated.

I should really have shutup.  Becoming a lurker on the list is getting to become
more attractive occupation all the time. :-(

- JJR

PS  The exasperation of these few should not be constrewed as lack of
appreciation to Walter for all that he's done.  Everyone /wants/ D to succeed,
and Walter with it.  The motivation behind the criticism is really a deep desire
to see D succeed in a /big/ way, rather than fade into proprietary nothingness
which I fear is the current direction D's taking.


In article <d3mh30$1lbv$1 digitaldaemon.com>, Dave says...
Ok - Let's try and cut through all of the bullshit here. Fork the language, 
C'MON!! Sounds like a slow and sure death to me.

Don't get me wrong Brad, I do appreciate that the threat of the 'F-word' is 
sometimes needed to get things moving, especially since some very talented 
and smart people seem to be at an impass here, but F'ing D now really would, 
well "F" D for good, IMO.

Below is what I propose should be done.. I apologize beforehand if I hurt 
any feelings here by leaving people out (many of you have put a lot of 
effort into building/testing/fixing things, and all of it is valued), or by 
putting five people on the spot.

Matthew, Kris, Ben and David Friedman:

From your posts, I can surmise that the first three have:
1) All done serious library development with D.
2) Been the most substantively vocal on D language issues.
3) All worked extensively with a lot of applications done w/ other 
languages.

And of course you, David, have actually implemented another working D 
compiler.

What I would suggest is each list their top 3 (and only 3) shortcomings of 
the D language itself (not bugs, not library). Keep it short and number the 
issues please.

Then, I suggest that out of these 12 submissions, 6 could be agreed upon by 
you four as top priority and something that would make sense for compiler 
developers. There may well be some overlap in the original 12 and the idea 
is to boil things down to a handful of the most important issues.

I figure once the language spec. is solid enough for major library and 
compiler development, fixing compiler bugs and fixing/developing the library 
will more easily follow.

Is this something that could be of any value?? If so, who will start?

Once it is done, there will be 6 major issues for Walter to (hopefully) 
focus and comment on, even that comment happens to be "get F'd".

- Dave

(I cross-posted to D.gnu because that seems relevant here).

"Brad Anderson" <brad dsource.dot.org> wrote in message 
news:d3l33k$6fr$1 digitaldaemon.com...
Speaking for myself, I've certainly become far grumpier of late. It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be if
my sons become software engineers and go and look up some of their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.


 Something's gotta change. I hope it'll be something organisationally with 
 D, but I suspect it'll be my conscience making me leave in response to 
 increasing number of reasonable complaints about my curmudgeon. :-(

 This would truly be a shame.  The way a technology advances, IMO, is the 
 conflict resolution between knowledgeable, passionate, and boisterous 
 people who are fully engaged in the birthing of the technology.  If the 
 conflict is fully vetted, and reasonable compromises can be made, in 
 addition to minds being kept open to future change, then advancement is 
 realized.

 I hate to name names, and forgive me if I've omitted you, but for D and 
 this NG to lose the voices of Matthew, Kris, Sean and others would be a 
 HUGE loss.  They've already been quiet recently as it is.  This is a 
 direct result of Walter not finding compromise or recognizing the value of 
 other expert opinions that may differ from his own.  Not sure who said 
 this, but maybe ESR? and it's paraphrased...  "Thrill your users. At 
 first, it will be the early adopters.  Make the experts / power users 
 happy..."

 This would be a bit more powerful from someone writing a lot of D code on 
 a consistent basis, but I've lurked for 2+ years, and have seen smart 
 people jump up and volunteer some great ideas.  I don't care if they get 
 shot down ... to a point.  Some of them are now gone because of the 
 problem noted above.

 Over and over again, it's been proposed that some organization be formed 
 to augment Walter's efforts, whether library or lang standard.  Let me say 
 this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to 
 happen, then get David Friedman on board, or do it yourselves, but fork 
 the damn language and fix the warts you guys want to fix!  If you come up 
 with something better, then maybe Walter will want to merge back with you. 
 When he holds the keys to the kingdom, however, the advancement made will 
 not be sufficient in your minds.

 One effort that holds my respect is Ares, because it's the only thing 
 those guys can do to compensate for their perceived shortcomings of 
 Phobos.  Even if they've stopped (slowed) participating in the NG, they 
 are still coding that lib.  Compiler warts and all.  It's all that they 
 can control.

 <somewhat-random-tangent>
 If none of this works, and you truly want to leave D, then come join me in 
 the world of Common Lisp.  Talk about a powerful language devoid of lots 
 of the warts you speak of.  (btw, don't tell me it's interpreted, slow, 
 full of parentheses, and its developers talk funny.  All of that's bull, 
 except for the parens, and they're manageable.)  All of the Design 
 Patterns you OO guys work with daily are basically to make up for 
 Java/C/C++/D's lack of late binding, and there's nothing like the macros 
 or closures in Lisp.
 </somewhat-random-tangent>

 I have learned a ton from this NG, watching the more experienced 
 developers debate, and firmly believe that D would be worse off without 
 the powerful voices that chime in regularly.  But I empathize with them in 
 their frustration to affect change recently (i.e. before 1.0).

 WTF, Walter?  Don't answer my post.  Answer theirs...

 And if he doesn't answer, boys, go ahead and fork it.  There has to be 
 some way to affect change and realize the great promise that keeps you 
 coming back to the current quagmire.

 BA 

Dave <Dave_member pathlink.com> writes:

In article <d3mo3u$1s66$1 digitaldaemon.com>, John Reimer says...
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I really don't have a stand on any of the issues in this thread, because,
frankly, I just jumped in when I saw the 'F-word' branch.

I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

I recognize the problem. But I also recognize that Walter (or anyone) would need
some sort of priority list to work from. That is damn hard to get when you have
people figuratively screaming at you from all directions in a forum like this.

I just tried to put forth something I really haven't seen detailed before.
Mentioned maybe, but not detailed.

Specifically that these four guys, who have used D extensively, put in 3
suggestions each - in one place as it were - to try and get the ball rolling
rather than endlessly arguing point/counter-point.

I've agreed with these people on past issues while disagreeing with Walter and
vice-versa. This is not about defending Walter's decision making process, it's
about getting the most out of D w/o fragmenting the group in some way.

I will gladly defer to what Kris, Matthew, Ben and David Friedman come up with
simply because they have used the language more and for more intensive stuff
than I have.

Bluntly, this was an attempt to get Walter to listen to them. I think a well
reasoned, concise list from such power users would be something usable. If it is
well done, makes sense and is demonstrably better for the language and /then/
Walter doesn't implement them because of some personal choice, fork away.

As it has been to date, once a complaint/proposal is made, the thread more often
than not goes off into la-la land somewhere where it is hard for anyone to
figure out if any conclusion was arrived at, much less what the conclusion is.

The way it stands right now, a fork would be a disaster because often times the
people talking about doing the fork can't even agree amongst themselves what
should be in the fork. And often times there would end-up being another 'Walter'
to lynch 6 months down the road with the fork once 'the group' see's 'the
leader' as a threat to their personal preferences. And then both D and the
'community' would be further fragmented.

See, most of these issues are not something that can be proven demonstrably
better by building another compiler (forking) because they are, in the final
analysis, subjective. Therefore you have to push the changes through by some
sort of concensus, as bad as that sounds.

I should have known.. The only one who could successfully get a list effort like
this going would have been Walter himself. But I figured it was worth a shot
anyhow.

- Dave

John Reimer <John_member pathlink.com> writes:

An excellent, clear-headed response, Dave. Thanks for taking the time to write
it.  I understand where you are coming from now.  It was good to get your
perspective clarified.  I'll choose not to continue on this topic, though, since
I'm more than a little weary of it.

-JJR

In article <d3mrrt$1v94$1 digitaldaemon.com>, Dave says...
In article <d3mo3u$1s66$1 digitaldaemon.com>, John Reimer says...
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

I really don't have a stand on any of the issues in this thread, because,
frankly, I just jumped in when I saw the 'F-word' branch.

I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

I recognize the problem. But I also recognize that Walter (or anyone) would need
some sort of priority list to work from. That is damn hard to get when you have
people figuratively screaming at you from all directions in a forum like this.

I just tried to put forth something I really haven't seen detailed before.
Mentioned maybe, but not detailed.

Specifically that these four guys, who have used D extensively, put in 3
suggestions each - in one place as it were - to try and get the ball rolling
rather than endlessly arguing point/counter-point.

I've agreed with these people on past issues while disagreeing with Walter and
vice-versa. This is not about defending Walter's decision making process, it's
about getting the most out of D w/o fragmenting the group in some way.

I will gladly defer to what Kris, Matthew, Ben and David Friedman come up with
simply because they have used the language more and for more intensive stuff
than I have.

Bluntly, this was an attempt to get Walter to listen to them. I think a well
reasoned, concise list from such power users would be something usable. If it is
well done, makes sense and is demonstrably better for the language and /then/
Walter doesn't implement them because of some personal choice, fork away.

As it has been to date, once a complaint/proposal is made, the thread more often
than not goes off into la-la land somewhere where it is hard for anyone to
figure out if any conclusion was arrived at, much less what the conclusion is.

The way it stands right now, a fork would be a disaster because often times the
people talking about doing the fork can't even agree amongst themselves what
should be in the fork. And often times there would end-up being another 'Walter'
to lynch 6 months down the road with the fork once 'the group' see's 'the
leader' as a threat to their personal preferences. And then both D and the
'community' would be further fragmented.

See, most of these issues are not something that can be proven demonstrably
better by building another compiler (forking) because they are, in the final
analysis, subjective. Therefore you have to push the changes through by some
sort of concensus, as bad as that sounds.

I should have known.. The only one who could successfully get a list effort like
this going would have been Walter himself. But I figured it was worth a shot
anyhow.

- Dave

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Personally, I thought it was a good suggestion and was very articulately
presented.  Sure, there are many variations on it that may be equally
effective, and sure there's the possibility that it's already been tried, but
it was in my opinion a good suggestion regardless.

TechnoZeus

"Dave" <Dave_member pathlink.com> wrote in message
news:d3mrrt$1v94$1 digitaldaemon.com...
 In article <d3mo3u$1s66$1 digitaldaemon.com>, John Reimer says...
*sigh*  More useless advice... more advice along the same lines that's been
offered many times before.  This is so wearisome.  It would be better to just
admit that you don't agree with these guys than to try to offer the /same/
solution that has been the very basis for these guys frustrations with the
current system.

 I really don't have a stand on any of the issues in this thread, because,
 frankly, I just jumped in when I saw the 'F-word' branch.

I apologize if this comes out too strongly, but what makes you think that Kris,
Matthew and others haven't done similar to your suggestion many times before?
Why do you suppose Walter might be so inclined to agree to there "top" listed
suggestions now if he hasn't in the past? This /is/ the very problem!

 I recognize the problem. But I also recognize that Walter (or anyone) would
need
 some sort of priority list to work from. That is damn hard to get when you have
 people figuratively screaming at you from all directions in a forum like this.

 I just tried to put forth something I really haven't seen detailed before.
 Mentioned maybe, but not detailed.

 Specifically that these four guys, who have used D extensively, put in 3
 suggestions each - in one place as it were - to try and get the ball rolling
 rather than endlessly arguing point/counter-point.

 I've agreed with these people on past issues while disagreeing with Walter and
 vice-versa. This is not about defending Walter's decision making process, it's
 about getting the most out of D w/o fragmenting the group in some way.

 I will gladly defer to what Kris, Matthew, Ben and David Friedman come up with
 simply because they have used the language more and for more intensive stuff
 than I have.

 Bluntly, this was an attempt to get Walter to listen to them. I think a well
 reasoned, concise list from such power users would be something usable. If it
is
 well done, makes sense and is demonstrably better for the language and /then/
 Walter doesn't implement them because of some personal choice, fork away.

 As it has been to date, once a complaint/proposal is made, the thread more
often
 than not goes off into la-la land somewhere where it is hard for anyone to
 figure out if any conclusion was arrived at, much less what the conclusion is.

 The way it stands right now, a fork would be a disaster because often times the
 people talking about doing the fork can't even agree amongst themselves what
 should be in the fork. And often times there would end-up being another
'Walter'
 to lynch 6 months down the road with the fork once 'the group' see's 'the
 leader' as a threat to their personal preferences. And then both D and the
 'community' would be further fragmented.

 See, most of these issues are not something that can be proven demonstrably
 better by building another compiler (forking) because they are, in the final
 analysis, subjective. Therefore you have to push the changes through by some
 sort of concensus, as bad as that sounds.

 I should have known.. The only one who could successfully get a list effort
like
 this going would have been Walter himself. But I figured it was worth a shot
 anyhow.

 - Dave

John Reimer <John_member pathlink.com> writes:

In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...
Personally, I thought it was a good suggestion and was very articulately
presented.  Sure, there are many variations on it that may be equally
effective, and sure there's the possibility that it's already been tried, but
it was in my opinion a good suggestion regardless.

TechnoZeus

Then you didn't understand the context of my complaint at all...  probably as a
result of not being around this group over the last 2 years (or perhaps you
have, and I haven't noticed).

This kind of a suggestion is not new, nor is it exceedingly original in
comparison to past suggestions.  Nor does my assessment of Dave's response have
anything to do with his level of articulation in the post: I have no issue with
his delivery abilities (that would be pretty stupid of me to pick on).

A suggestion is only useful if it solves the original problem.  Since his did
not, nor did it present something new, thus my conclusion and frustration.
People have listed wonderfully organized priority items in the past that have
done little to influence Walter's own priority list.  When people continue to
repeat old suggestions for old problems, admittedly quite innocently and in a
slightly different format, no amount of articulation can make the idea savoury.
It's like dumping salt on fleshy, open wound.  It's even more annoying when
people come by and say, "why that's a wonderful idea!" as if it were that rare
sought after solution to the whole problem. (my apologies for griping on this)
:-( 

Dave was right in his final assessment (and a good one):

"I should have known.. The only one who could successfully get a list effort
like this going would have been Walter himself"

Unfortuantely, though, objectivity in the list making in this situation would be
even harder from one man's experience.

But nonetheless Dave clarified his reasoning in his last post, enough for me to
respect his perspective.  Whether or not, I agree with him is irrelevent.

Incidently, it's not likely you will notice Walter responding to any of these
"suggestions" in this topic. 

-JJR

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"John Reimer" <John_member pathlink.com> wrote in message 
news:d3nes9$2e9d$1 digitaldaemon.com...
 In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...
Personally, I thought it was a good suggestion and was very 
articulately presented.  Sure, there are many variations on it 
that may be equally effective, and sure there's the possibility 
that it's already been tried, but it was in my opinion a good 
suggestion regardless.

TechnoZeus

 Then you didn't understand the context of my complaint at all... 
 probably as a
 result of not being around this group over the last 2 years (or 
 perhaps you
 have, and I haven't noticed).

 This kind of a suggestion is not new, nor is it exceedingly 
 original in
 comparison to past suggestions.  Nor does my assessment of Dave's 
 response have
 anything to do with his level of articulation in the post: I have 
 no issue with
 his delivery abilities (that would be pretty stupid of me to pick 
 on).

 A suggestion is only useful if it solves the original problem. 
 Since his did
 not, nor did it present something new, thus my conclusion and 
 frustration.
 People have listed wonderfully organized priority items in the 
 past that have
 done little to influence Walter's own priority list.  When people 
 continue to
 repeat old suggestions for old problems, admittedly quite 
 innocently and in a
 slightly different format, no amount of articulation can make the 
 idea savoury.
 It's like dumping salt on fleshy, open wound.  It's even more 
 annoying when
 people come by and say, "why that's a wonderful idea!" as if it 
 were that rare
 sought after solution to the whole problem. (my apologies for 
 griping on this)
 :-(

 Dave was right in his final assessment (and a good one):

 "I should have known.. The only one who could successfully get a 
 list effort
 like this going would have been Walter himself"

 Unfortuantely, though, objectivity in the list making in this 
 situation would be
 even harder from one man's experience.

 But nonetheless Dave clarified his reasoning in his last post, 
 enough for me to
 respect his perspective.  Whether or not, I agree with him is 
 irrelevent.

 Incidently, it's not likely you will notice Walter responding to 
 any of these
 "suggestions" in this topic.

Well, now I really am pessimistic. John's always been the very 
opposite in temperament to the GOM, but those who know him will 
recognise in these last couple of posts a degree of impatience and 
irritation that's quite new.

I take this as a sign that the frustration is not only not being 
rectified in its source(s), but is in fact spreading and 
reinforcing.

:-(

Matthew

P.S. I agree with what you've said, btw, John

Georg Wrede <georg.wrede nospam.org> writes:

Matthew wrote:
 "John Reimer" <John_member pathlink.com> wrote in message 
 news:d3nes9$2e9d$1 digitaldaemon.com...
 
In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...


Incidently, it's not likely you will notice Walter responding to 
any of these
"suggestions" in this topic.

 
 
 Well, now I really am pessimistic. John's always been the very 
 opposite in temperament to the GOM, but those who know him will 
 recognise in these last couple of posts a degree of impatience and 
 irritation that's quite new.
 
 I take this as a sign that the frustration is not only not being 
 rectified in its source(s), but is in fact spreading and 
 reinforcing.
 
 :-(
 
 Matthew
 
 P.S. I agree with what you've said, btw, John

If I have any clue of what's going on, it's this:

Walter is currently working 80-hour weeks to get the next DMD out, 
presumably even a release candidate.

This precludes him from even reading this newsgroup -- where most of the 
stuff is about "we need this too in 1.0, and it's urgent" or "We 
absolutely need this Grand Feature for 2.0". (Of which I'm  pretty 
guilty myself!) (BTW, this particular NG _is_ for these things, so it's 
ok to do that. ;-) )

All, that reading this NG would produce, is just distraction for him -- 
from the very work we all want him to do. (Some of us even seem to want 
him do that like 100 hours per week.)

Of course this ultimately leads to frustration: "he's not commenting, 
dammit he's not even listening".

Having understood this, there's an even more frustrating thing: when 
he'll eventually come out from his chamber, he'll have such a pile of 
messages to catch up, that the chances of even the BEST suggestions 
_ever_ reachim are slim.

Oh, well. There's a time for everything. Maybe I'll defer my new great 
ideas till after summer.

Thus, maybe this really is the time to go tinkering instead. I've 
already promised to tinker with metalanguage and a tool explicitly for 
language tinkering.

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

I understood the context.  You're right that I haven't been here to see where
that context came from, but I understood it quite well.  My opinion remains
though that it was a good suggestion.  If someone tells a kid to look both ways
before crossing the street, it's not any less of a good idea just because
they've been told before.  If someone shows kindness to a stranger, it's not
any less of a good deed just because they have done it before.  The context
doesn't, in my opinion, reduce the validity of the facts.  A good suggestion is
still a good suggestion, no matter how many times it gets repeated.  Maybe
eventually it will sink in, and pay off.

TZ

"John Reimer" <John_member pathlink.com> wrote in message
news:d3nes9$2e9d$1 digitaldaemon.com...
 In article <d3mtl8$20v8$1 digitaldaemon.com>, TechnoZeus says...
Personally, I thought it was a good suggestion and was very articulately
presented.  Sure, there are many variations on it that may be equally
effective, and sure there's the possibility that it's already been tried, but
it was in my opinion a good suggestion regardless.

TechnoZeus

 Then you didn't understand the context of my complaint at all...  probably as a
 result of not being around this group over the last 2 years (or perhaps you
 have, and I haven't noticed).

 This kind of a suggestion is not new, nor is it exceedingly original in
 comparison to past suggestions.  Nor does my assessment of Dave's response have
 anything to do with his level of articulation in the post: I have no issue with
 his delivery abilities (that would be pretty stupid of me to pick on).

 A suggestion is only useful if it solves the original problem.  Since his did
 not, nor did it present something new, thus my conclusion and frustration.
 People have listed wonderfully organized priority items in the past that have
 done little to influence Walter's own priority list.  When people continue to
 repeat old suggestions for old problems, admittedly quite innocently and in a
 slightly different format, no amount of articulation can make the idea savoury.
 It's like dumping salt on fleshy, open wound.  It's even more annoying when
 people come by and say, "why that's a wonderful idea!" as if it were that rare
 sought after solution to the whole problem. (my apologies for griping on this)
 :-(

 Dave was right in his final assessment (and a good one):

 "I should have known.. The only one who could successfully get a list effort
 like this going would have been Walter himself"

 Unfortuantely, though, objectivity in the list making in this situation would
be
 even harder from one man's experience.

 But nonetheless Dave clarified his reasoning in his last post, enough for me to
 respect his perspective.  Whether or not, I agree with him is irrelevent.

 Incidently, it's not likely you will notice Walter responding to any of these
 "suggestions" in this topic.

 -JJR

Georg Wrede <georg.wrede nospam.org> writes:

Good to hear from you too! It's been a while since I last noticed a post 
by you.

John Reimer wrote:
 As benevolent as Walter has been with putting such a wonderful effort
 into the D language, I doubt the language can ever completely "break
 out" until he realizes it will eventually have to be opened up to
 more outside influence...someday, sometime.  He can do it gradually,
 but I think it's inevitable for D's success for many of the reasons
 already discribed. Many, many suggestions on how and why this should
 happen have been put forth numerous times.

Yes. That'll happen, period. It's not like any of (us+Walter) even 
together _could_ change that fact. That's just the way things go.

We might delay this with 6 to 12 months, with a lot of effort, but 
eventually that'll happen. With or without us. Besides Walter knows it too.

 Morever, this kind of topic seems to make it's rounds multiple times
 during the year with what looks like an approaching critical mass on
 the horizon.
 
 I don't know if forking is the solution, but I can really understand
 why the temptation to do so is there.  D could collapse whether or
 not a fork is initiated.
 
 I should really have shutup.  Becoming a lurker on the list is
 getting to become more attractive occupation all the time. :-(
 
 - JJR
 
 PS  The exasperation of these few should not be constrewed as lack of
  appreciation to Walter for all that he's done.  Everyone /wants/ D
 to succeed, and Walter with it.  The motivation behind the criticism
 is really a deep desire to see D succeed in a /big/ way, rather than
 fade into proprietary nothingness which I fear is the current
 direction D's taking.

Euphoria is a good example of that having happened. Even if the language 
has many stunning features, and is as nice to work with as D. And even 
when Rob hasn't done things "wrong" in so many specific ways. (IMHO) 
(Not that I'd be blaming Walter either for having done "wrong"!)

Euphoria is growing, but the world is growing faster. So, relatively 
speaking, it's falling "into proprietary nothingness". And the window of 
opportunity may be going out of scope.

 In article <d3mh30$1lbv$1 digitaldaemon.com>, Dave says...
 
 Ok - Let's try and cut through all of the bullshit here. Fork the
 language, C'MON!! Sounds like a slow and sure death to me.
 
 Don't get me wrong Brad, I do appreciate that the threat of the
 'F-word' is sometimes needed to get things moving, especially since
 some very talented and smart people seem to be at an impass here,
 but F'ing D now really would, well "F" D for good, IMO.


IMHO, a big fork would be a serious risk. But 200 small forks -- none of 
which aspire to "take over" might be good.

(I get my kids to help me with house cleaning. I let them choose what 
they want to do. Works well. One maybe carries trash, another checks for 
toys under the piano before I vacuum, etc. Even the smallest 
contribution is welcome by me, and I show it.)

----

A dream come true (for me, at least) would be a D distro that you just 
download and run make install. (Or whatever Windows equivalent.)

It would be recompilable "with a click of a button", so to speak.

One would start by, say, making a new keyword into the language and 
recompiling: "make recompileD". (There'd be a mini-howto on how to make 
a helloWord. Pun intended.)

Then one could just test the new thing (say a keyword foo that does 
something trivial, just to show to oneself that it can be done).

----

Loads of people could this way get up and running with doing lab 
experiments, presumably first with their pet peeves:

  - So get rid of ===
  - create isnot, and see if it really is useful (by then writing 
programs for this "my_modified_D".)
  - ask guys what small things you could try to fix
  - if you're lucky and get some done, send them (to Walter? or to the 
dSource CVS, i dunno right now)
  - maybe try a total separation of reference and value equality tests
  - [your dream here]
  - ... etc.

The Bazaar, indeed!

-----

This package would contain Thomas' stress suite, and running it on the 
"my_new_D_compiler_of_the_day" would be trivial "right out of the box".

The more industrious and capable could get up and running wit ambitious 
things, and those at the other end might want to find typos in compiler 
error messages, or some such "non hairy", to begin with.

And, possibly a lot of folks would start tuning Phobos instead of 
breaking the compiler. :-)

-----

Many small forks give a huge meal.  :-)

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Well, it would be of no use to me personally at this time, and I'm not one of
the people that you mentioned, but in my opinion if there was to be one thing
that I could somehow get added to or changed in the DMD compiler, it would be
the addition of interfaces that would allow programmers to write DLLs that
could add to or supercede functionality within D at the lowest level reasonably
possible.  That would allow opinions to be tested and evidence of what "else"
is worth adding or changing to be produced in tangable form, and it would also
provide a way to allow Walter to delegate some of the workload, as well as
allowing the D community to delegate some of it for him and submit their
results for his aproval and possible internal integration.

TechnoZeus

"Dave" <Dave_member pathlink.com> wrote in message
news:d3mh30$1lbv$1 digitaldaemon.com...
 Ok - Let's try and cut through all of the bullshit here. Fork the language,
 C'MON!! Sounds like a slow and sure death to me.

 Don't get me wrong Brad, I do appreciate that the threat of the 'F-word' is
 sometimes needed to get things moving, especially since some very talented
 and smart people seem to be at an impass here, but F'ing D now really would,
 well "F" D for good, IMO.

 Below is what I propose should be done.. I apologize beforehand if I hurt
 any feelings here by leaving people out (many of you have put a lot of
 effort into building/testing/fixing things, and all of it is valued), or by
 putting five people on the spot.

 Matthew, Kris, Ben and David Friedman:

 From your posts, I can surmise that the first three have:
 1) All done serious library development with D.
 2) Been the most substantively vocal on D language issues.
 3) All worked extensively with a lot of applications done w/ other
 languages.

 And of course you, David, have actually implemented another working D
 compiler.

 What I would suggest is each list their top 3 (and only 3) shortcomings of
 the D language itself (not bugs, not library). Keep it short and number the
 issues please.

 Then, I suggest that out of these 12 submissions, 6 could be agreed upon by
 you four as top priority and something that would make sense for compiler
 developers. There may well be some overlap in the original 12 and the idea
 is to boil things down to a handful of the most important issues.

 I figure once the language spec. is solid enough for major library and
 compiler development, fixing compiler bugs and fixing/developing the library
 will more easily follow.

 Is this something that could be of any value?? If so, who will start?

 Once it is done, there will be 6 major issues for Walter to (hopefully)
 focus and comment on, even that comment happens to be "get F'd".

 - Dave

 (I cross-posted to D.gnu because that seems relevant here).

 "Brad Anderson" <brad dsource.dot.org> wrote in message
 news:d3l33k$6fr$1 digitaldaemon.com...
Speaking for myself, I've certainly become far grumpier of late. It
seems I take a break due to some pointless/bad experience, and
foreswear any such future behaviour on my part or being sucked into
fatuous debates by others, and yet within a couple of days of
'coming back' it's happening again. Needless to say, I find this
truly uncharacteristic - honest! <G> - behaviour of mine both
appalling and intriguing. (I often think how embarrassed I'll be if
my sons become software engineers and go and look up some of their
cranky old fart of a father's semi-lucid ranting and pompous
condescension.)

I'm totally with you, since I find the same thing happening.


 Something's gotta change. I hope it'll be something organisationally with
 D, but I suspect it'll be my conscience making me leave in response to
 increasing number of reasonable complaints about my curmudgeon. :-(

 This would truly be a shame.  The way a technology advances, IMO, is the
 conflict resolution between knowledgeable, passionate, and boisterous
 people who are fully engaged in the birthing of the technology.  If the
 conflict is fully vetted, and reasonable compromises can be made, in
 addition to minds being kept open to future change, then advancement is
 realized.

 I hate to name names, and forgive me if I've omitted you, but for D and
 this NG to lose the voices of Matthew, Kris, Sean and others would be a
 HUGE loss.  They've already been quiet recently as it is.  This is a
 direct result of Walter not finding compromise or recognizing the value of
 other expert opinions that may differ from his own.  Not sure who said
 this, but maybe ESR? and it's paraphrased...  "Thrill your users. At
 first, it will be the early adopters.  Make the experts / power users
 happy..."

 This would be a bit more powerful from someone writing a lot of D code on
 a consistent basis, but I've lurked for 2+ years, and have seen smart
 people jump up and volunteer some great ideas.  I don't care if they get
 shot down ... to a point.  Some of them are now gone because of the
 problem noted above.

 Over and over again, it's been proposed that some organization be formed
 to augment Walter's efforts, whether library or lang standard.  Let me say
 this carefully:  THIS IS NOT GOING TO HAPPEN.  If it's not going to
 happen, then get David Friedman on board, or do it yourselves, but fork
 the damn language and fix the warts you guys want to fix!  If you come up
 with something better, then maybe Walter will want to merge back with you.
 When he holds the keys to the kingdom, however, the advancement made will
 not be sufficient in your minds.

 One effort that holds my respect is Ares, because it's the only thing
 those guys can do to compensate for their perceived shortcomings of
 Phobos.  Even if they've stopped (slowed) participating in the NG, they
 are still coding that lib.  Compiler warts and all.  It's all that they
 can control.

 <somewhat-random-tangent>
 If none of this works, and you truly want to leave D, then come join me in
 the world of Common Lisp.  Talk about a powerful language devoid of lots
 of the warts you speak of.  (btw, don't tell me it's interpreted, slow,
 full of parentheses, and its developers talk funny.  All of that's bull,
 except for the parens, and they're manageable.)  All of the Design
 Patterns you OO guys work with daily are basically to make up for
 Java/C/C++/D's lack of late binding, and there's nothing like the macros
 or closures in Lisp.
 </somewhat-random-tangent>

 I have learned a ton from this NG, watching the more experienced
 developers debate, and firmly believe that D would be worse off without
 the powerful voices that chime in regularly.  But I empathize with them in
 their frustration to affect change recently (i.e. before 1.0).

 WTF, Walter?  Don't answer my post.  Answer theirs...

 And if he doesn't answer, boys, go ahead and fork it.  There has to be
 some way to affect change and realize the great promise that keeps you
 coming back to the current quagmire.

 BA

Sean Kelly <sean f4.ca> writes:

In article <d3kunk$3dp$2 digitaldaemon.com>, Matthew says...
But this is what I simply don't get. This 'industry' we're in is 
exactly what should attract people who genuinely care about the 
quality of their work. Lord knows, it's not for the chicks, or the 
money, or the doing-great-work-for-those-less-fortunate. Since it's 
somewhat related to maths, surely the "if it's not elegant, it's not 
correct/finished" ethos should pervade.

I'm not sure I agree.  While I certainly feel this way and know others who do as
well, there are plenty of people in this industry (and any other) who do not.
Not to mention those with massive egos and little skill.  People are people, be
they computer geeks or anything else.

And yet, the older I get, or certainly since the "heady days of the 
internet", it seems like more and more people care less and less 
about the elegance.

Okay, this may indeed be true.  As any practice gains popularity it will attract
more folks who are not 'purists.'  And it doesn't much help in this case that
some companies (MS, for example) have tried to simplify the job so that "anyone
can do it."  Whether simplifying the task beneficial or not, I don't believe
it's been a good thing that there is a perception that this job is easier than
it is.  I've had to maintain too much badly written code to think otherwise :)

Sometimes I think I was foolish not to take up my cousin's offer to 
go and work in The City (== London's financial community) when I got 
my PhD. He said he'd make me a millionnaire in less than 10 years. 
That was 10 years ago. ;/

Hah.  There are finance geeks just like there are software geeks, but I prefer
the latter.  And being a millionaire would not be a sufficient reward for
dealing with traders every day ;)


Sean

David Medlock <amedlock nospam.org> writes:

Sean Kelly wrote:

 In article <d3kunk$3dp$2 digitaldaemon.com>, Matthew says...
 
But this is what I simply don't get. This 'industry' we're in is 
exactly what should attract people who genuinely care about the 
quality of their work. Lord knows, it's not for the chicks, or the 
money, or the doing-great-work-for-those-less-fortunate. Since it's 
somewhat related to maths, surely the "if it's not elegant, it's not 
correct/finished" ethos should pervade.

 
 
 I'm not sure I agree.  While I certainly feel this way and know others who do
as
 well, there are plenty of people in this industry (and any other) who do not.
 Not to mention those with massive egos and little skill.  People are people, be
 they computer geeks or anything else.
 

My frustration with programming is not with mathematically 'purity' in 
the language, but with concentration on providing power on the wrong end 
of the language spectrum( by this I mean where the programmer gets his 
meat hooks into the process).

On the one hand, we are given nice syntactical and resource 
tools(templates, garbage collection,#define macros), but very little in 
the way of _semantical_ tools, such as macros that Lisp/Scheme provides, 
or Scheme continuations which make exceptions, coroutines, 
opApply-type-iterators and a host of other 'features' easy to implement.

Given these are hard to implement in compiled languages without explicit 
closures, but provide overall power at all levels rather than power in a 
few areas.

-DavidM

PS.  This does not diminish what Walter has accomplished, just my 
thoughts on how to move down the language power spectrum.

Kris <Kris_member pathlink.com> writes:

In article <d3h7fb$1iv$1 digitaldaemon.com>,
=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kris wrote: (and I cut it down heavily)

 This is all to do with compatability vis-a-vis accepted usage. It is not a
 proposition for the ideal usage of these operators.

It does sound like a compatibility kludge, that much is certain.

 And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.


Noooooo! :-)

What I meant was this: currently, 

- D 'is' is same as C/Java '=='

- D '==' is the effectively the same as Java equals(), but with the twist noted
previously

That is; D 'is' always does "trivial" equality, and D '==' does "deep" equality
(plus that twist noted).

*If* these two were role-reversed such that '==' /always/ does trivial equality
instead, then you'd be right at home with >, <, and friends; and backward
compatability is magically restored (yes, I'm aware of the opCmp implications). 

That would leave 'is' to do deep equality instead of its current role. 

In the original post, I noted "perhaps D has made a blunder in this regard". The
explicit reversal of these roles is what I was getting at (WRT backward
compatability).

I have little doubt Walter chose to reverse the roles intentionally, and I don't
imagine for one fleeting moment they will change again. But you, Ben, and I all
concur that the change breaks compatability with currently accepted idioms. This
is what I found interesting enough to post about in the first place. 

What's also interesting is that nobody here seems to care much about
compatability at this rather fundamental level (or haven't raised their hand
high enough yet). It seems far more important to have, for example, libraries
that mimic the C approach :-)

[the only person I've seen to make a fuss over claims of compatability is Walter
himself. Such is the dichotomy of D]

The saving grace, of course, is that we at least have a choice. I'll use 'is'
for everything except deep comparisons ~ which for my libraries will likely
hover around that magic 98.75% usage. "Deep equivalence" is just not used very
much outside of some specific algorithms (such as containers). I think if you
analyzed your own typical code, it would perhaps be in that vicinity also?

When it comes to general-case programming, consistency is king. Jumping between
equivalence operators, depending upon the data-type in question, is an ugly yet
seemingly necessary evil. Where one has to do it, it should be in the minority
case rather than the majority. Yes?

The kludge, as you called it, currently appears to be present in the majority
case. Before simply refuting that, please try some analysis on a large code base
of quality code :-)

Cheers, Anders;

- Kris


p.s. As Brad noted, this topic is recieving far more attention than the arguably
more important "true inner class". Go figure :-)

"Ben Hinkle" <bhinkle mathworks.com> writes:

 When it comes to general-case programming, consistency is king. Jumping 
 between
 equivalence operators, depending upon the data-type in question, is an 
 ugly yet
 seemingly necessary evil. Where one has to do it, it should be in the 
 minority
 case rather than the majority. Yes?

In templates I use the equals and compare functions in the TypeInfo. But 
that requires more work on the coder's part. TypeInfos are very handy things 
for generic code. 

=?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:

Kris wrote:

And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.

 
 Noooooo! :-)

Phew. :-)

 What I meant was this: currently, 
 
 - D 'is' is same as C/Java '=='

No argument there. Although that's: "when applied to Object references".

That it happens to work for primitive types in D, is simply because
identity falls back to equality for those... It "really" uses '=='.
Not that it matters in the slightest, in practice. Just in theo-logy/ry.

 - D '==' is the effectively the same as Java equals(), but with the twist noted
 previously
 
 That is; D 'is' always does "trivial" equality, and D '==' does "deep" equality
 (plus that twist noted).

"trivial equality" being identity, and "deep equality" being equality,
OK. (i.e. 'is' compares the pointers, and '==' compares the contents)

D '==' is the same as Java 'equals', for Object references.
It's also the same as Java's '==', for the primitive types.

It adds new functionality over C for comparing structs/arrays,
but works the same as in C when comparing two pointer values...

The difference between references and pointers in D, is
something of a dark side of allowing both things at once
(C and Java does not have it, since they only do one thing)
I guess those are the breaks when doing "multi-paradigm"...

 *If* these two were role-reversed such that '==' /always/ does trivial equality
 instead, then you'd be right at home with >, <, and friends; and backward
 compatability is magically restored (yes, I'm aware of the opCmp
implications). 

I'm not sure I follow ? Would < and > also work on the reference value ?
(i.e. compare the pointers to the objects, instead of calling on opCmp)

Or would == now work on the reference, and < > work on the contents ?
(which was why I commented that it would be "< is >", if it was so...)

 That would leave 'is' to do deep equality instead of its current role. 

Then one might as well rename it 'equals', than re-using 'is' keyword ?

Assuming here that 'is' has some kind of connection with "identity",
why it was suggested as a transcript of '==='/≡ in the first place ?

But I don't really see a reason to flip '==' over to "Java mode", except
that it would make it easier to port things like large libraries over...

But D and Java do differ in other areas, just not this particular one ?

 In the original post, I noted "perhaps D has made a blunder in this regard".
The
 explicit reversal of these roles is what I was getting at (WRT backward
 compatability).

Java and D made different choices. I'm not sure that D made a "blunder".

 I have little doubt Walter chose to reverse the roles intentionally, and I
don't
 imagine for one fleeting moment they will change again. But you, Ben, and I all
 concur that the change breaks compatability with currently accepted idioms.
This
 is what I found interesting enough to post about in the first place. 

That's OK, as I thought that what Walter did was unreverse the old ones.
i.e. the reference types were the odd ones in Java, set straight in D.

Then Walter made a different choice about whether comparing null should
throw a NullPointerException or not, but that's for another discussion.

 What's also interesting is that nobody here seems to care much about
 compatability at this rather fundamental level (or haven't raised their hand
 high enough yet). It seems far more important to have, for example, libraries
 that mimic the C approach :-)

Well, some might have thought that Java was broken and that D fixed it ?

 The saving grace, of course, is that we at least have a choice. I'll use 'is'
 for everything except deep comparisons ~ which for my libraries will likely
 hover around that magic 98.75% usage. "Deep equivalence" is just not used very
 much outside of some specific algorithms (such as containers). I think if you
 analyzed your own typical code, it would perhaps be in that vicinity also?

Sorry, I don't have that much of a object-oriented codebase right now.
But when I ran some quick greps on the JDK 1.5 codebase, what I saw was
a whole lot of "x == null" and "x != null" which Walter has now decided 
shall be "x" and "!x" in D (just like they were in C++ in the Dark Ages)

Then there were some enum stuff, not sure if those counts since D has
integer(-ish) enumerations just like C - and not object Enums like Java.
Then there was 'equals', about a quarter of the *total* amount of '==' 
calls, and then 'compare' again about a quarter of the equality calls.

So I guess your 98-2 breakdown just does not sound familiar to me ?

 The kludge, as you called it, currently appears to be present in the majority
 case. Before simply refuting that, please try some analysis on a large code
base
 of quality code :-)

Well, it reminds me of the comment made on the "bool" vs. "bit" page:

"The only problem is that a bit is not a bool. :-)"
Same problem here, just with equals and identity...

While it might work out (perhaps?), it still doesn't qualify as pretty.

Especially not if D also allows '==' for structs and arrays, neither
of which are even present in Java. (Similar to "no operator overloads")


Side note:

equality for subclasses. Thus, to check the references you use a cast...

But that's pretty similar to how the default implementation of equals
in the java.lang.Object simply compares the object references anyway ?

For things like String, it is overridden to check all the characters.


--anders

"Kris" <fu bar.com> writes:

 I have little doubt Walter chose to reverse the roles intentionally, and


I don't
 imagine for one fleeting moment they will change again. But you, Ben,


and I all
 concur that the change breaks compatability with currently accepted


idioms. This
 is what I found interesting enough to post about in the first place.

 That's OK, as I thought that what Walter did was unreverse the old ones.
 i.e. the reference types were the odd ones in Java, set straight in D.

Heck, I don't really care if B, BCPL, ALGOL, C, C++ and Java are /all/
broken, Anders. That's not what this thread is about, so let's not turn it
into an ideology quagmire.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

That's OK, as I thought that what Walter did was unreverse the old ones.
i.e. the reference types were the odd ones in Java, set straight in D.

 
 Heck, I don't really care if B, BCPL, ALGOL, C, C++ and Java are /all/
 broken, Anders. That's not what this thread is about, so let's not turn it
 into an ideology quagmire.

Really, I only meant when it comes to the '==' operator and references ?

As in: No, I didn't see any compelling reason to switch the operators...

--anders

"C is quirky, flawed, and an enormous success" -- Dennis M. Ritchie

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Kris" <Kris_member pathlink.com> wrote in message 
news:d3hcf3$60r$1 digitaldaemon.com...
 In article <d3h7fb$1iv$1 digitaldaemon.com>,
 =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
Kris wrote: (and I cut it down heavily)

 This is all to do with compatability vis-a-vis accepted usage. 
 It is not a
 proposition for the ideal usage of these operators.

It does sound like a compatibility kludge, that much is certain.

 And if the roles of '= =' and 'is' were reversed ...?

As in: < is > ? That does look more than a little strange.


 Noooooo! :-)

 What I meant was this: currently,

 - D 'is' is same as C/Java '=='

 - D '==' is the effectively the same as Java equals(), but with 
 the twist noted
 previously

 That is; D 'is' always does "trivial" equality, and D '==' does 
 "deep" equality
 (plus that twist noted).

 *If* these two were role-reversed such that '==' /always/ does 
 trivial equality
 instead, then you'd be right at home with >, <, and friends; and 
 backward
 compatability is magically restored (yes, I'm aware of the opCmp 
 implications).

 That would leave 'is' to do deep equality instead of its current 
 role.

 In the original post, I noted "perhaps D has made a blunder in 
 this regard". The
 explicit reversal of these roles is what I was getting at (WRT 
 backward
 compatability).

 I have little doubt Walter chose to reverse the roles 
 intentionally, and I don't
 imagine for one fleeting moment they will change again. But you, 
 Ben, and I all
 concur that the change breaks compatability with currently 
 accepted idioms. This
 is what I found interesting enough to post about in the first 
 place.

Whooshka! Straight over my head.

Can you re-explain, with the assumption that your audience has half 
the IQ you think it has?

 What's also interesting is that nobody here seems to care much 
 about
 compatability at this rather fundamental level (or haven't raised 
 their hand
 high enough yet). It seems far more important to have, for 
 example, libraries
 that mimic the C approach :-)

Please exemplify this statement. (Still desperately trying to get ya 
...)

Georg Wrede <georg.wrede nospam.org> writes:

Anders F Björklund wrote:
 "Been annoyed by", yes. :-) Wonder what dumb font would mix the two up ?
 Surely people aren't using Helvetica or Arial to program in ? <horrors>

:-)

But program code gets printed in books, magazines, etc.

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Georg Wrede wrote:

 But program code gets printed in books, magazines, etc.

Or quoted on web pages. Usually in typewriter fonts, though ?

--anders

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Georg Wrede wrote:

 "Been annoyed by", yes. :-) Wonder what dumb font would mix the two up ?
 Surely people aren't using Helvetica or Arial to program in ? <horrors>

 
 But program code gets printed in books, magazines, etc.

And if you mess '==' and '===' up, wouldn't you have the
same problems with the '=' and '==' expressions as well ?

That can easily be solved, though. We can change to using
':=' for all assignments. Or start them all with 'LET' ?

;-)

Seriously, I don't think "is" is bad. But this !(is nice).

--anders

Georg Wrede <georg.wrede nospam.org> writes:

Kris wrote:
 "Anders F Björklund" <afb algonet.se> wrote:
 Kris wrote:
 
 Disagree here, Eric. I think Java tried to cater to the most 
 widely used cases of '= =' such that it rarely conflicts with 
 established use (per the original example given). Don't forget
 that Java was attempting to pick up C/C++ users, just like D ;-)


 
 [...]
 
 Having said that, the now-generic usage of 'is' has somewhat 
 switched its role from an "identity" operator, and has <gasp> 
 suddenly become identical to the Java '= =' :-)




 If the assigned role of '= =' and 'is' were flipped, D would be just 
 like C/Java ~ with the aforementioned twist regarding the equals() 
 working with primitives as well as aggregates. That is, since '= =' 
 is currently the same as a Java equals(), but works with primitives 
 also, and 'is' currently plays the identical role of the Java '= =' 
 operator, switching the D operators around makes D equivalent to Java
  in the usage of '= =' and equivalent to C for the largest percentage
  of uses (given the original illustration). The use of 'is' would 
 thus be relegated to "deep equivalence" testing instead.


 What I do question is the break in backward compatability, which you 
 (and others) acknowledge.
 
 However if the D operators '= =' and 'is' were role-reversed, the C &
  Java compatability would be restored for the majority case (98.75% 
 in the use-case given). There's still compromise going on there, 
 naturally. But, shouldn't one optimize for the majority case?

Looks like the case FOR swapping == and is, has been established quite well!

Now let's hear it from the other side: do there exist _valid_ reasons 
for not to swap them?

(With "valid" I mean other than whining about old code breaking.)

"Regan Heath" <regan netwin.co.nz> writes:

Having read this whole thread, and feeling the need to at least put my  
opinion out there...

On Tue, 12 Apr 2005 23:41:40 +0300, Georg Wrede <georg.wrede nospam.org>  
wrote:
 Looks like the case FOR swapping == and is, has been established quite  
 well!

It can be summed up as "so it behaves like C/Java" right?

 Now let's hear it from the other side: do there exist _valid_ reasons  
 for not to swap them?
 (With "valid" I mean other than whining about old code breaking.)

Because IMO the afore mentioned reason isn't a valid one *for* swapping  
them.

Here's my personal take on "==" and "is". There appears to be a rule, with  
one exception.

"==" compares value.
"is" compares identity.

for all types, no matter what. Except.. "is" is identical to "==" for  
value types because comparing identity for value types is meaningless.

I'll admit when I first started with D I was at first confused by this  
change. However, now, I like it a lot. It's simple, it's straightforward  
and it makes sense. (once you get over the fact that it's different).

The fact that "==" segv's on null doesn't bother me, I'm used to it  
happening when I compare the value of something non-existant, eg.

char *p = NULL:
if (*p == 'a') // segv

My gut feeling (as I have no proof/example) is that "==" will be used just  
as frequently outside container implementations as "is". I'm thinking of  
basic types where by habit I use "==" (I could now use "is").

In response to Brad's question about how we define a type that behaves  
like a user defined one.. I don't know. It seems at first glance/thought  
that a struct would need to be used as it exhibits value type behaviour.  

can either.

In response to Brad's comment about Derek's problem with deep/shallow  
copy. I believe there is a need for a deep-copy operator, eg. ":=" which  
for all types copies the "value" (AKA deep copy). The is analogous to "=="  
which for all types compares that value.

In response to the idea for a word to replace "!==". I think it should be  
replaced, I think "===" and "!==" should be deprecated. I like either:  
isnt, isnot

Regan

=?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Regan Heath wrote:

 Here's my personal take on "==" and "is". There appears to be a rule, 
 with  one exception.
 
 "==" compares value.
 "is" compares identity.
 
 for all types, no matter what. Except.. "is" is identical to "==" for  
 value types because comparing identity for value types is meaningless.

There is one more exception, and is not that obvious - at first:
the default implementation of Object.opEquals compares identity...

module object;
class Object
{
     int opEquals(Object o)
     {
	return this is o;
     }
}

package java.lang;
public class Object {
     public boolean equals(Object obj) {
	return (this == obj);
     }
}

All this means is that all Objects are by default "unique" and separate,
unless they explicitly declare that the state matters more than the ref.

--anders

"Regan Heath" <regan netwin.co.nz> writes:

On Wed, 13 Apr 2005 00:34:33 +0200, Anders F Björklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 Here's my personal take on "==" and "is". There appears to be a rule,  
 with  one exception.
  "==" compares value.
 "is" compares identity.
  for all types, no matter what. Except.. "is" is identical to "==" for   
 value types because comparing identity for value types is meaningless.

 There is one more exception, and is not that obvious - at first:
 the default implementation of Object.opEquals compares identity...

True. With no description of how to compare the contents (i.e. no  
OpEquals) it does "default" to comparing identity.
This seems the most sensible choice to me. i.e. Until you tell it how the  
value compares to other values the identity is the value of the object.  
What else could it do? throw an exception?

Regan

=?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Regan Heath wrote:

 This seems the most sensible choice to me. i.e. Until you tell it how 
 the  value compares to other values the identity is the value of the 
 object.  What else could it do? throw an exception?

Well, it could just crash...
Or perhaps segfault on one OS and throw an Exception on another ?

Or was that when comparing things with null, I mixed them up. :-)


Seriously, the alternative would be to compare the bit contents.
(not saying that this would be a *good* alternative, or anything)

Comparing bits for structs, and references for objects, sounds good.
(as a default, then the object could always just implement opEquals)

--anders

"Regan Heath" <regan netwin.co.nz> writes:

On Wed, 13 Apr 2005 00:51:53 +0200, Anders F Björklund <afb algonet.se>  
wrote:
 Regan Heath wrote:

 This seems the most sensible choice to me. i.e. Until you tell it how  
 the  value compares to other values the identity is the value of the  
 object.  What else could it do? throw an exception?

 Well, it could just crash...
 Or perhaps segfault on one OS and throw an Exception on another ?

 Or was that when comparing things with null, I mixed them up. :-)

:)

 Seriously, the alternative would be to compare the bit contents.
 (not saying that this would be a *good* alternative, or anything)

 Comparing bits for structs, and references for objects, sounds good.
 (as a default, then the object could always just implement opEquals)

Isn't this what it does currently?

http://www.digitalmars.com/d/ctod.html#structcmp

Regan

=?ISO-8859-15?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Regan Heath wrote:

 Comparing bits for structs, and references for objects, sounds good.
 (as a default, then the object could always just implement opEquals)

 
 Isn't this what it does currently?
 http://www.digitalmars.com/d/ctod.html#structcmp

It is (sorry), and it's a good default too.

--anders

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

"Georg Wrede" <georg.wrede nospam.org> wrote in message 
news:425C3284.5070700 nospam.org...
 Kris wrote:
 "Anders F Björklund" <afb algonet.se> wrote:
 Kris wrote:

 Disagree here, Eric. I think Java tried to cater to the most 
 widely used cases of '= =' such that it rarely conflicts with 
 established use (per the original example given). Don't forget
 that Java was attempting to pick up C/C++ users, just like D 
 ;-)


 [...]

 Having said that, the now-generic usage of 'is' has somewhat 
 switched its role from an "identity" operator, and has <gasp> 
 suddenly become identical to the Java '= =' :-)




 If the assigned role of '= =' and 'is' were flipped, D would be 
 just like C/Java ~ with the aforementioned twist regarding the 
 equals() working with primitives as well as aggregates. That is, 
 since '= =' is currently the same as a Java equals(), but works 
 with primitives also, and 'is' currently plays the identical role 
 of the Java '= =' operator, switching the D operators around 
 makes D equivalent to Java
  in the usage of '= =' and equivalent to C for the largest 
 percentage
  of uses (given the original illustration). The use of 'is' would 
 thus be relegated to "deep equivalence" testing instead.


 What I do question is the break in backward compatability, which 
 you (and others) acknowledge.

 However if the D operators '= =' and 'is' were role-reversed, the 
 C &
  Java compatability would be restored for the majority case 
 (98.75% in the use-case given). There's still compromise going on 
 there, naturally. But, shouldn't one optimize for the majority 
 case?

 Looks like the case FOR swapping == and is, has been established 
 quite well!

 Now let's hear it from the other side: do there exist _valid_ 
 reasons for not to swap them?

 (With "valid" I mean other than whining about old code breaking.)

Sorry, I must've missed that. Where is a good case for swapping 
made?

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Matthew wrote:

Looks like the case FOR swapping == and is, has been established 
quite well!

Now let's hear it from the other side: do there exist _valid_ 
reasons for not to swap them?

(With "valid" I mean other than whining about old code breaking.)

 
 Sorry, I must've missed that. Where is a good case for swapping 
 made?

The case FOR is where Kris notes that in his ported Java library,
'===' (identity) is used more often than what '==' (equality) is.

Therefore, D should treat references like Java does (i.e. like pointers)
Since that would make it more compatible with Java, and with C pointers.

Then, in a bizarre twist, 'is' should now be used to compare equality...
(since it does work with primitives, as identity falls back to equality)

In case it wasn't obvious already, I didn't agree with the new idea?
But we still need a new operator for '!==', and 'isnt' is now ahead.

--anders

PS. Kris, I hope I got the suggestion right. At least the '==' part.

"Matthew" <admin.hat stlsoft.dot.org> writes:

"Anders F Björklund" <afb algonet.se> wrote in message
news:d3ijth$15bd$1 digitaldaemon.com...
 Matthew wrote:

Looks like the case FOR swapping == and is, has been established quite well!

Now let's hear it from the other side: do there exist _valid_ reasons for not
to swap them?

(With "valid" I mean other than whining about old code breaking.)

 Sorry, I must've missed that. Where is a good case for swapping made?

 The case FOR is where Kris notes that in his ported Java library,
 '===' (identity) is used more often than what '==' (equality) is.

 Therefore, D should treat references like Java does (i.e. like pointers)
 Since that would make it more compatible with Java, and with C pointers.

 Then, in a bizarre twist, 'is' should now be used to compare equality...
 (since it does work with primitives, as identity falls back to equality)

 In case it wasn't obvious already, I didn't agree with the new idea?
 But we still need a new operator for '!==', and 'isnt' is now ahead.

I don't go for it either, despite Kris's stats, because I think there's more
precedent for == being equality - 
C/C++/Java builtins, C++/Ruby objects - and there's precedent for 'is' being
identity in Python.

I think we need to cut a slice of pie that Walter'll swallow, and that's no
bigger than getting rid of === / !=== IMO. 

"Kris" <fu bar.com> writes:

"Anders F Björklund" <afb algonet.se> wrote in message
 Matthew wrote:

Looks like the case FOR swapping == and is, has been established
quite well!

Now let's hear it from the other side: do there exist _valid_
reasons for not to swap them?

(With "valid" I mean other than whining about old code breaking.)

 Sorry, I must've missed that. Where is a good case for swapping
 made?

 The case FOR is where Kris notes that in his ported Java library,
 '===' (identity) is used more often than what '==' (equality) is.

 Therefore, D should treat references like Java does (i.e. like pointers)
 Since that would make it more compatible with Java, and with C pointers.

 Then, in a bizarre twist, 'is' should now be used to compare equality...
 (since it does work with primitives, as identity falls back to equality)

 In case it wasn't obvious already, I didn't agree with the new idea?
 But we still need a new operator for '!==', and 'isnt' is now ahead.

 --anders

 PS. Kris, I hope I got the suggestion right. At least the '==' part.


That surely has to get the prize for the most misleading post ever made to
this NG ... if you had gone out of your way to deliberately misrepresent
virtually every aspect of the core topic, you probably could not have done a
more thorough job. Congratulations!

As a bonus, it's a vaguely amusing post too :-)

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

PS. Kris, I hope I got the suggestion right. At least the '==' part.

 
 That surely has to get the prize for the most misleading post ever made to
 this NG ... if you had gone out of your way to deliberately misrepresent
 virtually every aspect of the core topic, you probably could not have done a
 more thorough job. Congratulations!

Oh, that is something of an achievement considering the other posts.

I must admit that I wasn't trying to deliberately misrepresent your
post or opinions, just summarize as I had understood them. Seems like
I had missed what you were trying to say. Care to try again, then ?

Glad you found it amusing, at least.
--anders

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> writes:

Ding, Ding!

Kris, can you deobfuscate this topic with a summary of your points, 
as I'm now totally lost?

Thanks

Matthew

"Kris" <fu bar.com> wrote in message 
news:d3jogm$278a$1 digitaldaemon.com...
 "Anders F Björklund" <afb algonet.se> wrote in message
 Matthew wrote:

Looks like the case FOR swapping == and is, has been 
established
quite well!

Now let's hear it from the other side: do there exist _valid_
reasons for not to swap them?

(With "valid" I mean other than whining about old code 
breaking.)

 Sorry, I must've missed that. Where is a good case for swapping
 made?

 The case FOR is where Kris notes that in his ported Java library,
 '===' (identity) is used more often than what '==' (equality) is.

 Therefore, D should treat references like Java does (i.e. like 
 pointers)
 Since that would make it more compatible with Java, and with C 
 pointers.

 Then, in a bizarre twist, 'is' should now be used to compare 
 equality...
 (since it does work with primitives, as identity falls back to 
 equality)

 In case it wasn't obvious already, I didn't agree with the new 
 idea?
 But we still need a new operator for '!==', and 'isnt' is now 
 ahead.

 --anders

 PS. Kris, I hope I got the suggestion right. At least the '==' 
 part.


 That surely has to get the prize for the most misleading post ever 
 made to
 this NG ... if you had gone out of your way to deliberately 
 misrepresent
 virtually every aspect of the core topic, you probably could not 
 have done a
 more thorough job. Congratulations!

 As a bonus, it's a vaguely amusing post too :-)

 

"Kris" <fu bar.com> writes:

I did, Matthew. Two hours ago.

"Matthew" <admin stlsoft.dot.dot.dot.dot.org> wrote in message
news:d3kao0$2mu4$3 digitaldaemon.com...
 Ding, Ding!

 Kris, can you deobfuscate this topic with a summary of your points,
 as I'm now totally lost?

 Thanks

 Matthew

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

IMHO, Walter made a basic mistake when he followed Java's example of 
having clases be reference types rather than pointers.  I think that the 
'==' versus '===' issue is simply an outcome of that.

What I mean is, D should have been designed such that you would declare 
a class pointer/references like this:
	MyClass *foo;
rather than the current
	MyClass foo;
The difference is only one character, and yet it saves a massive amount 
of confusion, such as people (coming from C++) who don't expect the 
above to be a null reference.

More to the point, if D had required the pointer, then deep versus 
shallow compares would have been easy to differentiate:
	MyClass *foo;
	MyClass *bar;
	if(foo == bar) // compares pointers
	if(*foo == *bar) // compares value
(Yes, I know that there are always questions about *how* deep a deep 
compare should go...but that is not solved by the === operator, either.)

We wouldn't need an "is" operator if we had gone with the above syntax.

Kris wrote:
 Food for thought:
 
 Java is explicit about the distinction between equality and identity, just
 as D is. However, where D uses '==' as an equivalence operator, Java uses an
 equals() method. Where D uses (triple) '===' and 'is' for identity purposes,
 Java uses the traditional double '==' instead.
 
 So, what's that got to do with the price of tea in China?
 
 While porting 125,000 lines of Java to D, and an interesting thing happened.
 You'll perhaps not be surprised to hear Java identity style tests are far
 more prevalent than equivalence tests, but you may be surprised to know that
 the former comprised 98.75% of all explicit tests within those 125,000
 lines. To embellish, equals() was applied just 1.25% of the time.
 
 Please note that we're talking about high-quality Java code that makes
 extensive use of OO practices, and does indeed use equals() appropriately
 when doing class comparisons. It's just that there's relatively little call
 for that kind of thing once you get beyond writing sorting-algorithms,
 containers, and so on. What I'd classify as "user-level code" appears to
 apply equivalence testing rather seldom.
 
 The Java code was converted mechanically, so it was thankfully easy to
 change all identity tests into the D equivalent, which is the word 'is', or
 the triplet '==='. Likewise, the inversion was converted from '!=' to the D
 triplet '!=='. Each equals() instance was translated into the more
 traditional twin '==' equivalence operator.
 
 This has some notable ramifications; of which I'll attempt to be brief:
 
 1) The converted Java code now has reams of  'is' statements throughout the
 code, which makes it look 'interesting', to say the least. Quite nice,
 actually; and eminantly readable, even vaguely amusing at times. The '!=='
 instances look suitably alien by comparison. This amplifies the need for a
 sibling for the word 'is', such as the oft proposes 'not' or the colloquial
 'aint'.
 
 BTW, using 'is' generates optimal code for that 98.75% of tests within that
 large body of code. That is absolutely not the case when applying the
 traditional operators instead. Look at the emitted codegen.
 
 2) Anyone used to C or Java will habitually use the traditional '==' and
 '!=' all over their D code. This is actually the *wrong* thing to do, since
 those operators in D are for equivalence testing instead of identity
 testing. This has implications for both performance and for "expectations of
 behaviour". For example, the subsequent addition of an opEquals() to some
 aggregate may break the overall system in all manner of subtle and
 unexpected ways, where the original developer used '==' by force of habit.
 
 3) Just as importantly, this highlights a significant divergence of D from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many of
 you even use 'is' at all?
 
 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.
 
 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.
 
 D has effectively inverted that, and almost requires the adoption of a
 different, and somewhat confusing, idiom to do what has been tradition for a
 rather long time. The alternative is potentially error-prone code.
 
 There's ostensibly nothing wrong with change, but it's not clear what the
 benefit is here ~ if any?
 
 At the very least, one has to mentally shift gears to perform identity tests
 on classes and structs instead of native types. This would be OK if such
 things were in the minority, but they're not. In the case noted above, one
 has to continually shift gears for the overwhelming majority of tests.
 
 Those of you who avoid OO like the plague will likely not be bothered by
 such trivialities. For the rest, is it best to full embrace "is" and just
 stick with it?
 
 What sayeth ye?
 
 - Kris

=?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:

Kris wrote:

 3) Just as importantly, this highlights a significant divergence of D from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many of
 you even use 'is' at all?
 
 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.
 
 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.

(I meant to ask this earlier, but might as well ask it now...)


Did you mean for 'is' to be preferred only for class objects,
or did you feel that the default operator ('==') does the
"wrong thing" when it comes to the arrays and strings too ?
(since in Java, '==' compares the references there too - not
too surprising since they are both first-class Objects there)

As in: should one really be checking identity most of the time ?


All I know that in the Java that *I* have written, that's usually
not the case. It's pretty common to want to compare the contents ?
Like if I have two Integer "wrappers", and I want to compare them.
It's kinda confusing to learn that new Integer(1) != new Integer(1) ?

Or if you have two strings, that you must use string1.equals(string2)
just in case they have not allocated from the exact same string pool.
And when I have created two arrays, I cannot compare them either with
the normal '==' operator, but must instead call upon Array.equals() ?


The only thing that I thought to be confusing in D was that accidently
comparing something with null, causes a "NullPointerException"/segv...

(I still think it's the biggest trap in D for the Java programmer, since
calling opEquals an extra time is not as big as dereferencing null is ?)

That you now could compare objects, structs, arrays and strings with the
same == syntax as used for primitives - I thought that to be excellent ?

Especially when you could now use the related syntax of < <= >= > also,
for comparing two objects (assuming they are Comparable, of course...)


I'm not sure I would like to go back to the definition of '==' in Java.
(That treats primitive types in one way, and reference types in another)

As at least I *thought* that was what you were suggesting, either by
always using 'is' instead of '==' - or possibly even by a change to D ?

--anders

PS. I'm assuming that you like the equality for arrays and strings in D.
     (Since Java doesn't really have those "built-in", they are objects)

"TechnoZeus" <TechnoZeus PeoplePC.com> writes:

Well, I'll try to paraphrase it, as I understand it.  The problem is that there
is no way to state as an imutable fact exactly what "is" or "==" does without
having to first specify what they are being used to compare, other than that
they both compare for likeness.

In other words, we know what "is" and "==" have in common, and roughly what
that common functionality does, but we can't be sure of exactly how either one
goes about doing it even as a default, unless we have some idea what they are
doing it to.

For some things, like litteral numeric expressions for example, as they are
both comparing the value of those expressions, rather than the location that
the expressions are stored in.  (someone correct me if I'm wrong, because part
of this I am extrapolating from experience with other languages and assuming to
have been paralleled here based on the parts of this discussion that I have
read so far.)

For some things, like Objects for example, they are both comparing the
locations of the things rather than the contents of the things.

For some things, such as variables, for example, the "is" operator compares the
locations of the things, while the "==" operator compares the contents of the
things.

To make matters worse, this is just the "default" behavior, and can which it is
possible to override, and therefore can't always be trusted.

Of course, if should be possible to specify the unoverridden form, but doing so
all the time "just in case someone else over-rides the default" would be a real
bother.  Besides, it is even possible that the defaults could get changed.

Okay, I think that should about sum it up.  I did offer a solution a while
back... but it's probably lost in this thread by now.

TZ



"Anders F Björklund" <afb algonet.se> wrote in message
news:d3k43n$2hmb$1 digitaldaemon.com...
 Kris wrote:

 3) Just as importantly, this highlights a significant divergence of D from C
 and, IMO, in a rather fundamental manner. Think about this: you should
 actually be using 'is' most of the time instead of (twin) '=='. How many of
 you even use 'is' at all?

 One might perhaps argue the numbers above are artificially inflated since
 many of those test are applied to native types rather than to classes and
 structs ~ that may be true. But we're talking about something that's already
 well-developed as a habit in the community (the double '==') and we're
 talking about consistency in the majority case.

 I think D has perhaps made a serious blunder here. IMO, Java has the right
 approach by maintaining compatability for the vast majority of usage, whilst
 providing an option for testing "deep equivalence" via the equals() method
 for the remaining small percentage.

 (I meant to ask this earlier, but might as well ask it now...)


 Did you mean for 'is' to be preferred only for class objects,
 or did you feel that the default operator ('==') does the
 "wrong thing" when it comes to the arrays and strings too ?
 (since in Java, '==' compares the references there too - not
 too surprising since they are both first-class Objects there)

 As in: should one really be checking identity most of the time ?


 All I know that in the Java that *I* have written, that's usually
 not the case. It's pretty common to want to compare the contents ?
 Like if I have two Integer "wrappers", and I want to compare them.
 It's kinda confusing to learn that new Integer(1) != new Integer(1) ?

 Or if you have two strings, that you must use string1.equals(string2)
 just in case they have not allocated from the exact same string pool.
 And when I have created two arrays, I cannot compare them either with
 the normal '==' operator, but must instead call upon Array.equals() ?


 The only thing that I thought to be confusing in D was that accidently
 comparing something with null, causes a "NullPointerException"/segv...

 (I still think it's the biggest trap in D for the Java programmer, since
 calling opEquals an extra time is not as big as dereferencing null is ?)

 That you now could compare objects, structs, arrays and strings with the
 same == syntax as used for primitives - I thought that to be excellent ?

 Especially when you could now use the related syntax of < <= >= > also,
 for comparing two objects (assuming they are Comparable, of course...)


 I'm not sure I would like to go back to the definition of '==' in Java.
 (That treats primitive types in one way, and reference types in another)

 As at least I *thought* that was what you were suggesting, either by
 always using 'is' instead of '==' - or possibly even by a change to D ?

 --anders

 PS. I'm assuming that you like the equality for arrays and strings in D.
      (Since Java doesn't really have those "built-in", they are objects)