www.digitalmars.com         C & C++   DMDScript  

D - First impressions

reply John English <je brighton.ac.uk> writes:
I've only read the first few sections of the manual, but I noticed a
few things in the lexical grammar already:
1) the grammar for hex constants contains a misprint (0b instead of
   0x)
2) the grammar for HexadecimalH constants looks ambiguous as is:
   it implies that the word "each" could be interpreted as a valid
   hexadecimal contant (same as 0xEAC)
3) the grammar shows h or H as valid suffixes for HexadecimalH, but
   not prefixes 0B or 0X... is this intentional?
4) A nice addition to the list of escape characters would be \e for
   ESC.

Also, re (3) above, can I make a plea for case insensitivity throughout?
Students that I teach Java to waste an awful lot of their time dealing
with spelling mistakes: they write RunTimeException instead of
RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
analogy with Hashtable) instead of HashMap... What possible benefit
do you get from case sensitivity? Why do you want to be able to
distinguish between String and string and STRING, which any native
English speaker would regard as different representations of the
same word...

-----------------------------------------------------------------
 John English              | mailto:je brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------
May 02 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"John English" <je brighton.ac.uk> wrote in message
news:3CD1479A.91A6CBDC brighton.ac.uk...
 I've only read the first few sections of the manual, but I noticed a
 few things in the lexical grammar already:
 1) the grammar for hex constants contains a misprint (0b instead of
    0x)
 2) the grammar for HexadecimalH constants looks ambiguous as is:
    it implies that the word "each" could be interpreted as a valid
    hexadecimal contant (same as 0xEAC)
 3) the grammar shows h or H as valid suffixes for HexadecimalH, but
    not prefixes 0B or 0X... is this intentional?
 4) A nice addition to the list of escape characters would be \e for
    ESC.

Thanks, I'll go back through the documentation.
 Also, re (3) above, can I make a plea for case insensitivity throughout?
 Students that I teach Java to waste an awful lot of their time dealing
 with spelling mistakes: they write RunTimeException instead of
 RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
 analogy with Hashtable) instead of HashMap... What possible benefit
 do you get from case sensitivity? Why do you want to be able to
 distinguish between String and string and STRING, which any native
 English speaker would regard as different representations of the
 same word...

D is case sensitive because C is <g>. But seriously, this is one of those no-win topics like brace indenting styles. If D was a pascal successor, it would be case insensitive, but since it is in the tradition of C like languages (and can interface directly to C), it is case sensitive.
May 02 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Walter" <walter digitalmars.com> wrote in message
news:aarmn9$1eip$4 digitaldaemon.com...

 2) the grammar for HexadecimalH constants looks ambiguous as is:
    it implies that the word "each" could be interpreted as a valid
    hexadecimal contant (same as 0xEAC)


Nope. It's just like asm - if it starts with a letter, it's an identifier (so "each" is an identifier). Only if it starts with a digit, it is a number (so "0each" is a hex number 0xEAC).
 4) A nice addition to the list of escape characters would be \e for
    ESC.


Yep, a nice one for those guys working directly with UNIX terminals...
May 02 2002
parent John English <je brighton.ac.uk> writes:
Pavel Minayev wrote:
 
 "Walter" <walter digitalmars.com> wrote in message
 news:aarmn9$1eip$4 digitaldaemon.com...

Actually, it was me...
 2) the grammar for HexadecimalH constants looks ambiguous as is:
    it implies that the word "each" could be interpreted as a valid
    hexadecimal contant (same as 0xEAC)


Nope. It's just like asm - if it starts with a letter, it's an identifier (so "each" is an identifier). Only if it starts with a digit, it is a number (so "0each" is a hex number 0xEAC).

Yes, I assumed that was what it would mean -- it's just that it isn't what it says at the moment, and I was just trying to point out an ambiguity... ----------------------------------------------------------------- John English | mailto:je brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk -----------------------------------------------------------------
May 03 2002
prev sibling parent reply "anderson" <anderson firestar.com.au> writes:
You probably won't read this (stuck in the middle of this old email), but my
suggestion would be to put case-senstivity in the error message as some ada
versions did. When a variable/functions definion is not found, suggest an
alternative in the error message.

ie
"Variable not found. Did you mean ...."

I found that quite helpful, and a smart IDE could take this further.

