stability

[Ary Borenszweig]

Derek Parnell escribió:
> On Sun, 24 Feb 2008 09:12:18 +0000, Janice Caron wrote:
> 
>> On 24/02/2008, Derek Parnell <derek at psych.ward> wrote:
>>>  So I would imagine that before another D compiler is written, a
>>>  specification is created that forms the benchmark to measure what is a
>>>  conforming D compiler.
>> Specifications can have bugs in them too.
> 
> Really?? I'm shocked beyond sarcasm!
> 
>> That's why specifications have continual addenda and/or new versions.
> 
> Ohhh, I wondered why that happened.
> 
>> Without that, conforming implementations would be forced to implement
>> bugs.
> 
> Well thankfully we have people in this world who are willing to correct
> mistakes in specifications.
> 
>> The /real/ definition of a bug is probably "doesn't do what the
>> designer intended it to do". That's certainly true when /I/ write code
>> - if it doesn't do what I want, it's a bug. /Sometimes/ what I want it
>> to do is comply with a spec, in which case non-compliance is a bug,
>> but other times I'm creating something new, but in either case, a bug
>> is "it doesn't do what I intended".
>>
>> In the case of D, I'm happy that Walter is not constrained to a
>> possibly buggy spec.
> 
> I think that you and I have different experience about what is a
> specification. To me, a specification is a description of what will be
> achieved by some system/application, which is agreed upon by the
> stakeholders of the system. Yes, it likely that it will contain errors, we
> are human no? Yes, it is likely to be changed over time; to clarify, to
> remove functionality no longer required, and to add functionality that is
> now required. All this happens under the watchful eyes of the stakeholders
> in order to minimize mistakes in the specification. 
> 
> A good piece of software will implement mistakes in the spec. That same
> softare will also be modified to keep in synchronization with the spec. In
> my experience, it often happens that mistakes in the spec are discovered by
> the implementers. 
> 
> In the case of D, I'm not happy that Walter is not constrained to a
> possibly buggy spec. 
> 
> A specification, with or without bugs, does not cause bug free software.
> However, how will we know if an application contains bugs if you can't know
> "what the designer intended it to do" in the first place? The specification
> is supposed to tell us what the designer wanted.
> 
> I refuse to believe that Walter could not create a better D compiler if it
> was known what a D compiler was supposed to do. 
> 

See my response to Robert Fraser.

I think what the community should do, is write a D specification that 
looks like this one: 
http://java.sun.com/docs/books/jls/third_edition/html/j3TOC.html

It will explain everything: what's the grammar of the language, possibly 
how to write a lexer and a parser for it, what the compiler is supposed 
to do with a source file in order to compile it, etc. The specification 
could be a wiki, which Walter would check according to it's experience, 
intuition and the DMD front end.

Finally, when the specification is done, other compilers could be 
implemented. At that point, it won't matter if they act like the DMD 
front end (which probably won't work according to this new 
specification), it will only matter that they work according to this new 
sepcification.