Related articles |
---|
target language grammars. ralphpboland@yahoo.com (2004-11-06) |
Re: target language grammars. cppljevans@cox-internet.com (Larry Evans) (2004-11-07) |
Re: target language grammars. dobes@dobesland.com (Dobes Vandermeer) (2004-11-07) |
Re: target language grammars. lujoplujop@gmail.com (Lujop) (2004-11-07) |
Re: target language grammars. vbdis@aol.com (2004-11-07) |
Re: target language grammars. cgweav@aol.com (2004-11-07) |
Re: target language grammars. kenrose@tfb.com (Ken Rose) (2004-11-14) |
[3 later articles] |
From: | ralphpboland@yahoo.com (Ralph Boland) |
Newsgroups: | comp.compilers |
Date: | 6 Nov 2004 15:15:09 -0500 |
Organization: | http://groups.google.com |
Keywords: | parse, question |
Posted-Date: | 06 Nov 2004 15:15:09 EST |
Forgive me if these are stupid questions; I know a fair bit about
parsing but not so much about compiler back ends.
When translating/compiling from one language to another we normally
have a source language grammar but don't (to my knowledge) make much
use of any grammar for the target language. (Grammar here may mean
language syntax specification grammar, attribute grammar, or any other
grammar that might be fed to a "parser" generator.)
Does it make sence to make use of a grammar of the target language in
any way? Can anyone point to applications where the target language
grammar is made use of?
Perhaps, in translating a program, we could generate a representation
of the program as a parse tree in the target language and then
de-parse the parse tree to get code in the target language. The
de-parser could, in principle, be constructed automatically from a
grammar of the target language in much the same (but reversed) way
that a parser is constructed from a grammar for the source language.
Presumably, this would make writing a translator easier.
Mostly here I am thinking of cases where the target language is
something like postscript, pdf, or latex. (The Lyx program translates
Lyx files to latex files.)
I am particularly interested in the case that a target language
program represents how some data is to be displayed on a computer
screen. Consider, for example, a word processor, say Lyx. (Lyx is
basically a gui-editor on top of latex that allows easy creation of
latex documents. I am shamelessly putting in a plug for Lyx here.)
The user edits a Lyx file that can be translated to latex files. But
the user, when editing, doesn't see a Lyx file (which is similar to a
latex file) but instead a word-processor like representation of the
file on the screen. With each user change to the Lyx file the screen
representation of the Lyx file is updated. The data sent to the
screen can be thought of as a program in some "monitor" language that
when sent to the monitor is executed to cause the display of the image
on the screen. The monitor language might be much higher level than
described above and deal with much more of the translation process.
Assume that we have a grammar for this "monitor" language. If we were
to rewrite Lyx from scratch (I don't recommend this) would it not be
better to generate monitor language parse trees (than monitor language
programs) and use a monitor language de-parser to generate the data to
be sent to the screen (where the de-parser is generated automatically
from a monitor language grammar)?
I know this is very vague and not nearly as simple as described but,
hopefully, you get the general idea.
Ralph Boland
[It does sound familiar. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.