"Walter" <walter digitalmars.com> wrote in message
news:aarmn9$1eip$4 digitaldaemon.com...
 "John English" <je brighton.ac.uk> wrote in message
 news:3CD1479A.91A6CBDC brighton.ac.uk...
 I've only read the first few sections of the manual, but I noticed a
 few things in the lexical grammar already:
 1) the grammar for hex constants contains a misprint (0b instead of
    0x)
 2) the grammar for HexadecimalH constants looks ambiguous as is:
    it implies that the word "each" could be interpreted as a valid
    hexadecimal contant (same as 0xEAC)
 3) the grammar shows h or H as valid suffixes for HexadecimalH, but
    not prefixes 0B or 0X... is this intentional?
 4) A nice addition to the list of escape characters would be \e for
    ESC.

Thanks, I'll go back through the documentation.
 Also, re (3) above, can I make a plea for case insensitivity throughout?
 Students that I teach Java to waste an awful lot of their time dealing
 with spelling mistakes: they write RunTimeException instead of
 RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
 analogy with Hashtable) instead of HashMap... What possible benefit
 do you get from case sensitivity? Why do you want to be able to
 distinguish between String and string and STRING, which any native
 English speaker would regard as different representations of the
 same word...

D is case sensitive because C is <g>. But seriously, this is one of those no-win topics like brace indenting styles. If D was a pascal successor, it would be case insensitive, but since it is in the tradition of C like languages (and can interface directly to C), it is case sensitive.

May 20 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:acaui6$f8v$1 digitaldaemon.com...

 You probably won't read this (stuck in the middle of this old email), but

 suggestion would be to put case-senstivity in the error message as some

 versions did. When a variable/functions definion is not found, suggest an
 alternative in the error message.

 ie
 "Variable not found. Did you mean ...."

 I found that quite helpful, and a smart IDE could take this further.

A good idea, it is. As for the IDE, well, Visual Assist successfully fixes such errors on the fly, as you type identifiers in the editor. So cwindow becomes CWindow, etc
May 20 2002
parent reply "anderson" <anderson firestar.com.au> writes:
What about the extreme cases where there are 2 or more declarations of
differn't case for the same name? Does it give you an option or warning?

"Pavel Minayev" <evilone omen.ru> wrote in message
news:acb3pj$kf2$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:acaui6$f8v$1 digitaldaemon.com...

 You probably won't read this (stuck in the middle of this old email),


 my
 suggestion would be to put case-senstivity in the error message as some

 versions did. When a variable/functions definion is not found, suggest


 alternative in the error message.

 ie
 "Variable not found. Did you mean ...."

 I found that quite helpful, and a smart IDE could take this further.

A good idea, it is. As for the IDE, well, Visual Assist successfully fixes such errors on the fly, as you type identifiers in the editor. So cwindow becomes CWindow, etc

May 20 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"anderson" <anderson firestar.com.au> wrote in message
news:accfii$1rme$1 digitaldaemon.com...

 What about the extreme cases where there are 2 or more declarations of
 differn't case for the same name? Does it give you an option or warning?

The compiler (MSVC) doesn't. The IDE just don't do any automatic fixes in such a case. Also, you really shouldn't propose Walter to add warnings - he hates 'em. =)
May 20 2002
parent "anderson" <anderson firestar.com.au> writes:
Sorry, I was talking about the IDE Visual Assist , and it wasn't a proposal,
it was a question. I know VB does something simular, but it's
case-insentitive to start with.

"Pavel Minayev" <evilone omen.ru> wrote in message
news:accfsn$1rq9$1 digitaldaemon.com...
 "anderson" <anderson firestar.com.au> wrote in message
 news:accfii$1rme$1 digitaldaemon.com...

 What about the extreme cases where there are 2 or more declarations of
 differn't case for the same name? Does it give you an option or warning?

The compiler (MSVC) doesn't. The IDE just don't do any automatic fixes in such a case. Also, you really shouldn't propose Walter to add warnings - he hates 'em.


May 20 2002
prev sibling next sibling parent reply "Richard Krehbiel" <rich kastle.com> writes:
"John English" <je brighton.ac.uk> wrote in message
news:3CD1479A.91A6CBDC brighton.ac.uk...
 [...]
 3) the grammar shows h or H as valid suffixes for HexadecimalH, but
    not prefixes 0B or 0X... is this intentional?
 [...]
 Also, re (3) above, can I make a plea for case insensitivity throughout?
 Students that I teach Java to waste an awful lot of their time dealing
 with spelling mistakes: they write RunTimeException instead of
 RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
 analogy with Hashtable) instead of HashMap... What possible benefit
 do you get from case sensitivity? Why do you want to be able to
 distinguish between String and string and STRING, which any native
 English speaker would regard as different representations of the
 same word...

