On Wed, 21 Jul 2004 09:08:34 +0000, Matthias Becker wrote:

> 
> INT fac (INT x)
> {
> IF (x <= 1)
> RETURN 1;
> ELSE
> RETURN x * fac(x - 1);
> }
> }
> 

Heh.  Looks kinda like BASIC.

"Arcane Jill" <Arcane_member@pathlink.com> wrote in message news:cdifjr$15hj$1@digitaldaemon.com...
> In article <cdiemi$157f$1@digitaldaemon.com>, Tom Popovich says...
>
> >Maybe we could say :  reserved words can be either lower or uppercase allowing for this style
>
> Well that would seriously bugger up my class Int.
>
> Arcane Jill
>

Even worse, Windows' LONG is an int in D...

Like Modula-2.
I really like Modula-2 and this is the only thing I really dislike about the
language.

This will not happen.

GG.

"Tom Popovich" <Tom_member@pathlink.com> wrote in message news:cdiemi$157f$1@digitaldaemon.com...
> I'd also like to throw out a thought...
>
> Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
> a nice style (upper vs lower) like this
>
> SELECT  name, id, addr
> FROM  emp, ...
> WHERE  ...;
> -----------
> UPPER-lower style: all reserved words are written in UPPER- CASE and all application names are kept in lowercase:
>
> IF TO_NUMBER(the_value) > 22   AND
> num1 BETWEEN lval AND hval
> THEN
> newval := 100;
> ELSIF TO_NUMBER (the_valuue) < 1...
>
> --vs--
> if to_number(the_value)>22 and
> num1 between lval and hval
> then
> newval := 100;
> elsif to_number(the_value) < 1...
>
>
> e.g another example: the shell loop could be:
> FOR  i IN ....
> DO
> echo $i
> DONE
>
>
>
>
> Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for
keywords  it
> allows your
> eye to scan it easily since you can skip/pattern match them.
>
> Maybe we could say :  reserved words can be either lower or uppercase allowing for this style
>
> --------------------------------
> int foo( IN int x, INOUT int y ) { ... }
> -vs-
> int foo( in int x, inout int y ) { ... }
> --------------------------------
>
> or in one of your examples:
> --------------------------------
> int foo(int x, OUT int y, INOUT int z, int q);
> -vs-
> int foo(int x, out int y, inout int z, int q);
> --------------------------------
> that way the IN/OUT... can be easily scanned.
>
>
> In my C++/C coding, since OUT params can be "hidden"
> I always use a ugly
> /*OUT*/ in the decl stmts (out of convention).
>
>

Tom Popovich wrote:

>I'd also like to throw out a thought...
>
>Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
>a nice style (upper vs lower) like this
>
>SELECT  name, id, addr
>FROM  emp, ...
>WHERE  ...;
>-----------
>UPPER-lower style: all reserved words are written in UPPER-
>CASE and all application names are kept in lowercase:
>
>IF TO_NUMBER(the_value) > 22   AND
>num1 BETWEEN lval AND hval
>THEN
>newval := 100;
>ELSIF TO_NUMBER (the_valuue) < 1...
>
>--vs--
>if to_number(the_value)>22 and
>num1 between lval and hval
>then
>newval := 100;
>elsif to_number(the_value) < 1...
>
>
>e.g another example: the shell loop could be:
>FOR  i IN ....
>DO
>echo $i
>DONE
>
>
>
>
>Oracle sql/plsql is case-insensitve.  So by choosing UPPERCASE for keywords  it
>allows your
>eye to scan it easily since you can skip/pattern match them.
>
>Maybe we could say :  reserved words can be either lower or uppercase
>allowing for this style
>
>--------------------------------
>int foo( IN int x, INOUT int y ) { ... }
>-vs-
>int foo( in int x, inout int y ) { ... }
>--------------------------------
>
>or in one of your examples:
>--------------------------------
>int foo(int x, OUT int y, INOUT int z, int q);
>-vs-
>int foo(int x, out int y, inout int z, int q);
>--------------------------------
>that way the IN/OUT... can be easily scanned.
>
>
>In my C++/C coding, since OUT params can be "hidden"
>I always use a ugly
>/*OUT*/ in the decl stmts (out of convention).
>
>
>  
>
Personally, I don't like holding now shift for more then one letter when typing fluently because you halve the productivity (as your only typing with one hand).   Caps lock is even worse.  Also uppercase is harder for me to read as I'm less used to it and have to switch neurons in my brain (like most people), which makes it harder to read code like reading a book. 

http://en.wikipedia.org/wiki/Uppercase_letter
http://www.omegalegal.com/Articles/StopAllCaps.htm

-- 
-Anderson: http://badmama.com.au/~anderson/

In article <cdlocd$2lmo$1@digitaldaemon.com>, J Anderson says...
>
>Tom Popovich wrote:
>
>>I'd also like to throw out a thought...
>>
>>Ever see some oracle plsql code?  A key author (Steven Feuerstein) defined
>>a nice style (upper vs lower) like this
>
>Personally, I don't like holding now shift for more then one letter when typing fluently because you halve the productivity (as your only typing with one hand).   Caps lock is even worse.  Also uppercase is harder for me to read as I'm less used to it and have to switch neurons in my brain (like most people), which makes it harder to read code like reading a book.

For sql syntax the caps work just fine, but with c-style format they don't look nice. Many formatting guidelines suggest that all-caps are used for constants. The one for D language tells the same.

Personally I'm used to see the reserved words in different colors/formatting in the editor, so that they are more easily distinguished.

What comes to the typing speed I don't see any problem in typing all-caps words. I rest my index finger (or whatever the last finger counting on the thumb is called... can't remember :) on the shift all the time. So typing speed doesn't certainly get halved.

Sampsa Lehtonen

Just consider the repercussions of any existing software.  For example, there is an "Int" class, since Int would be the same as "int" if the
case were suddenly not to matter--it would cause the entire class to be renamed.

Also consider distinguishing between constants and keywords if someone were to do the all caps thing.

I personally am not a fan of the idea.

SQL has its place, but it is also ALL case insensitive.  That means that the user has the option to have the keywords all upper case, or the column and table names all upper case, or everything in one case.  What ends up happening is that unless the SQL is maintained by one person or a tool, different ideas creep in and one part has different capitalization policies in the same file.  Not pretty.

Since D seems to favor encouraging good practices, why change the capitalization policy at this point?

There are repercussions of changing the case now and later.  Now we would have to deal with software that used to compile not compiling after the change due to variable and class name conflicts.  In the future we will have to deal with software not compiling because one maintainer used title case for the keywords, another used all caps, and yet another used all lower case in the same file.

The cost of even experimenting with this in the D language would be too high IMO.