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

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...
> >
> Actually they probably are different people. The first is the poet and the second is somebody else. Case does provide semantic meaning.
>
> Karl Bochert
>
>

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


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

"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

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

"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
competent
> 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

"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

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

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

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

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