Re: Programming language and IDE design

George Neuner <gneuner2@comcast.net>
Mon, 18 Nov 2013 19:02:39 -0500

          From comp.compilers

Related articles
[12 earlier articles]
Re: Programming language and IDE design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-08)
Re: Programming language and IDE design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2013-11-08)
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-11-08)
Re: Programming language and IDE design jthorn@astro.indiana.edu (Jonathan Thornburg) (2013-11-10)
Re: Programming language and IDE design martin@gkc.org.uk (Martin Ward) (2013-11-16)
Re: Programming language and IDE design DrDiettrich1@aol.com (Hans-Peter Diettrich) (2013-11-16)
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-11-18)
Re: Programming language and IDE design sgk@REMOVEtroutmask.apl.washington.edu (Steven G. Kargl) (2013-11-19)
Re: Programming language and IDE design gneuner2@comcast.net (George Neuner) (2013-11-19)
Re: Programming language and IDE design jonathan@cobalt.astro.indiana.edu (Jonathan Thornburg) (2013-11-19)
Re: Parsing Fortran, was Programming language and IDE design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-19)
Re: Parsing Fortran, was Programming language and IDE design gah@ugcs.caltech.edu (glen herrmannsfeldt) (2013-11-21)
Re: Programming language and IDE design wclodius@earthlink.net (2013-11-22)
[7 later articles]
| List of all articles for this month |
From: George Neuner <gneuner2@comcast.net>
Newsgroups: comp.compilers
Date: Mon, 18 Nov 2013 19:02:39 -0500
Organization: A noiseless patient Spider
References: 13-11-016
Keywords: design, comment
Posted-Date: 19 Nov 2013 09:45:55 EST

On Sat, 16 Nov 2013 15:55:10 +0000, Martin Ward <martin@gkc.org.uk>
wrote:


>On Friday 08 Nov 2013 at 21:04, George Neuner <gneuner2@comcast.net> wrote:
>
>> The majority of successful languages are LL(k) for small k. It's hard
>> to get much simpler than that for parsing.
>
>C is not LL(K), neither is COBOL, nor C++, nor I think is Java.
>That probably covers the majority of successful languages:
>if "success" is defined as "total lines of code in production".


They _all_ are LL(k). More specifically, I believe all of your
examples are, at most, LL(2).


AFAIK, Fortran's DO loop requires the most lookahead of any of the
classic language features: LL(4) [if I'm counting correctly].


      10DOI=42
      10DOI=42,45


Card Fortran didn't require whitespace separation. You had to look
ahead to find [or not] the comma to distinguish DO "I = m,n" from the
assignment "DOI = n".




>> It's impossible not to have implementation dependent behavior: e.g.,
>> program execution time is a behavior that can't be specified.
>
>In my opinion, execution time is not part of the semantics or meaning
>of a program.


Then I hope never to encounter any devices you have programmed.




>Early CPUs did not have a hardware stack: your attitude would suggest
>that *therefore* languages should define the behaviour of a recursive
>subroutine to be "implementation dependent". Fortunately, there were
>language designers, such as the designers of Lisp and Algol,
>who recognised the value of recursion and included it in their language.
>As a result, hardware designers added stack operations to their CPUs.


I simply said that your assertion:


    (2) Absolutely no behaviour should be "implementation dependent"
            or "undefined". Every syntactically valid program should have
            a single semantically valid meaning (even if that meaning
            is "halt with an error message").


is not plausible. I did not offer an alternative.




Since you brought up this ludicrous example, you ought to know that
the people who programmed those early CPUs - stack or no - were far
more aware of the program's runtime environment and of the tradeoffs
of using "equivalent" codings than you seem to want to be.


George
[Fortran through F77 potentially had to look arbitrarily far ahead to
tell FORMAT statements from an assignment to an array called FORMAT.
BTDT. But I would be surprised if any modern languages were that hard
to lex. -John]


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.