removal of cruft from D

[Justin Johansson]

Nick Sabalausky wrote:
> "Justin Johansson" <no at spam.com> wrote in message 
> news:he768r$244h$1 at digitalmars.com...
>> Nick Sabalausky wrote:
>>> 1. Floating point literals without digits on *both* sides!!! "1.", 
>>> ".1" --> Useless hindrance to future language expansion!
>>>
>> On 1.  I understand you mean floating point literals without digits on 
>> both sides of the decimal point should be disallowed.  On basis of this 
>> understanding I beg to differ on grounds that this *should* be allowed for 
>> future language expansion.
>>
>> Rationale: Whilst D is not currently XML aware (to any meaningful level of 
>> standards compliance), the language may go that way in the future. 
>> Therefore I would suggest that the lexical form of all literals in the 
>> language should be aligned with, or at least include the lexical forms of, 
>> literals as allowed by XML Schema Part 2: Datatypes Second Edition
>>
>> http://www.w3.org/TR/xmlschema-2/
>>
>> Specifically this does allow digits to be omitted from either size as per 
>> the following lexical production:
>>
>> DoubleLiteral ::=
>> (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits
>>
>> It is noted, of course, that D does provide the very programmer-friendly 
>> mechanism of allowing underscores to used to separate digits in integer 
>> literals.  Whilst integers with embedded underscores are not included in 
>> the lexical space of integers as in cited XML Schema Datatypes, I do not 
>> argue against them.  In other words, whatever D supports with respect to 
>> the lexical forms of literals is fine so long as it *does not* preclude 
>> lexical forms from XML Schema Datatypes.
>>
> 
> I'm not sure I understand the usefulness of doing that, or what exactly you 
> mean by a language being XML-aware. If you mean it would help translating 
> some sort of special XML files into D code, then supporting those types of 
> float literals from xml would be trivial to special-case. Or if you mean 
> doing some sort of XML->D translation via XSLT: in my experience, I've found 
> that XSLT is in general a very poor choice for anything other than XML->XML 
> translations. Other than that, I don't understand the point...?

I wasn't thinking XSLT particularly.

By XML aware, I meant awareness of (any parts of) the wider XML 
ecosystem in general and W3C related specs so not just XML syntax but 
including XML Schema Datatypes for example.  Obviously XSLT is something 
that would be implemented in a library rather than being reflected in a 
language but such a library would be easier to implement in a language 
that acknowledged XML Schema Datatypes.

In the case of XML syntax, note that both Scala and JavaScript support 
XML syntax at the language level (the latter via the E4X extension to 
JavaScript).  At some point in the (distant) future, D might support XML 
syntax in the language in similar fashion to Scala, who knows.  I 
understand that D1 has some ability to embed D code in HTML.  Though 
I've never used it, and considering that (X)HTML is an application of 
XML, this is at least an acknowledgement by D that HTML exists!

My point basically boils down to this.  We all accept IEEE Standard for 
Floating-Point Arithmetic (IEEE 754) as the basis for the binary 
representation of floating point data and nobody is going to argue 
against that.  In terms of the evolution of standards, XML Schema 
Datatypes does for the lexical representation of common datatypes 
(numeric and string data), what IEEE 754 does for floating point data at 
the binary level.

In the future I believe that PL's will implicitly acknowledge XML Schema 
Datatypes as much as vernacular PL's implicitly acknowledge IEEE 754 
today and that's why I took shot at your comment "Useless hindrance to 
future language expansion".

Cheers
Justin