Seconded (though I suspect the D implementation and underway are advanced to the point of no return). I can think of no reason for D to remain case-sensitive save the need to be link-compatible with C. Although the ANSI/ISO standard states that external identifiers need not be case sensitive, it's possible that some arbitrary C library might contain the same name with only a letter-case distinction, in which case D needs case-sensitivity to be able to resolve these. I suspect this is rare enough that it might be reasonable to require stubbly little C functions be written to resolve the difference, but even if not, D could make the rule that extern(C) identifiers are case-sensitive but D identifiers are not. -- Richard Krehbiel, Arlington, VA, USA rich kastle.com (work) or krehbiel3 comcast.net (personal)
May 02 2002
parent reply "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Richard Krehbiel" <rich kastle.com> wrote in message
news:aarn3p$1fp5$1 digitaldaemon.com...
 "John English" <je brighton.ac.uk> wrote in message
 news:3CD1479A.91A6CBDC brighton.ac.uk...
 [...]
 3) the grammar shows h or H as valid suffixes for HexadecimalH, but
    not prefixes 0B or 0X... is this intentional?
 [...]
 Also, re (3) above, can I make a plea for case insensitivity throughout?
 Students that I teach Java to waste an awful lot of their time dealing
 with spelling mistakes: they write RunTimeException instead of
 RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
 analogy with Hashtable) instead of HashMap... What possible benefit
 do you get from case sensitivity? Why do you want to be able to
 distinguish between String and string and STRING, which any native
 English speaker would regard as different representations of the
 same word...

Seconded (though I suspect the D implementation and underway are advanced

 the point of no return).

 I can think of no reason for D to remain case-sensitive save the need to

 link-compatible with C.  Although the ANSI/ISO standard states that

 identifiers need not be case sensitive, it's possible that some arbitrary

 library might contain the same name with only a letter-case distinction,

 which case D needs case-sensitivity to be able to resolve these.  I

 this is rare enough that it might be reasonable to require stubbly little

 functions be written to resolve the difference, but even if not, D could
 make the rule that extern(C) identifiers are case-sensitive but D
 identifiers are not.

I am far from a language guru (though by reading here, I am learning about some of the issues - thanks to everyone), but I have some, perhaps dumb, questions. Some time ago, someone here suggested a scheme (I'm sorry, I can't remember the name) where identifiers were once you defined an identifier, any attempt to use an identifier that was the same letters but different cases was an error. Doesn't this solve the huge screw-up potential of case sensitivity (multiple different identifiers that should really be the same) while fixing the arbitraryness of allowing full case insensitivityness? It seems like a good compromise. It seems another possibility is to make case sensitivity or not for all internal names something like a compile time pragma. That is, a user could use whichever he wanted, as long as it was clearly specified in the source code. Of course, organizations could set easily enforced standards for their programmers. The overhead in the compiler should be minimal What am I missing? -- - Stephen Fuld e-mail address disguised to prevent spam
May 03 2002
parent reply "Richard Krehbiel" <rich kastle.com> writes:
"Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
news:aaube8$2b3e$1 digitaldaemon.com...
 "Richard Krehbiel" <rich kastle.com> wrote in message
 news:aarn3p$1fp5$1 digitaldaemon.com...
 Seconded (though I suspect the D implementation and underway are


 to
 the point of no return).

be link-compatible with C. Although the ANSI/ISO standard states that external identifiers need not be case sensitive, it's possible that some


 C
 library might contain the same name with only a letter-case distinction,
 in
 which case D needs case-sensitivity to be able to resolve these.  I
 suspect
 this is rare enough that it might be reasonable to require stubbly


 C
 functions be written to resolve the difference, but even if not, D could
 make the rule that extern(C) identifiers are case-sensitive but D
 identifiers are not.

I am far from a language guru (though by reading here, I am learning about some of the issues - thanks to everyone), but I have some, perhaps dumb, questions. Some time ago, someone here suggested a scheme (I'm sorry, I can't remember the name) where identifiers were once you defined an identifier, any attempt to use an identifier that was the same letters but different cases was an error. Doesn't this solve the huge screw-up potential of case sensitivity (multiple different identifiers that should really be the same) while fixing the arbitraryness of allowing full case insensitivityness? It seems like a good compromise.

