January 21, 2005
John Reimer wrote:
> Georg Wrede wrote:
> 
>> I ignored it, since the main point was kind of obvious.  :-)
>>
>> In my mother tongue "at most" is just one word, as is "at least". My gripe is actually the pronunciation of "<=" as "less than or equal to", in all spoken languages. It sounds clumsy and overly technical, especially as it refers to a single operator, or concept, more than a combination of two.
>>
>> Back to the original point, I like "isnt". It should be perfectly ok since nobody seems to have a problem with "endif". We might use "isnot", but "isnt" feels nicer.
> 
> 
> As an English speaker, "isnt" feels very informal.  I doesn't (!) quite feel correct to use informal English contractions in a computer language.

Heh, obviously I meant to say "It doesn't."
January 21, 2005
John Reimer wrote:

>> As an English speaker, "isnt" feels very informal.  I doesn't (!) quite feel correct to use informal English contractions in a computer language.
> 
> Heh, obviously I meant to say "It doesn't."

Or: "Not that I do", as in current D syntax. :-)

(p isnot null) => (!(p is null))

--anders

PS. I take it that's another one against "aint" ?
January 21, 2005
Anders F Björklund wrote:

> 
> Or: "Not that I do", as in current D syntax. :-)
> 
> (p isnot null) => (!(p is null))
> 
> --anders
> 
> PS. I take it that's another one against "aint" ?

Heh, "aint" just doesn't cut it. :-)
January 21, 2005
John Reimer wrote:

>> PS. I take it that's another one against "aint" ?
> 
> Heh, "aint" just doesn't cut it. :-)

The two most likely outcomes are "isnot", or nothing.

I mean, since "(p)" works and booleans are unwanted,
then shortening "(!(p is null))" is not a priority ?

Hopefully, "===" and "!==" will continue to work
when using the "-d" flag (for deprecated features)...

--anders
January 21, 2005
Anders F Björklund wrote:
> John Reimer wrote:
> 
>>> PS. I take it that's another one against "aint" ?
>>
>>
>> Heh, "aint" just doesn't cut it. :-)
> 
> 
> The two most likely outcomes are "isnot", or nothing.
> 
> I mean, since "(p)" works and booleans are unwanted,
> then shortening "(!(p is null))" is not a priority ?
> 
> Hopefully, "===" and "!==" will continue to work
> when using the "-d" flag (for deprecated features)...
> 
> --anders

If it is anything, then "isnot" it is; otherwise "nothing" is it. :-)

- John
January 21, 2005
Anders F Björklund wrote:
> Georg Wrede wrote:
> 
>> We should start using a word for >= and <=, too.
> 
> But if you really like some new words, then I suggest ≥ and ≤ ?

I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is" and the proposed "isnt". After all I suspect D 2.0 will struggle with all the english based keywords in the future since Unicode support really suggests supporting multiple languages.
January 21, 2005
parabolis wrote:

>> But if you really like some new words, then I suggest ≥ and ≤ ?
> 
> I absolutely agree with this suggestion. I would further it by suggesting "≡≡" and "!≡" replace the current "is"

No, not replace. As an *alternative* to the US-ASCII syntax.
And that should be ≡ for '===', and ≢ for '!==' by the way.

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

--anders
January 21, 2005
My example was C code, I was making a point which
everybody here probably already knows (sorry for any confusion)
as a step towards my real point that typenames in D don't
need to be reserved words. Precisely because the D language,
unlike C/C++, does *not* need them to be so in order to direct parsing.
And making too many things keywords has some bad side-effects.


In article <csq0ml$1nh8$1@digitaldaemon.com>, parabolis says...
>agent.smith@archvillain.com wrote:
>> typedef float foo;
>> a= (foo)(i);   /* a cast */
>> b= (bar)(i);   /* a function call */>Check the D spec on casting. Especially Unary Expressions:
>http://www.digitalmars.com/d/expression.html#UnaryExpression
>
>So the above should be:
>----------------------------------------------------------------
>   a= cast(foo)(i);   /* a cast */
>   b= (bar)(i);       /* a function call */
>----------------------------------------------------------------


January 21, 2005
> Hopefully, "===" and "!==" will continue to work
> when using the "-d" flag (for deprecated features)...

