Re: Perfrom Thru

From: Rick Smith (ricksmith_at_mfi.net)
Date: 03/28/04 

Date: Sat, 27 Mar 2004 23:33:25 -0500

<docdwarf@panix.com> wrote in message news:c458v0$3mh$1@panix1.panix.com...
> In article <106bf9662o28uc6@corp.supernews.com>,
> Rick Smith <ricksmith@mfi.net> wrote:
> >
> ><docdwarf@panix.com> wrote in message
news:c4440d$scs$1@panix1.panix.com...
> >> In article <1069f8jbntmh6ab@corp.supernews.com>,
> >> Rick Smith <ricksmith@mfi.net> wrote:
> >> >
> >> ><docdwarf@panix.com> wrote in message
> >news:c417tk$pil$1@panix5.panix.com...
> >>
> >> [snip]
> >>
> >> >> It seems that you are setting the standard and the implementation to
be
> >> >> co-equal, that such things exist only in practise (a variation of
'ibi non
> >> >> accusator, non iudex' or 'where there ain't no cop there ain't no
> >> >> speed-limit'). That being the case then the conclusion appears to
be that
> >> >> the Standard is not a standard but... a suggestion.
> >> >
> >> >Not suggestion. Understand that a programming language
> >> >standard is a specification for a programming language; not a
> >> >specification for a compiler -- thus two domains.
> >>
> >> Using this terminology it seems that a compiler is an implementation of
> >> the specification of the language... after all, it is code.
> >
> >The language specification cannot be implemented directly.
>
> Nowhere in my statement is 'directly', 'indirectly' or 'around the barn
> door' referred to, Mr Smith.

Quite right. The sentence was introductory to the paragragph.
Sometimes splitting paragraphs can lead to confusion.

> >Parts of the language specification require the implementor
> >to complete the specification. For 2002 these items are listed
> >in Annex B as 'Implementor-defined language element list'.
>
> Standards and their implementation by compilers have been around for a few
> years prior to this... the one which started this thread was an ANSI '74
> compiler.

And, for years other thatn 2002, there is, to the best of my
knowledge, a similar list for those standards.

> >> >The standard
> >> >specifies valid syntax for the language. The implementor decides,
> >> >for example, how much valid syntax its compiler can accept.
> >>
> >> So it follows that a compiler is an implementation of a subset of the
> >> language specs set forth in the standard.
> >
> >Not quite. Your wording suggests that implementing half the
> >COBOL verbs would be sufficient ('implementation of a subset ...').
>
> Mr Smith, suggestion is in the mind of the beholder. If 'how much' a
> vendor chooses to implement of the standard's language specs is not equal
> to all that is in the standard then the implementation is, by definition,
> a subset.

Mr Dwarf, 'how much' refers to limitations imposed by the
compiler, a subject being discussed in this thread. Therefore,
it would not follow from the discussion 'that a compiler is an
implementation of a subset of the language specs set forth
in the standard.' which had not been discussed at all.

Since you introduced the subject of 'subset of the language spec',
If I remember correctly, IBM COBOL E was a subset of COBOL-68
and IBM COBOL F was a full implementation of that standard;
but I digress.

> >The correct sense is that the language specification is but one
> >of many requirements.
>
> 'Correct sense' to *whom*, Mr Smith?

To those who agree with my opinion, Mr Dwarf!

> >> >A language compiler cannot exist independently of a language
> >> >specification; but the language specification does not define
> >> >the specification for the compiler -- it imposes requirements
> >> >for the specification of the compiler.
> >>
> >> I am not sure how you are differentiating between 'defining
> >> specifications' and 'imposing requirements'; I have heard the two used
> >> interchangeably ('these requirements are set forth in the spec' and
'the
> >> spec is written so that it requires').
> >
> >That you have heard such merely attests to the usefulness of
> >these words in their various senses. In the more specialized
> >sense that applies to systems and software development,
> >requirements are used to produce specifications. Thus the
> >requirements for a COmmon Business Oriented Language
> >are used to establish a specification for that language and
> >a desire to implement that language means to accept the
> >language specification as one of the requirements for the
> >specification of the compiler.
>
> Mr Smith, in the paragraph above you state 'the requirements of COBOL are
> used to establish a specification for that language', in an earlier
> paragraph you state ' but the language specification.. imposes
> requirements for the specification of the compiler.'
>
> These appear to be contradictory, based on your assertion that
> 'requirements are used to produce specifications'.

They are not contradictory. Both the 'Implementor-defined language
elements list' and 'General rules', for example, impose requirements
that must find expression in the specification for the compiler.
Including a specification from one system as a requirement of
another is merely a means of bridging two separate (distinct?)
systems.

> >> >Consider the definition -- syntax error: a combination of
> >> >language elements that prevents successful compilation.
> >> >'[C]ombination of language elements' carries the notion of
> >> >syntax and 'prevents successful compilation' carries the
> >> >notion of error. If this definition is valid, it implies that valid
> >> >syntax (language domain) could cause a syntax error (compiler
> >> >domain) by preventing successful compilation (compiler domain).
> >> >The apparent absurdity is resolved by recognizing two distinct,
> >> >though dependent, domains.
> >>
> >> I would not say distinct... but that one is a subset of the other, the
> >> compiler's 'list of acceptable combinations of language elements'
contains
> >> a part of the Standard and... some other stuff, the various extensions
a
> >> vendor offers. In that case something which is 'invalid syntax' to the
> >> compiler could be valid syntax in the Standard... hence my question of
> >> 'where do the rules of valid syntax' live, the Standard or the
> >> implementation?'
> >
> >The implementation, subject to the Standard.
>
> If the implementation is subject to the Standard then, by definition, the
> implementation is subordinate to the Standard; the Standard, being
> superordinate, would seem to have primacy... or so your language might
> lead to conclude. What am I missing here?

Where the Standard provides formats and syntax rules, it is
supreme. Where the implementation provides formats and
syntax rules, it must not conflict with the Standard. The implementor
applies whichever rules are required. Your question '... the Standard
or the implemention?' asked for one to the exclusion of the other.
The answer is both in the form I stated. This is because the
rules 'live' in the implementation but must conform to the Standard
or, 'as if' the Standard's rules 'live' in the Standard.

Relevant Pages

  • Re: Perfrom Thru
    ... >> door' referred to, Mr Smith. ... >> vendor chooses to implement of the standard's language specs is not equal ... >> to all that is in the standard then the implementation is, by definition, ... >compiler, a subject being discussed in this thread. ...
    (comp.lang.cobol)
  • Re: Forth Frustrations
    ... How would they even know what they are without being language lawyers? ... Then if you choose a standard system you can write code for it, ... interpreter, ... They set up four states -- HOST INTERPRETER COMPILER ...
    (comp.lang.forth)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.ada)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.cpp)
  • Re: [9fans] caveat... optimizer? the `zero and forget thread on HN
    ... The language standard can only mandate what you can do within ... compiler dependent way. ... you can change from signed-preserving to unsigned preserving. ...
    (comp.os.plan9)