I remember that one; the suggestion would have these effects: int MixedCaseName; MixedcaseName = MixedcaseName + 1; ***ERROR: no such identifier 'MixedupName' So far, it looks case-sensitive. int MixedUpName; int mixedupName; ***ERROR: differs from 'MixedCaseName' in letter case only. ...but this is remarkable. It's case-sensitive because you can't use an identifier except by exact match. It's case-insensitive because it rejects the declaration of a variable spelled the same but with different letter case. I personally would rather not have a schizoid compiler.
May 03 2002
parent "Stephen Fuld" <s.fuld.pleaseremove att.net> writes:
"Richard Krehbiel" <rich kastle.com> wrote in message
news:aaucs7$2cdl$1 digitaldaemon.com...
 "Stephen Fuld" <s.fuld.pleaseremove att.net> wrote in message
 news:aaube8$2b3e$1 digitaldaemon.com...
 "Richard Krehbiel" <rich kastle.com> wrote in message
 news:aarn3p$1fp5$1 digitaldaemon.com...
 Seconded (though I suspect the D implementation and underway are


 to
 the point of no return).




 be
 link-compatible with C.  Although the ANSI/ISO standard states that
 external
 identifiers need not be case sensitive, it's possible that some


 C
 library might contain the same name with only a letter-case



 in
 which case D needs case-sensitivity to be able to resolve these.  I
 suspect
 this is rare enough that it might be reasonable to require stubbly


 C
 functions be written to resolve the difference, but even if not, D



 make the rule that extern(C) identifiers are case-sensitive but D
 identifiers are not.

I am far from a language guru (though by reading here, I am learning


 some of the issues - thanks to everyone), but I have some, perhaps dumb,
 questions.  Some time ago, someone here suggested a scheme (I'm sorry, I
 can't remember the name) where identifiers were once you defined an
 identifier, any attempt to use an identifier that was the same letters


 different cases was an error.  Doesn't this solve the huge screw-up
 potential of case sensitivity (multiple different identifiers that


 really be the same) while fixing the arbitraryness of allowing full case
 insensitivityness?  It seems like a good compromise.

I remember that one; the suggestion would have these effects: int MixedCaseName; MixedcaseName = MixedcaseName + 1; ***ERROR: no such identifier 'MixedupName'

I presume you mean 'MixedcaseName' in the error message. Even so, why can't the error message take note that there is an identically spelled, but differently cased identifier and note that exactly as in the example you give below? It is still an error and the message is more informative.
 So far, it looks case-sensitive.

   int MixedUpName;
   int mixedupName;
 ***ERROR: differs from 'MixedCaseName' in letter case only.

 ...but this is remarkable.  It's case-sensitive because you can't use an
 identifier except by exact match.  It's case-insensitive because it

 the declaration of a variable spelled the same but with different letter
 case.

 I personally would rather not have a schizoid compiler.

Agreed, but I don't see why it has to be so. -- - Stephen Fuld e-mail address disguised to prevent spam
May 03 2002
prev sibling next sibling parent reply C.R.Chafer <blackmarlin nospam.asean-mail.com> writes:
John English wrote:

 I've only read the first few sections of the manual, but I noticed a
 few things in the lexical grammar already:

1 and 3 I think these are typographical errors in the manual. 2 the manual may be unclear on... [a-zA-Z]+ -> label [0-9][0-9a-fA-F][hH] -> hex number therefore each -> label 0each -> hex number
 4) A nice addition to the list of escape characters would be \e for
    ESC.

Maybe useful, and I do not '\e' is currently used. Personally I would prefer \[ like in bash.
 Also, re (3) above, can I make a plea for case insensitivity throughout?
 Students that I teach Java to waste an awful lot of their time dealing
 with spelling mistakes: they write RunTimeException instead of
 RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
 analogy with Hashtable) instead of HashMap...

I think you are blaming case sensitivity for what are errors in the Java library. If the naming convention commonly used in Java had been used throughout this would not be a problem - there is a difference between bad design and bad implementation, however this fault is little more than the annoying and incessant mispelling of colour in may programming languages. I personally prefer case sensitivity - but it is one of those topics where there is no right answer. When teaching others case insensitive languages are slightly easier, but writing language lexagraphical analisers it becomes an more difficult problem - especially when you consider the mess that is Unicode (id est. where one letter may be represented by multiple combinations and there is no simple algorithm to convert lower to upper case efficiently as exists with ASCII)
 What possible benefit do you get from case sensitivity? Why do you
 want to be able to distinguish between String and string and STRING,
 which any native English speaker would regard as different
 representations of the same word...

