Re: Syntax directed compilation

thomas.mertes@gmx.at
29 May 2007 01:03:56 -0700

          From comp.compilers

Related articles
Syntax directed compilation barry.j.kelly@gmail.com (Barry Kelly) (2007-05-26)
Re: Syntax directed compilation ang.usenet@gmail.com (Aaron Gray) (2007-05-28)
Re: Syntax directed compilation sdn@svpal.org (Steven Nichols) (2007-05-28)
Re: Syntax directed compilation thomas.mertes@gmx.at (2007-05-29)
Re: Syntax directed compilation cfc@shell01.TheWorld.com (Chris F Clark) (2007-05-29)
Re: Syntax directed compilation xenophon+usenet@irtnog.org (Matthew X. Economou) (2007-05-31)
Re: Syntax directed compilation barry.j.kelly@gmail.com (Barry Kelly) (2007-06-20)
| List of all articles for this month |

From: thomas.mertes@gmx.at
Newsgroups: comp.compilers
Date: 29 May 2007 01:03:56 -0700
Organization: Compilers Central
References: 07-05-088
Keywords: parse, design
Posted-Date: 30 May 2007 00:22:41 EDT

On 26 Mai, 13:45, Barry Kelly <barry.j.ke...@gmail.com> wrote:
> I recall, a long time back on this group, people pointing out that
> languages supporting redefinable or user extensible grammars have
> never taken off, and that like heavy armour on insects, it's a feature
> more notable of the extinct than the extant. The argument against them
> seems to be "too much power, users write their own languages and then
> can't understand one another's". That always seemed like a weak
> argument to me, and in this day and age of DSLs and indirect program
> rewriting in dynamic languages, I wonder if it just hasn't been done
> correctly yet.


It is also my opinion that it just hasn't been done correctly by
most programming languages.


> I've recently taken to thinking of source code as being a program to
> produce an executable, where compilers are interpreters of the text.
> That is, a declaration like 'int x;' in a C-like language is an
> imperative statement in the compiler's language to 'declare a variable
> called "x", of type "int", and add it to the current scope'.


This is the way Seed7 works. The declaration statements are executed
at
compile time. They declare new objects and add them to the current
scope.
That means: A Seed7 program is just a sequence of statements which are
executed at compiletime. Since this statements are (most of the time)
declaration statements, this declares the objects of the program.
A 'writeln' statement at top level does just print a message at
compile
time. The 'include' command (except for the first one which boots
Seed7)
is also a statement which is executed at compile time. You are able
to declare new declaration (and other) statements which can be used to
change the language. But this is not as easy as it sounds. All the
different things need to fit to an overall concept. In the future I
plan to create an 'import' statement (for a module / package system)
which is based on the 'include' statement. After the compile time the
interpreter looks for a function named 'main' and starts it. In the
compiler (which compiles to C) the code generation phase is started
instead.


> In this view, it is quite noticeable that most languages don't support
> much abstraction during this compile-time interpretation. C++
> templates seem like a limited and clumsy form of functions over parse
> trees, while C#/.NET-style type generics are single-level type
> constructors, and method generics method constructors. C macros are a
> very crude manipulation of the source text, with almost no syntax or
> type awareness.


The Seed7 templates are also functions which are executed at compile
time. This functions contain other declarations in their body and
declare the necessary things this way. For example:


  const proc: FOR_DECLS (in type: aType) is func
      begin


          const proc: for (inout aType: variable) range (in aType: low) to
(in aType: high) do
                  (in proc: statements) end for is func
              begin
                  variable := low;
                  if variable <= high then
                      statements;
                      while variable < high do
                          incr(variable);
                          statements;
                      end while;
                  end if;
              end func;


      end func;


  FOR_DECLS(char);
  FOR_DECLS(boolean);


As you can see: The instanciation of the templates must be explicit.
With 'FOR_DECLS(char)' the declaration statement 'const proc: for ...'
is executed which declares a for loop for char. Types are just
used as normal parameters. No special template / generic syntax with
'<' and '>' as in other languages.


> To old fogies of 27 like me, who like statically verified type safety,


I also consider "statically verified type safety" very important.


> one of the major advantages of the approach I'm describing is that it
> enables both (a) Lisp-level abstraction, symbolic manipulation and
> program rewriting and (b) compile-time type safety with a classically
> efficient target executable. It brings the dynamic touch to the static
> world. It also moves much, if not most, of the body of the compiler into
> the run-time library of the language.


This is exacly my approach.


> Has there been research in this area that I've missed on my searches
> (using 'syntax directed compilation' as my main phrase)?


Look for "extensible programming language".
I also suggest you look for Seed7 :-)


Greetings Thomas Mertes


Seed7 Homepage: http://seed7.sourceforge.net
Project page: http://sourceforge.net/projects/seed7


Post a followup to this message

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