January 21, 2005
Vathix wrote:
> On Thu, 20 Jan 2005 23:50:43 +0100, Anders F Björklund <afb@algonet.se>  wrote:
> 
>> Paul Bonser wrote:
>>
>>> I must have had a good English teacher in high school, because such  things pain me. (As well as its-it's their-there-they're to-too and a  lot (the only proper way is a lot, two separate words, not one)...but I  guess I'm a bit obsessive compulsive, too...)
>>
>>
>> I guess you're not in favor of an "aint" keyword then ? :-)
>>
>> Or maybe it should use "p is not null", just like in SQL...
>>
>> Oh, well: !(p is null)
>>
>> --anders
> 
> 
> I like the previously mentioned "p !is null". Would also work with "in",  "key !in aa".

I'm not actually opposed to using isnt, I'd just have a hard time for a while typing it without the "'"...isnot would work, too.

-PIB
January 21, 2005
Georg Wrede wrote:
> Anders F Björklund wrote:
>>
>> I still think that we need 'isnt' for '!=='
> 
> We should start using a word for >= and <=, too.
> 
> There are perfect words for them in non-computer literature, and in the spoken language as well. They are "at least" and "at most", respectively.

I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form.


> Reading "greater than or equal to" instead of "at least" is like reading "!==" as "Bang equal equal".

Reading ">=" as "greater than equal" is analogous to "bang equal equal."

Reading ">=" as "greater than *or* equal *to*" is like reading "!==" as "is not equivalent to."
January 21, 2005
>I'm not actually opposed to using isnt, I'd just have a hard time for a while typing it without the "'"...isnot would work, too.

Microsoft has applied to patent the IsNot operator. I have the link somewhere.
Amusing as that is, I have another point. I just recently encountered
the D language (Dr Dobbs article got me here) and I really really
like what I see. I could go on about why, but it's all the same
reasons that are in the D blurb.

I have one issue though - is anyone concerned about having too many keywords in the language ? There's a long list of them, and more than 20 are types. And discussion of adding more.

So I'm thinking, one of the goals of D is to eliminate the interdependence
between compiler passes. My understanding of the issue is this:
in order to parse C or C++, you need feedback from the symbol table
to the lexer. The two assignments below have different grammatic
composition, but you can't know that unless you know that 'foo'
is a type name and 'bar' is not:

typdef float foo;
a= (foo)(i);   /* a cast */
b= (bar)(i);   /* a function call */

This really stinks, and one of the stated goals of D is to eliminate this problem by adjusting the grammar. Great! So, given that, is there any reason why int, uint, wchar, ubyte and all those guys need to be keywords? In many languages, type names are predefined identifiers.

For instance, Python, Pascal, VHDL, and, I think, Ada (python doesn't have type declarations in any form, so that hardly counts, but it does have predefined variables for type objects).

In fact, 'true' and 'false' could be predefined identifiers corresponding to constants of type bit. Two more keywords down.

Of course, you could argue that they should be keywords not because
they *need* to be, but because redefining them would be a Bad Thing,
and can't ever be useful.
The problem is, if a new type is added in the future, it *should*
be added as an identifier, so that it won't mess up existing code
where the same name is used as a local variable, or struct member
name, for instance. So why not start as you mean to go on, so
that the langauge definition stays consistent.

Years ago I was helping someone move some code from C to C++; we couldn't
understand how a struct decl would work in C and fail in C++, until
we noticed a member named 'this'. Now, really, C++ 'this' is conceptually
a local variable, and struct member names are in a separate space,
so given a different implementation of C++, it would have worked. But
you make something a keyword, you reserve its meaning in all possible
contexts. Like #define.  #define is not in D, because
it's ugly, but mainly because defining meaning to a word regardless of
context is a Bad Thing, so why not extend the same argument to
keywords that don't really need to be keywords? In C++, 'this'
didn't need to be a keyword, it could be an implicitly declared
const pointer parameter in all member funcs. One less keyword, and
it wouldn't have broken that C code (hey, that could probably
work for D too).

In D, the properties (like int.max, array.length, double.nan, x.size) are not keywords, and they shouldn't be - otherwise you couldn't have a variable called 'length'. I think this philosophy could extend to type names too.

I have kind of a vague bias against too many keywords. My
favorite language, Python, has relatively few keywords.
It forms some operatore using pairs of keywords like
'is not' and 'not in', eliminating the need
for extra keywords - I can't see any reason not to do this, as
long as is doesn't break the grammar ('is not' barely works
in python - the alternate interpretation "a is (not b)"
*is* legal, but useless in practice)

Conversely, one of the most awful languages I've used --
Dec PDP11 compiled BASIC (for RSTS or something) -- had four full
manual pages listing the reserved words, including pretty
much any word that had anything do with computers or data
processing. So you had to write your code with everything spelled
wrong, as in REKORD=REKORD+1.



January 21, 2005
agent.smith@archvillain.com wrote:

> to the lexer. The two assignments below have different grammatic
> composition, but you can't know that unless you know that 'foo'
> is a type name and 'bar' is not:
> 
> typdef 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
In article <csps3e$1jcu$1@digitaldaemon.com>, agent.smith@archvillain.com says...
>In D, the properties (like int.max, array.length, double.nan, x.size) are not keywords, and they shouldn't be - otherwise you couldn't have a variable called 'length'. I think this philosophy could extend to type names too.

Good points. 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'.

This is one of several insideously sneaky things that have been introduced to D recently -- an overload of a rather common variable name, /particularly/ so when used with arrays. It's a great way to piss-off both novices and experts alike

- Kris


January 21, 2005
<agent.smith@archvillain.com> wrote in message news:csps3e$1jcu$1@digitaldaemon.com...
>
> [...]

I totally agree with you. So much in fact, that I refer to a thread I started a month or so ago:

http://www.digitalmars.com/d/archives/digitalmars/D/12260.html

Lionello.


January 21, 2005
agent.smith@archvillain.com wrote:

> For instance, Python, Pascal, VHDL, and, I think, Ada (python
> doesn't have type declarations in any form, so that hardly counts,
> but it does have predefined variables for type objects).

You should try Perl then, for a refreshing look on operators and vars :)

> In fact, 'true' and 'false' could be predefined identifiers corresponding
> to constants of type bit. Two more keywords down.

They already are, if you look at the code. But I would rather add bool.

--anders
January 21, 2005
Georg Wrede wrote:

> We should start using a word for >= and <=, too.

No, those relate to the equality comparisons, not the identity.

The identity comparators need a word to separate them from equality,
since people were confusing '==' and '===' as well as '!=' and '!=='

But if you really like some new words, then I suggest ≥ and ≤ ?
Might as well put all that Unicode UTF-8 to some use, right :-) (☺)

But "is" and "in" are plenty. Perhaps "is!" and "!in" could work.

--anders
January 21, 2005
>>> I still think that we need 'isnt' for '!=='
>>
> I think you missed the larger point that "isnt" is better than nothing which is what we have since "is not" is not a single word. The phrases "at least" and "at most" suffer from the same problem that keeps "is not" from being possible while lacking a contractable form.

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.
January 21, 2005
Georg Wrede wrote:

> 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.

Do you actually read your programs out loud ? Haven't done that since
I went to school and had program (implement) the whole thing on paper.

But maybe I should get the speech synthesizer to read my D code now...
That would be good for a laugh or two, I think. (wonder where it's at)

--anders

PS: Being an assembly and Perl nerd, I just think "le" :-)
http://www.perldoc.com/perl5.8.0/pod/perlop.html#Relational-Operators