-
Notifications
You must be signed in to change notification settings - Fork 25
FAQ
Short answer: no.
Currently, we cannot exhibit exactly the same behaviour for the following two reasons :
- Currently, we first want to implement the full width of features of an incremental Cobol compiler. Once we have brought the technical proof that is is both doable and technically convincing, we will then implement the full depth of each remaining feature. Implementing the whole list of IBM compiler errors is one of these remaining tasks, wich is not completed ... for now.
- Our Cobol parser does have the following limitations.
Writing a full parser for a language other than Cobol or TypeCobol is out of our scope. However, we want to provide extension points so our parser can delegate some of the work to other existing parsers (more details here).
- First, for pragmatic reasons: as we wanted to clearly separate our parser from GUI-specific concerns, it has to be able to live as a server. So, why chose a language only suited for one of its purposes ?
- Second, for legacy reasons. The prototype initaly written by @laurentprudhon was full C#, and we did stick with it.
- Third, because our organization is more used to work in C# than in Java.
To be completely honest, we thought about converting from C# to Java. Here are some proofs. However, we dismissed this solution for the reasons listed up there.
Well, you can always create an issue, but please read our guidelines first. See you soon!
Why, thanks a lot! Of course you can, please check out how.
Introduction
TypeCobol language
-
In a nutshell
-
TypeCobol concepts
TypeCobol Editor
(Type)Cobol parser API
TypeCobol architecture
- Glossary
- Main phases
- How to extend the grammar and semantic check (full example)
- File
- Text
- Code analysis steps
- Program class parser
- Type checker
- Error handler
- Grammars Composition
- Code generation
- Compilation process
(Type)Cobol concepts / reference doc
Contributing