Re: Aspects of programming languages in common

From: James Harris (no.email.please)
Date: 04/28/04 

Date: Tue, 27 Apr 2004 23:06:35 +0100

"James Rogers" <jimmaureenrogers@att.net> wrote in message
news:Xns94D7C7A847D24jimmaureenrogers@204.127.36.1...
> "James Harris" <no.email.please> wrote in
> news:408d85dc$0$31680$fa0fcedb@lovejoy.zen.co.uk:
>
> > Think of my query as postulating a compiler where the definition of
> > the language's syntax can be defined, to a certain extent, in the
> > source (or in headers). If that /can/ be done why not define one
>
> Many languages do not use header files and pre-processors. How will
> you handle pre-processing for C and C++ but not for Fortran or
> Pascal? C code should not be scanned by the compiler until the
> pre-processor step is complete. C pre-processor statements are
> often needed even if a #include statement is not used.
>
> > compiler that will compile many languages based on changable syntax
> > rules. The answer, I suspect, is cost. Having to generate efficient
> > code based on parsed source is largely language-feature specific. The
> > query, then: why not translate the source languages to a common form?
>
> I see no reason not to make such a translation if you can handle all the
> differences. One simple approach is to force the person running the
> compiler to identify the language of the source code. You appear to
> want to automate that knowledge somehow, even down to the expression
> level. I do not see how you can do this unambiguously.

Jim, thanks for your comments. As in another reply I think each section of code would be
in only one language, maybe broken down to the statement level but no lower. There would
have to be a way to tell the compiler, "from now on expect these constructs," in a form
that was distinct from the language being compiled.

As for the preprocessor question, why not allow #include, #define etc at the top of any
code as long as there is a way to express this which does not conflict with the language
proper? Why not preprocess all code but for any Fortran or Pascal just pass it through
unchanged? I wonder, though, about symbolic substitutions in the Fortran code.... Do you
think these should be allowable? My gut feeling is, No, so as to keep the Fortran code,
er, Fortran! 

--
Cheers,
James

Relevant Pages

  • Re: Compiler and an interpreter
    ... >> Suppose in a source-code file, the 4th line contains the first syntax ... >> error.Can anybody please tell me how the compiler and interpreter will ... Some small unit of the language is an acceptable input. ... Perl does not to my knowledge in any way require the reading of the ...
    (comp.programming)
  • Re: Choice of programming language
    ... Language choice is a deeply religious issue, ... I also don't know how well the Fortran compilers are ... Do you have a bunch of money to drop on a compiler, ... other data structures? ...
    (sci.math.num-analysis)
  • Re: "STL from the Ground Up"
    ... high-level intermediate language than can interoperate with many other ... If your language lacks expressive features then you cannot write code ... memory management in comparison. ... Mostly because type errors mean that the programmer and compiler disagree ...
    (comp.programming)
  • Re: Fortran 2003 and F
    ... >> As the Fortran language keeps getting bigger, ... Walt's F compiler doesn't have ... what part of object-oriented programming ...
    (comp.lang.fortran)
  • Re: RAD vs. performance
    ... It depends on what the compiler can infer and optimize. ... rationals are another type, which are not supported in the cpu and would ... (rather than typed declarations based language with a class-based types ... using about the same syntax as before. ...
    (comp.lang.misc)