Re: New editor/Integrated Development Environment/compiler

On Apr 8, 3:40 am, HiramEgl <hiram...@hotmail.com> wrote:
> My name is Hiram and I would like to know if somebody is interested in
> joining the development of a new kind of editor/Integrated Development
> Environment/compiler.
...
>
> /Hiram
> [There were structure based tools back in the 1970s. My recollection
> is that they were completely unusable other than by the people who
> wrote them. -John]


Warning: Long, and possibly pointless post.


I have always wanted to build a parser generator tool that also builds
a syntax directed editor based on the grammar. Presumably this would
make editing easier and the user would only need to know one editor
though the editor would behave differently for different languages
(grammars).


Of particular interest to me is that, once a text is parsed, more is
known about the structure of the text and thus, in principle, you can
use this information to construct a representation of the text that is
more compact than the original text and that is faster to process by
the compiler than processing starting from the original text. What
the syntax directed editor would do then is deparse the parsed and
compressed text on demand for the user to edit and parse and
recompress the user's changes on the fly. With this set up the cost
of parsing during compilation would be close to 0. Well, parsing is
not a major cost of compiling anyway so the saving would not be that
great.


But there are other advantages. Since the text is efficiently
compressed, presumably better than generic text compressors, the
actual source files would be smaller. Of course with all the disk
space available this isn't all that important (when my source code
exceeds my 250GB hard drive I will let you know). An interesting
question is: Can the syntax directed editor file in a compressed
program file and decompress it faster than a regular editor can file
in the equivalent uncompressed program file? My expectation is that
it would. Of course, given the speed of computers today, this
performance improvement would rarely matter. In any case a smart
editor would not necessarily file in all of the source file before
displaying the part required by the user.


But there are other advantages. After parsing, the result can also be
fed to other tools for analyzing the program. These would also see
the same improvement as shown for compiling above.


But there are other advantages. One interesting thing that could be
done is have the parsed version of the program be broken into three
sections (perhaps three files):


      1) The core of the program. This section has everything except the
following sections.
      2) The comment section. This section contains all the comments and
also all spacing text.
      3) The naming section. This section would contain the equivalent
of the symbol table.


With this set up the program could be edited to change the comment
section and/or the naming section without requiring a recompile. I
think this is a useful feature though I don't know how many would
agree. In particular this would be useful when comparing two versions
of the program, one that works and one that doesn't. The user could
then ask to only see only the differences that affect the core
section. Also, during code freezes, the developer could be allowed to
update the comment and naming sections (and thus the he/she could
delay this work until the code freeze ;-) ).


The big issue though is that the syntax directed editor would need to
be easy enough to use and productive enough that developers will
actually use it. As John pointed out this is a major issue that
should not be underestimated.


It is also worth noting that this would be a lot of work, well unless
I do it in Smalltalk. :-)


Comments welcome.


Ralph Boland

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