Then why do we differentiate between them in English? - maybe we should all start writing like e.e.cummings :-). My guess is it is convention, C is case sensitive and, as D is based on C, D is case sensitive too. Now is probably to late to vote for a change, however the proposed scripting language based on D (see D-- thread) may be a candidate for case insensitivity. I find the difference useful a it allows me to differentate between classes, structures and unions by using a capital first letter effectively creating a separate name space from the remainder of the variables which are instances of these objects.
  University of Brighton

Bring us all some Brighton Rock :-) C 2002/5/2
May 02 2002
parent reply John English <je brighton.ac.uk> writes:
"C.R.Chafer" wrote:
 
 I personally prefer case sensitivity - but it is one of those topics where
 there is no right answer.  When teaching others case insensitive languages
 are slightly easier,  but writing language lexagraphical analisers it
 becomes an more difficult problem - especially when you consider the mess
 that is Unicode (id est. where one letter may be represented by multiple
 combinations and there is no simple algorithm to convert lower to upper
 case efficiently as exists with ASCII)

??? All you do is get the lexical analyser to flatten everything to a single case (e.g. lowercase) when constructing tokens; it's a more difficult matter with Unicode (can't just build a 256-byte mapping table anymore) but it's hardly insuperable... and then the lexer churns out tokens which are always in a single case. End of problem.
 What possible benefit do you get from case sensitivity? Why do you
 want to be able to distinguish between String and string and STRING,
 which any native English speaker would regard as different
 representations of the same word...

Then why do we differentiate between them in English? - maybe we should all start writing like e.e.cummings :-).

Well, at least I can tell that e.e.cummings is the same guy as E.E.Cummings. In a case sensitive language they'd be two completely separate people. Still, I guessed this would be a lost cause...
  >  University of Brighton
 
 Bring us all some Brighton Rock :-)

:-) ----------------------------------------------------------------- John English | mailto:je brighton.ac.uk Senior Lecturer | http://www.it.bton.ac.uk/staff/je Dept. of Computing | ** NON-PROFIT CD FOR CS STUDENTS ** University of Brighton | -- see http://burks.bton.ac.uk -----------------------------------------------------------------
May 03 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"John English" <je brighton.ac.uk> wrote in message
news:3CD276CE.E34BE7EB brighton.ac.uk...

 ??? All you do is get the lexical analyser to flatten everything to
 a single case (e.g. lowercase) when constructing tokens; it's a more
 difficult matter with Unicode (can't just build a 256-byte mapping
 table anymore) but it's hardly insuperable... and then the lexer
 churns out tokens which are always in a single case. End of problem.

Not so fast! Don't forget about imported functions... there should definitely be some way to preserve case. Or, use the "proper case" convention: identifier is defined once, and definition is case-sensitive. Further references are converted to this proper case.
May 03 2002
parent "Sean L. Palmer" <spalmer iname.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:aau5lf$25kg$1 digitaldaemon.com...

 Not so fast! Don't forget about imported functions... there
 should definitely be some way to preserve case. Or, use
 the "proper case" convention: identifier is defined once,
 and definition is case-sensitive. Further references are converted
 to this proper case.

I like that idea best out of all I've heard so far. Sean
May 03 2002
prev sibling parent reply Karl Bochert <kbochert ix.netcom.com> writes:
 
 Well, at least I can tell that e.e.cummings is the same guy as
 E.E.Cummings. In a case sensitive language they'd be two completely
 separate people. Still, I guessed this would be a lost cause...
 

the second is somebody else. Case does provide semantic meaning. Karl Bochert
May 03 2002
parent "Nic Tiger" <nictiger pt.comcor.ru> writes:
You say that names with different case have the same semantic?
Remember mathematics! There we used very often the same letters written in
different case to denote not only different things, but even different
types.

Then I don't think it's good idea that 'X' and 'x' are the same. In
programming also there are many places where we can somehow select
(highlight) some var with changing case.

Thus, I think the only problem that case-sensitivity makes concerns
"MySpecialVar"-type of names. But this could be easily resolved by
programmer (not compiler) when good notation system is used.

Nic Tiger.

