[🐛]: Tried the first program and complaining about

[birojnayak]

Describe the bug
biroj@88665a0182c9 demonewapp % otterkit build --run -e hello.cob --free

Analyzer Error [COB0085]: Missing source unit definition.
╭─/> [hello.cob:1:7]
│
1 │ program-id. hello.
│ ~~~~/> Expected a source unit id definition.
│
│ Note: The identification header is optional but every source unit must still have an ID.
│
────╯
Unhandled exception. System.InvalidOperationException: Stack empty.
at System.Collections.Generic.Stack1.ThrowForEmptyStack() at System.Collections.Generic.Stack1.Peek()
at Otterkit.Analyzers.Analyzer.Source() in C:\Users\KTSno\Documents\GitHub\otterkit\Otterkit.Analyzers\src\Analyzer.cs:line 54
at Otterkit.Analyzers.Analyzer.Analyze(List`1 tokenList) in C:\Users\KTSno\Documents\GitHub\otterkit\Otterkit.Analyzers\src\Analyzer.cs:line 17
at Otterkit.Otterkit.CommandLineArguments(String[] args) in C:\Users\KTSno\Documents\GitHub\otterkit\src\Otterkit.cs:line 115
at Otterkit.Otterkit.Main(String[] args) in C:\Users\KTSno\Documents\GitHub\otterkit\src\Otterkit.cs:line 27
zsh: abort otterkit build --run -e hello.cob --free

To Reproduce
https://gist.github.com/birojnayak/6b939399336ac80da8e50a47e58ae8de <= CobolFile

ran this command
otterkit build --run -e hello.cob --free

Expected behavior
Expecting CS file

Screenshots
If applicable, add screenshots to help explain the issue. This could be terminal screenshots that can help us find the source of the issue.

Platform Information (please complete the following information):

• OS: Mac
• OS Version [e.g. Ubuntu 22.04]
• CPU Architecture [e.g. x64]
• Libotterkit Version 1.0.70

Additional context
Add any other context about the problem here.

[KTSnowy]

Hey @birojnayak, have you used the Nuget package or the latest commit from Main?

[birojnayak]

@KTSnowy I simply followed the https://github.com/otterkit/otterkit#quick-install

[KTSnowy]

Hey @birojnayak, I managed to reproduce the issue. The problem seems to be with the --free command line option not correctly switching the compiler to free format.

Running Otterkit with the following command otterkit build --run -e hello.cob will successfully compile and display "hello" (using source format autodetection)

I'll work on a fix for this issue and I'll let you know as soon as I upload the updated version.

In the meantime could you try updating your Otterkit version to 1.0.75 and running the above command without --free? I just uploaded that version to NuGet and wanted to see if it's also working for you without the free format option.

[KTSnowy]

Newest version from NuGet should be working now: https://www.nuget.org/packages/Otterkit/1.0.80

Just made an updated version with the fix.

The preprocessor needed the following lines to check if a source format (other than auto) was specified.

    if (CompilerOptions.Format is not SourceFormat.Auto)
    {
        HasDetectedSourceFormat = true;
    }

Previously it would continue with HasDetectedSourceFormat set to false, which caused it to default to fixed format (during auto detection) even if a user specified free format.

It also skipped most of the auto detection checks because source format was not set to Auto anymore.

[birojnayak]

The first demo works(thank you). Now I am struggling with this one https://gist.github.com/birojnayak/4bd0d4332d98170f74803b3e217ca4f8 .

biroj@88665a0182c9 transform % otterkit build -e demo.cob

Analyzer Error [COB0027]: End marker, Missing END PROGRAM marker.
╭─/> [demo.cob:1:34]
│
1 │ PROGRAM-ID. Demo-For-Cobol.
│ ~/> Expected a source unit end marker after this token
│
────╯
Compilation process cancelled due to an analyzer error


[KTSnowy]

The AUTHOR paragraph is currently not supported, it was removed from the language after the COBOL 85 standard. The parser doesn't recognize the keyword and jumps to the end of the source unit parsing.

We want to support extensions (and older syntax) through an --enable-extensions command line option, but right now we don't have enough developer resources to work on both the COBOL 2023 implementation and additional COBOL 85 syntax and extensions.

We wish we had more resources to be able to work on more than one thing at the same time.

Due to limited resources we can also only work on the parser right now (working on name resolution), and work on the codegen would have to wait until we finish name resolution or until we get more resources to work on both the parser and codegen.

Because of that, the 01 SsnNum. group item and the COMPUTE statement in the gist link will both fail to compile (codegen for both is not ready yet).

We hope we can get more contributors and maybe (open source) company support soon so that we can work on more than one thing and get Otterkit working and stable sooner.

@birojnayak would you like to help us with the codegen a little bit while we work on name resolution?

[KTSnowy]

I'll add parsing checks for the AUTHOR paragraph so that Otterkit doesn't completely fail when trying to parse them.

With error messages if --enable-extensions is not passed to the build command.

[birojnayak]

Ok close this once you fix the Author paragraph.. I am also creating few more issues based on my finding.

[GitMensch]

Is there an update to this issue?

[KTSnowy]

Hey @GitMensch, unfortunately I will have to stop developing the COBOL compiler, the Otterkit project will be repurposed towards developing a different language.

Overall I have found the COBOL standard to be severely underspecified and having too much implementation-defined behavior to make a Standard COBOL implementation possible. That together with the fact that I cannot contact the committee at all to ask for clarification makes the goal of the project, to build a Standard COBOL implementation, extremely hard if not completely unattainable.

Also I tried asking you for help 3 months ago with the external typedefs, but it seems to have been mostly ignored. I still have no idea how to resolve some of those issues, or how exactly they are meant to work.

[GitMensch]

Please drop at least a note to the GnuCOBOL Lounge, once your decision is final.
I also ask you to please rename this repo, possibly otterkit-cobol, adjust the README (potentially sending people to GnuCOBOL as an industrial-used general-prupose compiler and to gcobol as a "new" compiler targetting COBOL2023, partially COBO85 and extensions" and put it on "archived" - instead of "directly re-purposing it" (you can then re-create an otterkit repo, either as a clone from the other one or "from scratch", copying in only the pieces you need..

As noted before, you should be able to contact your national standard body for any clarification (or contact details) about a standard they have given their OK to as part of ISO.

[KTSnowy]

Please drop at least a note to the GnuCOBOL Lounge, once your decision is final.

I'll make one once I figure out what I should do next.

and put it on "archived" - instead of "directly re-purposing it"

I put the COBOL compiler code in an ARCHIVED branch, I'll see if I can rename the repo and fork it with the "otterkit" name.