> > On Oct 2, 3:46 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >> On 2012/10/02 04:43, DKleinecke wrote:
> >>> On Oct 1, 1:42 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>> On 2012/10/01 01:51, DKleinecke wrote:
> >>>>> On Sep 30, 1:05 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>>>> On 2012/09/30 06:34, DKleinecke wrote:
> >>>>>>> On Sep 29, 1:10 am, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
> >>>>>>>> Le samedi 29 septembre 2012 04:18:43 UTC+2, DKleinecke a écrit :
> >>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
> >>>>>>>>> know, a standard technical term. But hierarchy is used often these
> >>>>>>>>> days to describe what are also called trees. For example XML.
> >>>>>>>> yes, but there are several kinds of trees,
> >>>>>>> Any of the different trees could be intended. The word hierarchy does
> >>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
> >>>>>>> the context seems to require such a reading.
> >>>>>> A more general structure is a formal grammar
> >>>>>> https://en.wikipedia.org/wiki/Formal_grammar > >>>>>> When implementing a computer language, one attaches semantic actions to
> >>>>>> the production rules.
> >>>>> The question really is what did the authors of a naive article about
> >>>>> language mean by hierarchy. I think any construction more complicated
> >>>>> than a string would fall under their concept of hierarchy.
> >>>> They do not seem to be very specific, just quoting some other articles.
> >>>>> There are other ways to write compilers (assuming that's what you
> >>>>> meant by implementing).
> >>>> I had in mind not relying entirely on a grammar, but using the semantic
> >>>> actions as well to pin down the language.
> >>> Without semantics a language is pretty useless. But while we all have
> >>> come to agree (more or less) about formal syntax there seems to be no
> >>> agreement on the best way to represent the semantics.
> >> Right, though there is denotational semantics.
> >>> For example I write compilers to what is technically a subset of C and
> >>> then assume the C compiler does all the optimizing dirty work.
> >> For example, LLVM admits optimizations that are not through C.
> >>> I feel
> >>> compilers are easy to write if it weren't for all the special cases
> >>> involved in implementing the language on a real computer. That part
> >>> is an exercise in pure boredom.
> >> That is legacy; comp.compilers had in March a thread about lack of
> >> progress in programming language design.
> > I am pretty old-fashioned about computer language. Although I would
> > prefer to code in assembly language I settle for 1990 ANSI standard C
> > with one improvement - declarations floating in blocks. I am unsure
> > that any "progress in programming language design" is a Good Thing.
> The 2011 revisions of C and C++ are rather quickly implemented now.
Sure. But I am old-fashioned enough to deplore the innovations. There
are even things in 1990 ANSI I deplore and do not use - for example,
FOR statements. FOR statements are not, if I remember correctly, in
the oldest surviving version of C - but that's not my objection. I
think they add unnecessary complexity to code.
>> >>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
>> >>>>>>>>> know, a standard technical term. But hierarchy is used often these
>> >>>>>>>>> days to describe what are also called trees. For example XML.
>> >>>>>>>> yes, but there are several kinds of trees,
>> >>>>>>> Any of the different trees could be intended. The word hierarchy does
>> >>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
>> >>>>>>> the context seems to require such a reading.
>> >>>>>> A more general structure is a formal grammar
>> >>>>>> https://en.wikipedia.org/wiki/Formal_grammar >> >>>>>> When implementing a computer language, one attaches semantic actions to
>> >>>>>> the production rules.
>> >>>>> The question really is what did the authors of a naive article about
>> >>>>> language mean by hierarchy. I think any construction more complicated
>> >>>>> than a string would fall under their concept of hierarchy.
>> >>>> They do not seem to be very specific, just quoting some other articles.
>> >>>>> There are other ways to write compilers (assuming that's what you
>> >>>>> meant by implementing).
>> >>>> I had in mind not relying entirely on a grammar, but using the semantic
>> >>>> actions as well to pin down the language.
>> >>> Without semantics a language is pretty useless. But while we all have
>> >>> come to agree (more or less) about formal syntax there seems to be no
>> >>> agreement on the best way to represent the semantics.
>> >> Right, though there is denotational semantics.
>> >>> For example I write compilers to what is technically a subset of C and
>> >>> then assume the C compiler does all the optimizing dirty work.
>> >> For example, LLVM admits optimizations that are not through C.
>> >>> I feel
>> >>> compilers are easy to write if it weren't for all the special cases
>> >>> involved in implementing the language on a real computer. That part
>> >>> is an exercise in pure boredom.
>> >> That is legacy; comp.compilers had in March a thread about lack of
>> >> progress in programming language design.
>> > I am pretty old-fashioned about computer language. Although I would
>> > prefer to code in assembly language I settle for 1990 ANSI standard C
>> > with one improvement - declarations floating in blocks. I am unsure
>> > that any "progress in programming language design" is a Good Thing.
>> The 2011 revisions of C and C++ are rather quickly implemented now.
> Sure. But I am old-fashioned enough to deplore the innovations. There
> are even things in 1990 ANSI I deplore and do not use - for example,
> FOR statements. FOR statements are not, if I remember correctly, in
> the oldest surviving version of C - but that's not my objection. I
> think they add unnecessary complexity to code.
Your avoiding the FOR statements reminded me of an article
I read many, many, many years ago when I was in a small group
of people writing an Algol 60 compiler. The magazine (it may have
been CACM, but I am not sure anymore) article advocated replacing
all Fortran FOR statements with ON GOTOs and calculated GOTOs.
Jiminy crickets I thought to myself, calculated GOTOs, that guy
must be nuts. Towards the end of the article the author embarked on
discussing the virtues of the proposed COME FROM. Wow, wow,
wait a minute!!! I checked the date of the issue, and yes it was
the 1st of April.
> On Oct 3, 9:48 am, Hans Aberg <haberg-n...@telia.com> wrote:
>> On 2012/10/03 02:23, DKleinecke wrote:
>>> On Oct 2, 3:46 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>> On 2012/10/02 04:43, DKleinecke wrote:
>>>>> On Oct 1, 1:42 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>> On 2012/10/01 01:51, DKleinecke wrote:
>>>>>>> On Sep 30, 1:05 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>>>> On 2012/09/30 06:34, DKleinecke wrote:
>>>>>>>>> On Sep 29, 1:10 am, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
>>>>>>>>>> Le samedi 29 septembre 2012 04:18:43 UTC+2, DKleinecke a écrit :
>>>>>>>>>>> On Sep 27, 11:57 pm, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
>>>>>>>>>>>> What does "hierarchy" describe?
>>>>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
>>>>>>>>>>> know, a standard technical term. But hierarchy is used often these
>>>>>>>>>>> days to describe what are also called trees. For example XML.
>>>>>>>>>> yes, but there are several kinds of trees,
>>>>>>>>> Any of the different trees could be intended. The word hierarchy does
>>>>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
>>>>>>>>> the context seems to require such a reading.
>>>>>>>> A more general structure is a formal grammar
>>>>>>>> https://en.wikipedia.org/wiki/Formal_grammar >>>>>>>> When implementing a computer language, one attaches semantic actions to
>>>>>>>> the production rules.
>>>>>>> The question really is what did the authors of a naive article about
>>>>>>> language mean by hierarchy. I think any construction more complicated
>>>>>>> than a string would fall under their concept of hierarchy.
>>>>>> They do not seem to be very specific, just quoting some other articles.
>>>>>>> There are other ways to write compilers (assuming that's what you
>>>>>>> meant by implementing).
>>>>>> I had in mind not relying entirely on a grammar, but using the semantic
>>>>>> actions as well to pin down the language.
>>>>> Without semantics a language is pretty useless. But while we all have
>>>>> come to agree (more or less) about formal syntax there seems to be no
>>>>> agreement on the best way to represent the semantics.
>>>> Right, though there is denotational semantics.
>>>>> For example I write compilers to what is technically a subset of C and
>>>>> then assume the C compiler does all the optimizing dirty work.
>>>> For example, LLVM admits optimizations that are not through C.
>>>>> I feel
>>>>> compilers are easy to write if it weren't for all the special cases
>>>>> involved in implementing the language on a real computer. That part
>>>>> is an exercise in pure boredom.
>>>> That is legacy; comp.compilers had in March a thread about lack of
>>>> progress in programming language design.
>>> I am pretty old-fashioned about computer language. Although I would
>>> prefer to code in assembly language I settle for 1990 ANSI standard C
>>> with one improvement - declarations floating in blocks. I am unsure
>>> that any "progress in programming language design" is a Good Thing.
>> The 2011 revisions of C and C++ are rather quickly implemented now.
> Sure. But I am old-fashioned enough to deplore the innovations. There
> are even things in 1990 ANSI I deplore and do not use - for example,
> FOR statements. FOR statements are not, if I remember correctly, in
> the oldest surviving version of C - but that's not my objection. I
> think they add unnecessary complexity to code.
Have you though of switching to B? Not even Bison will support these outdated versions of C.
> > On Oct 3, 9:48 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >> On 2012/10/03 02:23, DKleinecke wrote:
> >>> On Oct 2, 3:46 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>> On 2012/10/02 04:43, DKleinecke wrote:
> >>>>> On Oct 1, 1:42 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>>>> On 2012/10/01 01:51, DKleinecke wrote:
> >>>>>>> On Sep 30, 1:05 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>>>>>> On 2012/09/30 06:34, DKleinecke wrote:
> >>>>>>>>> On Sep 29, 1:10 am, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
> >>>>>>>>>> Le samedi 29 septembre 2012 04:18:43 UTC+2, DKleinecke a écrit :
> >>>>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
> >>>>>>>>>>> know, a standard technical term. But hierarchy is used often these
> >>>>>>>>>>> days to describe what are also called trees. For example XML.
> >>>>>>>>>> yes, but there are several kinds of trees,
> >>>>>>>>> Any of the different trees could be intended. The word hierarchy does
> >>>>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
> >>>>>>>>> the context seems to require such a reading.
> >>>>>>>> A more general structure is a formal grammar
> >>>>>>>> https://en.wikipedia.org/wiki/Formal_grammar > >>>>>>>> When implementing a computer language, one attaches semantic actions to
> >>>>>>>> the production rules.
> >>>>>>> The question really is what did the authors of a naive article about
> >>>>>>> language mean by hierarchy. I think any construction more complicated
> >>>>>>> than a string would fall under their concept of hierarchy.
> >>>>>> They do not seem to be very specific, just quoting some other articles.
> >>>>>>> There are other ways to write compilers (assuming that's what you
> >>>>>>> meant by implementing).
> >>>>>> I had in mind not relying entirely on a grammar, but using the semantic
> >>>>>> actions as well to pin down the language.
> >>>>> Without semantics a language is pretty useless. But while we all have
> >>>>> come to agree (more or less) about formal syntax there seems to be no
> >>>>> agreement on the best way to represent the semantics.
> >>>> Right, though there is denotational semantics.
> >>>>> For example I write compilers to what is technically a subset of C and
> >>>>> then assume the C compiler does all the optimizing dirty work.
> >>>> For example, LLVM admits optimizations that are not through C.
> >>>>> I feel
> >>>>> compilers are easy to write if it weren't for all the special cases
> >>>>> involved in implementing the language on a real computer. That part
> >>>>> is an exercise in pure boredom.
> >>>> That is legacy; comp.compilers had in March a thread about lack of
> >>>> progress in programming language design.
> >>> I am pretty old-fashioned about computer language. Although I would
> >>> prefer to code in assembly language I settle for 1990 ANSI standard C
> >>> with one improvement - declarations floating in blocks. I am unsure
> >>> that any "progress in programming language design" is a Good Thing.
> >> The 2011 revisions of C and C++ are rather quickly implemented now.
> > Sure. But I am old-fashioned enough to deplore the innovations. There
> > are even things in 1990 ANSI I deplore and do not use - for example,
> > FOR statements. FOR statements are not, if I remember correctly, in
> > the oldest surviving version of C - but that's not my objection. I
> > think they add unnecessary complexity to code.
> Have you though of switching to B? Not even Bison will support these
> outdated versions of C.
Not at all sure which versions of C you as disparaging. If you mean
1990 ANSI it is still a subset and newer software - like Gnu CC - work
just fine. There is no rule saying you must use all features of a
language. If you mean the original version, it had other defects that
the 1990 version almost entirely cleared up.
> On Oct 4, 12:54 am, Hans Aberg <haberg-n...@telia.com> wrote:
>> On 2012/10/04 02:18, DKleinecke wrote:
>>> On Oct 3, 9:48 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>> On 2012/10/03 02:23, DKleinecke wrote:
>>>>> On Oct 2, 3:46 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>> On 2012/10/02 04:43, DKleinecke wrote:
>>>>>>> On Oct 1, 1:42 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>>>> On 2012/10/01 01:51, DKleinecke wrote:
>>>>>>>>> On Sep 30, 1:05 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>>>>>> On 2012/09/30 06:34, DKleinecke wrote:
>>>>>>>>>>> On Sep 29, 1:10 am, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
>>>>>>>>>>>> Le samedi 29 septembre 2012 04:18:43 UTC+2, DKleinecke a écrit :
>>>>>>>>>>>>> On Sep 27, 11:57 pm, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
>>>>>>>>>>>>>> What does "hierarchy" describe?
>>>>>>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
>>>>>>>>>>>>> know, a standard technical term. But hierarchy is used often these
>>>>>>>>>>>>> days to describe what are also called trees. For example XML.
>>>>>>>>>>>> yes, but there are several kinds of trees,
>>>>>>>>>>> Any of the different trees could be intended. The word hierarchy does
>>>>>>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
>>>>>>>>>>> the context seems to require such a reading.
>>>>>>>>>> A more general structure is a formal grammar
>>>>>>>>>> https://en.wikipedia.org/wiki/Formal_grammar >>>>>>>>>> When implementing a computer language, one attaches semantic actions to
>>>>>>>>>> the production rules.
>>>>>>>>> The question really is what did the authors of a naive article about
>>>>>>>>> language mean by hierarchy. I think any construction more complicated
>>>>>>>>> than a string would fall under their concept of hierarchy.
>>>>>>>> They do not seem to be very specific, just quoting some other articles.
>>>>>>>>> There are other ways to write compilers (assuming that's what you
>>>>>>>>> meant by implementing).
>>>>>>>> I had in mind not relying entirely on a grammar, but using the semantic
>>>>>>>> actions as well to pin down the language.
>>>>>>> Without semantics a language is pretty useless. But while we all have
>>>>>>> come to agree (more or less) about formal syntax there seems to be no
>>>>>>> agreement on the best way to represent the semantics.
>>>>>> Right, though there is denotational semantics.
>>>>>>> For example I write compilers to what is technically a subset of C and
>>>>>>> then assume the C compiler does all the optimizing dirty work.
>>>>>> For example, LLVM admits optimizations that are not through C.
>>>>>>> I feel
>>>>>>> compilers are easy to write if it weren't for all the special cases
>>>>>>> involved in implementing the language on a real computer. That part
>>>>>>> is an exercise in pure boredom.
>>>>>> That is legacy; comp.compilers had in March a thread about lack of
>>>>>> progress in programming language design.
>>>>> I am pretty old-fashioned about computer language. Although I would
>>>>> prefer to code in assembly language I settle for 1990 ANSI standard C
>>>>> with one improvement - declarations floating in blocks. I am unsure
>>>>> that any "progress in programming language design" is a Good Thing.
>>>> The 2011 revisions of C and C++ are rather quickly implemented now.
>>> Sure. But I am old-fashioned enough to deplore the innovations. There
>>> are even things in 1990 ANSI I deplore and do not use - for example,
>>> FOR statements. FOR statements are not, if I remember correctly, in
>>> the oldest surviving version of C - but that's not my objection. I
>>> think they add unnecessary complexity to code.
>> Have you though of switching to B? Not even Bison will support these
>> outdated versions of C.
> Not at all sure which versions of C you as disparaging. If you mean
> 1990 ANSI it is still a subset and newer software - like Gnu CC - work
> just fine. There is no rule saying you must use all features of a
> language. If you mean the original version, it had other defects that
> the 1990 version almost entirely cleared up.
It is K&R C that will not be supported in Bison 2.6. This means that one cannot expect a compiler only accepting this language to compile a Bison generated parser file.
> > On Oct 4, 12:54 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >> On 2012/10/04 02:18, DKleinecke wrote:
> >>> On Oct 3, 9:48 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>> On 2012/10/03 02:23, DKleinecke wrote:
> >>>>> On Oct 2, 3:46 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>>>> On 2012/10/02 04:43, DKleinecke wrote:
> >>>>>>> On Oct 1, 1:42 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>>>>>> On 2012/10/01 01:51, DKleinecke wrote:
> >>>>>>>>> On Sep 30, 1:05 am, Hans Aberg <haberg-n...@telia.com> wrote:
> >>>>>>>>>> On 2012/09/30 06:34, DKleinecke wrote:
> >>>>>>>>>>> On Sep 29, 1:10 am, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
> >>>>>>>>>>>> Le samedi 29 septembre 2012 04:18:43 UTC+2, DKleinecke a écrit :
> >>>>>>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
> >>>>>>>>>>>>> know, a standard technical term. But hierarchy is used often these
> >>>>>>>>>>>>> days to describe what are also called trees. For example XML.
> >>>>>>>>>>>> yes, but there are several kinds of trees,
> >>>>>>>>>>> Any of the different trees could be intended. The word hierarchy does
> >>>>>>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
> >>>>>>>>>>> the context seems to require such a reading.
> >>>>>>>>>> A more general structure is a formal grammar
> >>>>>>>>>> https://en.wikipedia.org/wiki/Formal_grammar > >>>>>>>>>> When implementing a computer language, one attaches semantic actions to
> >>>>>>>>>> the production rules.
> >>>>>>>>> The question really is what did the authors of a naive article about
> >>>>>>>>> language mean by hierarchy. I think any construction more complicated
> >>>>>>>>> than a string would fall under their concept of hierarchy.
> >>>>>>>> They do not seem to be very specific, just quoting some other articles.
> >>>>>>>>> There are other ways to write compilers (assuming that's what you
> >>>>>>>>> meant by implementing).
> >>>>>>>> I had in mind not relying entirely on a grammar, but using the semantic
> >>>>>>>> actions as well to pin down the language.
> >>>>>>> Without semantics a language is pretty useless. But while we all have
> >>>>>>> come to agree (more or less) about formal syntax there seems to be no
> >>>>>>> agreement on the best way to represent the semantics.
> >>>>>> Right, though there is denotational semantics.
> >>>>>>> For example I write compilers to what is technically a subset of C and
> >>>>>>> then assume the C compiler does all the optimizing dirty work.
> >>>>>> For example, LLVM admits optimizations that are not through C.
> >>>>>>> I feel
> >>>>>>> compilers are easy to write if it weren't for all the special cases
> >>>>>>> involved in implementing the language on a real computer. That part
> >>>>>>> is an exercise in pure boredom.
> >>>>>> That is legacy; comp.compilers had in March a thread about lack of
> >>>>>> progress in programming language design.
> >>>>> I am pretty old-fashioned about computer language. Although I would
> >>>>> prefer to code in assembly language I settle for 1990 ANSI standard C
> >>>>> with one improvement - declarations floating in blocks. I am unsure
> >>>>> that any "progress in programming language design" is a Good Thing.
> >>>> The 2011 revisions of C and C++ are rather quickly implemented now.
> >>> Sure. But I am old-fashioned enough to deplore the innovations. There
> >>> are even things in 1990 ANSI I deplore and do not use - for example,
> >>> FOR statements. FOR statements are not, if I remember correctly, in
> >>> the oldest surviving version of C - but that's not my objection. I
> >>> think they add unnecessary complexity to code.
> >> Have you though of switching to B? Not even Bison will support these
> >> outdated versions of C.
> > Not at all sure which versions of C you as disparaging. If you mean
> > 1990 ANSI it is still a subset and newer software - like Gnu CC - work
> > just fine. There is no rule saying you must use all features of a
> > language. If you mean the original version, it had other defects that
> > the 1990 version almost entirely cleared up.
> It is K&R C that will not be supported in Bison 2.6. This means that one
> cannot expect a compiler only accepting this language to compile a Bison
> generated parser file.
Which matters, of course, only if one uses Bison. I don't.
I haven't checked in detail but I believe 1990 ANSI corrected several
genuine problems with K&R and they are not identical.
> On Oct 5, 5:26 am, Hans Aberg <haberg-n...@telia.com> wrote:
>> On 2012/10/05 01:44, DKleinecke wrote:
>>> On Oct 4, 12:54 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>> On 2012/10/04 02:18, DKleinecke wrote:
>>>>> On Oct 3, 9:48 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>> On 2012/10/03 02:23, DKleinecke wrote:
>>>>>>> On Oct 2, 3:46 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>>>> On 2012/10/02 04:43, DKleinecke wrote:
>>>>>>>>> On Oct 1, 1:42 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>>>>>> On 2012/10/01 01:51, DKleinecke wrote:
>>>>>>>>>>> On Sep 30, 1:05 am, Hans Aberg <haberg-n...@telia.com> wrote:
>>>>>>>>>>>> On 2012/09/30 06:34, DKleinecke wrote:
>>>>>>>>>>>>> On Sep 29, 1:10 am, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
>>>>>>>>>>>>>> Le samedi 29 septembre 2012 04:18:43 UTC+2, DKleinecke a écrit :
>>>>>>>>>>>>>>> On Sep 27, 11:57 pm, "Arnaud F." <fournet.arn...@wanadoo.fr> wrote:
>>>>>>>>>>>>>>>> What does "hierarchy" describe?
>>>>>>>>>>>>>>> Actually I have been guessing what they meant. It is not, so far as I
>>>>>>>>>>>>>>> know, a standard technical term. But hierarchy is used often these
>>>>>>>>>>>>>>> days to describe what are also called trees. For example XML.
>>>>>>>>>>>>>> yes, but there are several kinds of trees,
>>>>>>>>>>>>> Any of the different trees could be intended. The word hierarchy does
>>>>>>>>>>>>> not imply what kind. In fact, it usually doesn't imply a tree - but
>>>>>>>>>>>>> the context seems to require such a reading.
>>>>>>>>>>>> A more general structure is a formal grammar
>>>>>>>>>>>> https://en.wikipedia.org/wiki/Formal_grammar >>>>>>>>>>>> When implementing a computer language, one attaches semantic actions to
>>>>>>>>>>>> the production rules.
>>>>>>>>>>> The question really is what did the authors of a naive article about
>>>>>>>>>>> language mean by hierarchy. I think any construction more complicated
>>>>>>>>>>> than a string would fall under their concept of hierarchy.
>>>>>>>>>> They do not seem to be very specific, just quoting some other articles.
>>>>>>>>>>> There are other ways to write compilers (assuming that's what you
>>>>>>>>>>> meant by implementing).
>>>>>>>>>> I had in mind not relying entirely on a grammar, but using the semantic
>>>>>>>>>> actions as well to pin down the language.
>>>>>>>>> Without semantics a language is pretty useless. But while we all have
>>>>>>>>> come to agree (more or less) about formal syntax there seems to be no
>>>>>>>>> agreement on the best way to represent the semantics.
>>>>>>>> Right, though there is denotational semantics.
>>>>>>>>> For example I write compilers to what is technically a subset of C and
>>>>>>>>> then assume the C compiler does all the optimizing dirty work.
>>>>>>>> For example, LLVM admits optimizations that are not through C.
>>>>>>>>> I feel
>>>>>>>>> compilers are easy to write if it weren't for all the special cases
>>>>>>>>> involved in implementing the language on a real computer. That part
>>>>>>>>> is an exercise in pure boredom.
>>>>>>>> That is legacy; comp.compilers had in March a thread about lack of
>>>>>>>> progress in programming language design.
>>>>>>> I am pretty old-fashioned about computer language. Although I would
>>>>>>> prefer to code in assembly language I settle for 1990 ANSI standard C
>>>>>>> with one improvement - declarations floating in blocks. I am unsure
>>>>>>> that any "progress in programming language design" is a Good Thing.
>>>>>> The 2011 revisions of C and C++ are rather quickly implemented now.
>>>>> Sure. But I am old-fashioned enough to deplore the innovations. There
>>>>> are even things in 1990 ANSI I deplore and do not use - for example,
>>>>> FOR statements. FOR statements are not, if I remember correctly, in
>>>>> the oldest surviving version of C - but that's not my objection. I
>>>>> think they add unnecessary complexity to code.
>>>> Have you though of switching to B? Not even Bison will support these
>>>> outdated versions of C.
>>> Not at all sure which versions of C you as disparaging. If you mean
>>> 1990 ANSI it is still a subset and newer software - like Gnu CC - work
>>> just fine. There is no rule saying you must use all features of a
>>> language. If you mean the original version, it had other defects that
>>> the 1990 version almost entirely cleared up.
>> It is K&R C that will not be supported in Bison 2.6. This means that one
>> cannot expect a compiler only accepting this language to compile a Bison
>> generated parser file.
> Which matters, of course, only if one uses Bison. I don't.
> I haven't checked in detail but I believe 1990 ANSI corrected several
> genuine problems with K&R and they are not identical.
The problem is only if you expect your subset to be supported.