"Karl Bochert" <kbochert ix.netcom.com> wrote in message
news:1103_1020441383 bose...
 Well, at least I can tell that e.e.cummings is the same guy as
 E.E.Cummings. In a case sensitive language they'd be two completely
 separate people. Still, I guessed this would be a lost cause...

the second is somebody else. Case does provide semantic meaning. Karl Bochert

May 03 2002
prev sibling parent reply "Matthew Wilson" <matthewatd hotmail.com> writes:
Sorry, but this string String STRING stuff sounds like a guy I once worked
with who took the egregious

#define retrun return

with him wherever he went because he couldn't type well.

It's surely not the "case" that case insensitivity makes things easier to
teach, rather that it is easier to teach to people who want to be sloppy?
One only has to do a single days Windows programming to come across the M$
violation of the global namespace (both preprocessor and C/C++) to realise
that it is more, not less, discipline that is required to produce competent
software engineers, and that we are lacking them in large numbers.


"John English" <je brighton.ac.uk> wrote in message
news:3CD1479A.91A6CBDC brighton.ac.uk...
 I've only read the first few sections of the manual, but I noticed a
 few things in the lexical grammar already:
 1) the grammar for hex constants contains a misprint (0b instead of
    0x)
 2) the grammar for HexadecimalH constants looks ambiguous as is:
    it implies that the word "each" could be interpreted as a valid
    hexadecimal contant (same as 0xEAC)
 3) the grammar shows h or H as valid suffixes for HexadecimalH, but
    not prefixes 0B or 0X... is this intentional?
 4) A nice addition to the list of escape characters would be \e for
    ESC.

 Also, re (3) above, can I make a plea for case insensitivity throughout?
 Students that I teach Java to waste an awful lot of their time dealing
 with spelling mistakes: they write RunTimeException instead of
 RuntimeException, or HashTable instead of Hashtable, or Hashmap (by
 analogy with Hashtable) instead of HashMap... What possible benefit
 do you get from case sensitivity? Why do you want to be able to
 distinguish between String and string and STRING, which any native
 English speaker would regard as different representations of the
 same word...

 -----------------------------------------------------------------
  John English              | mailto:je brighton.ac.uk
  Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
  Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
  University of Brighton    |    -- see http://burks.bton.ac.uk
 -----------------------------------------------------------------

May 05 2002
parent reply "OddesE" <OddesE_XYZ hotmail.com> writes:
"Matthew Wilson" <matthewatd hotmail.com> wrote in message
news:ab2or3$1teu$1 digitaldaemon.com...
 Sorry, but this string String STRING stuff sounds like a guy I once worked
 with who took the egregious

 #define retrun return

 with him wherever he went because he couldn't type well.

LOL!
 It's surely not the "case" that case insensitivity makes things easier to
 teach, rather that it is easier to teach to people who want to be sloppy?
 One only has to do a single days Windows programming to come across the M$
 violation of the global namespace (both preprocessor and C/C++) to realise
 that it is more, not less, discipline that is required to produce

 software engineers, and that we are lacking them in large numbers.

But isn't this one of the problems? No matter if you use HungarianNotation like Microsoft does or lower_case like the C standard library, with case sensitivity you are forced to use other peoples conventions, even if they conflict with each others or with yours! Then again in pascal I see code that contains the same symbol spelled in many different ways: begin Begin BEGIN Even in the same source file! I think that this makes me want to lean towards case sensitivity. But I am not 'sensitive' on the issue. :) -- Stijn OddesE_XYZ hotmail.com http://OddesE.cjb.net _________________________________________________ Remove _XYZ from my address when replying by mail
May 05 2002
parent reply "Pavel Minayev" <evilone omen.ru> writes:
"OddesE" <OddesE_XYZ hotmail.com> wrote in message
news:ab3u9t$2tna$1 digitaldaemon.com...

 Then again in pascal I see code that contains the
 same symbol spelled in many different ways:

 begin
 Begin
 BEGIN

Oh yeah... and then Integer, and tRect and IF in that same file. =) I do remember these things. That's why I'm for case sensitivity
May 05 2002
parent "Walter" <walter digitalmars.com> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:ab3v4b$2uap$1 digitaldaemon.com...
 Oh yeah... and then Integer, and tRect and IF in that same
 file. =) I do remember these things. That's why I'm for
 case sensitivity

I've used both case sensitive and insensitive languages. I much prefer the sensitive ones, though I can't give a good reason why. Perhaps it's because I get better results from grep when I'm looking through files <g>.
May 15 2002