They shouldn't be supported. Walter'd better add a hint to the error messages which they'll generate when they are removed.

old.d(25): I did not expect another = after == (did you mean "is"?)
old.d(26): either use != or == but not both (did you mean "isnot"?)

L.


January 21, 2005
In article <csq18r$1o7t$1@digitaldaemon.com>, Kris says...
>In article <csps3e$1jcu$1@digitaldaemon.com>, agent.smith@archvillain.com says...
> Unfortunately, you cannot have a variable called 'length' in D.
>Well ... you can ... but there's that sneaky issue where you can't use it within an array reference:
>
># int length = 0;
># char x[], y[20];
>#
># // what do you think will happen here?
># x = y[0 .. length];
>
>Believe it or not, 'length' is a pseudo-reserved keyword when used in this manner (within the braces), although the compiler says nothing about the 'collision'.
>
Really? but I'm not allowed to do this in D:
myfunc() { int x; ...  { int x; ... } ... }
.. shouldn't the same philosophy make your example an error?
That would be a Good Thing, IMHO. I.e. I can use 'length' if
I want, but the compiler will keep me from loading it and pointing
it at my foot. I can still do x.length. So somebody wanting to
add the last statement to my code later would either have to add

int ylength= y.length;
x = y[ 0..ylength];

or

int tlength = length;
x = y[ 0..tlength];

.. whilst cursing me in the comments. or just s/length/len/ first.

I'm not so sure that this should be disallowed:

myfunc() { {int x; ...}  { int x; ... } ... }

I've an awful lot of C++ code where ...
for( int irow=0; irow < h ; irow ++ )...
.. appears several times in a function, and I'm less convinced that's
dangerous. I'm making it explicit that these are independent uses of the
same conceptual variable; in D i'd have to give each one a different
name, or make them all the same variable, neither of which accomplishes this.

Another issue:  years ago I read something on a language newsgroup which really
surprised me... that every Pascal 'with .. do' was a bug waiting to happen; but
the author was right; what is even more scary is that the exact same issue
exists in  every C++ member func; these inherit scopes in basically the same way
as a with ..do.  It's actually worse in C++, because of class inheritance.
This problem, which could result in bugs that take days to find, is
commonly avoided by lexical conventions (e.g. starting member names with m_).

Here's the problem in C++:
----
static int table[] = {1,2,3};

int MyClass::memberfunc(int i)
{
return table[i];
}
---
OK. Now imagine 'MyClass' is based on 'JoesClass', and next week Joe
adds a member 'table' to his function. My memberfunc() function will now
reference that member variable instead of the static local! If I'm really
lucky, I'll get a compile error, if not, I'll get different runtime behaviour,
despite the fact that I didn't touch my code, and Joe's change was done in
such a way as not to change the existing class interface (other than by
adding this name...) This could take ages to figure out. The reason
this doesn't happen much is because most variable naming conventions
avoid it (e.g m_); but I suspect few programmers realize that this can happen.
I only realized recently that the Pascal problem applies to C++ too.

This can be avoided, of course, by putting :: in front of table, but that's a lot of ::'s to use. Some languages (e.g. Python) require explicit this->, (or self.) which is also rather a pain, but at least avoids this problem.

Is there is a similar issue in D? Fundamentally, the problem is that
a name introduced into a distant scope (inherited class) can hide a variable
in a scope which is in some sense much closer (file scope of the function);
it can be argued that the derived class and the file scope are under control
of the author of the derived class, whereas the base class is not; and therefore
this should not work this way. Maybe it's even more dangerous, somehow,
to insert the file scope between the base class and derived class.

In any case, it seems to me that this is a detectable case of ambiguity, and it's not unreasonable to flag it as such, and require the :: to be used. The problem will also be avoided if Joe's member 'table' is private. It might not compile, but that's better than compiling with the wrong meaning.

I apologize for not stating this in D terms, and I apologize profusely if
this is discussed in the D docs somewhere, but I haven't had time to read
it all yet... will do so before further ramblings..
I did see just now that there is a with(){ } in D, which may suffer from the
same problem, but this time accidentally hiding local vars instead of
file-scope? This is more dangerous, if only because naming conventions are much
less likely to protect you.