Re: Need starting tips for a new interpreter / parser

> COMMENTS:
> That is my goal too; NOT to create another visual tool,
> and also my main reason in planning to create
> a reporting language, completely source-code driven.


I am a great beliver in this approach. One of the main difficulties I
encountered with the visual tools is that they are propreitry and closed
to user modifaction. This usually means that they are tied to specifc DBMS
products, and don't allow extended functionality. I find this really hurt
- esp. in a legacy enviroment with lots data spread over different
machines/and formats. One aspect which is really important is the lack of
security options. It is very hard to add your security policy on top of
the usually limited model the GUI system has.


> You see, John, I am sick of all these Visual tools, because you always
> end up in having hundreds of calculated/formula fields all over your
> reports, to solve-real world report needs. And when trying to include
> new stuff to your report after ex. one year, you have forgot where you
> have the calculation you need to change, and in locating it, you need
> to double-click every formula field to find it (and ofcourse it is the
> last one).


I don't think this is the problem. I actually think that even if under the
hood the system is language driven, it is quite possible to provide a
clean , visual user interface - which may be easier to use. This also
means it should be easier to maintain the reports created.


One of the hard parts here is being able to do the transformation in both
directions:
visual/user view -> textual program
textual program -> visual view


This is a challange in those cases where either:
* you have old reports that were created before the interface existed.
This luckily for you, you don't have. OR
* users/admins are allowed to change the textual code, but the result
should make sense when viewed graphically.


Doing these transformations in a straight forward way is not hard. But it
will usually either mean stroing duplicate information, or producing a
less than optimal visual representation.


Doing it "the right way" is ahrd. It requires deep thinking about the
conceptual model of the language, and of possible interfaces.


Make sure your language is verstile enough for at least:
1. Direct coding (unless you decide only to implement a VM and not a HLL)
2. A simple visual model with bi-directional translation into code
3. Some complicated querying system you can imagine


>
> I hope to get some support on this project in comp.compilers, because
> I feel a little alone with these ideas.


I will be pleased to hear how you progress, and comment as best I can.


> [Making GUI applications programmable is always a challenge. But there's
> a lot of prior art in non-GUI reporters too, going back to the late
> lamented COBOL report writer which was actually rather nice even though
> it had an undeserved reputation as complex and baffling. -John]


I agree on both counts. I am not familiar with the COBOL report writer,
but I've seen many mainframe tools. some of them have very clver ideas.


I'd also try to make the system as table driven as possible (with tables
of data sources, data layouts etc.). It would be nice to create those as
needed from real data (like teh DBMS catalog table), and to keep it up to
date automatically.


I'd also think about utilities:
pretty printing, profiling, debugging etc.


So much for now.


Ehud Lamm mslamm@pluto.mscc.huji.ac.il

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