Compiler/Language eXperiment

Hi!


I'm searching for people who are interested in participating a compiler
experiment. This project is in planning phase, since I want to give people
the chance to bring in their own ideas right from the beginning. I've been
working since beginning of this year on a related projet
http://www.dtone.org


I'll outline what this experiment is about.


Think about the way we're used to programming, we write text files in a
text editor having a specific command structure in mind. After writing the
text a parser has to seek out that structure again. When we're talking
about language or project coding-style we're often only discussing how this
text files should look like, if the indention of blocks should be 2,
4 or 8 characters or tabs, if the blocks should be marked with curly
brackets or with the BEGIN/END keywords, if the leading bracket should be
in the same line or in the next, and on and on. But after all that does
really not matter, or? We all have the same symantical block in mind, no
matter how it's representation looks like. Now how about not storing the
project code as text, but to store directly the information that there is a
block? Every user can interact with this data with his favorite viewing
tool, it can show curly brackets, BEGIN/END keywords or highlight this
block mere by coloring or it could also illustrate the code in a tree view!
Note that this is fundamentally different to the way IDE's work today
with a code-insight feature. They've a parser running constantly in
background drudging to understand the code structure
in realtime as you write the text file, not you specifing directly the
structure and a viewer that is showing it. There's even more potential in
the viewer, it could in example let you write mathematical expressions just
like they would look
on paper, (like in example mathcad).


First thanks for reading so far :o) Maybe I got you excited already...


Altough the representation does no longer matter, there has to be a
structure in the language. In example one cannot exchange C and PASCAL
freely. They've also semantical differences. So to speak tech jargon, the
syntactic is free, but the symantic has to be defined. As point of origin I
would take java, maybe with some extentions to it to be able to compete
with C(++) on it's homeland, like adress-of and content-of operators,
functions pointers, and beeing able to directly interact with existing C
libraries.


So how could the project structure been layed out? I'm thinking about a
central source server. Where the different viewers or parsers connect to it
using RPC, and interact with the data. However every programmer should have
his own source server running localy, no need to layout what happens if all
of them interact with the same source base at the same time. The server can
write his data into files (in example using XML), which can be syncronized
using CVS as usual. A backend application can retrieve the server data, and
generate in example piggyback C code, or at later stage having a gcc
frontend
that receives it's data from the source-server.


Every application in this tool chain should be kept relative small and
overlookable, but as whole growing bigger by working together.


If I've managed to set you on fire your input is highly appriciated, both
in design but also later at coding. This new project has not even yet a
name! So also here some good ideas are welcome, naming the beast is a
pretty difficult task. Until then my current project will function as
temporary host. All discussions are welcome on the mailing list!


http://lists.sourceforge.net/lists/listinfo/dtone-compiler


Although I don't want to discuss about the license: All Apps are GPL, libs
are LGPL, docs GDL and code-examples are public domain.


- Axel Kittenberger ( axel@dtone.org )
[There have been integrated development environments with structure
editors before. -John]

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