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

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

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

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

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

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

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

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

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

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