Ideas for a Standard Library

[TriAttack238]

Note: This was originally an issue, until I was notified that the discussion board was a better place for it.

The Otterkit Standard Library Idea

While modern COBOL has made great strides from the 1985 standard that still colors public perception, there are still a few holes where the language does not quite match up to modern standards and expectations. Therefore, there is the idea for a standard library written in 2023 Standard COBOL that is attached to the compiler. However, we need ideas, which is where this issue thread comes in.

And while every major COBOL vendor has chosen to extend and embed functionality directly into COBOL syntax, this has proven to not be ideal given the amount of incompatible dialects (sometimes with conflicting extensions). It would be much more beneficial to strictly follow the Standard COBOL syntax and provide additional methods and functions through a standard library.

COBOL is capable of conditional compilation similar to C, so any dialect could potentially benefit from this library as long as the compiler implements the required preprocessor directives and help is provided to figure out the differences to make it work.

How to format ideas.

If you have an idea for an addition to the standard library, your proposal needs three important aspects:

1. What is this feature? Are there any examples from other languages that implement this feature well in their standard libraries or elsewhere? What use cases does it serve? Should this feature be in the standard library(ie benefit a majority of projects/developers)?

2. How exactly would it work? You don't need to write a full college essay, but some clarification on expected behavior and maybe internals would be great. How would it fit in with the rest of the standard library and COBOL's language philosophy as a whole?

3. How hard would it be to implement? Everything takes work and time, and it's important to think about the resources it takes to implement a feature before going ahead with it. For example, while true randomness would be cool, breaking a constant server connection to a cosmic ray detector or lava lamp camera is cool but impractical, to say the least.

However, that is not usually the end. Other commenters can discuss and suggest modifications to the idea as they wish, within reason.

The First Idea

This is not only a legitimate proposal for the standard library, but an example for future proposals.

Idea: Dynamic Data Structures.

1. COBOL's tables work just as well as arrays in other languages, as structures of predefined length for variables of the same type. However, nearly every programming language in the modern day also has Dynamic Data Structures: structures that order data but do not have a set length. These are perfect for handling an unknown amount of elements, which is quite often. I propose to add not one but two dynamic data structures to the standard library: Vectors(Dynamic Arrays) and Linked Lists.

2. Both structures will be classes in the standard library that generate mutable objects. These objects will be able to store virtually any number of values of the same type. Structures will also support concatenation with tables and their own type(as in type of structure and type of value), along with stack-like properties(more on that later). These structures can also hold other structures, such as a vector holding another vector of a linked list. Assume all methods are for the instance of the respective class unless told otherwise. First, Vectors:

• Vectors are dynamic arrays, which means that under the hood vector objects contain a table, and that table is swapped out for a smaller or larger one when needed. According to this youtube video, these tables should be some multiple of 2 larger or smaller than the initial size of the internal table(which is 1 by default) for efficient resizing. So if the internal table is 4 items long and completely filled, a new table 8 items long will be created and all of the values of the last table will be carried over. Additionally, if an internal table 16 items long that has 8 items but 1 item is removed, it is now at less than one-half capacity and the new internal array will be 8 units long. Unlike linked lists, vectors will be indexed, sliced(creating a smaller vector with an indexed subset of elements), and insertion and deletions by index.
• Linked lists are composed of object nodes that reference each other. I am specifically talking about Doubly-Linked Lists, where nodes can both access the previous node and the next node. However, the first node references when initializing the list always start with the first Head node, and the following nodes must be traversed with a next() or prev() method on each node.

While it is technically possible for each node of a linked list to have a different type, in my proposal each vector and linked list will only hold one type of value using COBOL's generics system. Whether this includes interfaces or just regular types and classes I am sure.

These structures will also have methods that consider the structure as a whole, such as a static equals() that checks if two structures are of the same type and values, and a contains() method to check if a certain value exists in a structure.

These structures will also implement the stack interface, which will allow users to use the push() method to add a value to the end of the structure, and a pop() method to remove a value from the end of the structure and return the value. The linked list structure can also push and pop at the beginning.

3. While it is a lot of work to implement these features, vectors and linked lists are nothing new to the world of computer science, so they should be relatively easy to implement. Additionally, COBOL's high-level language features such as garbage collection and generics should make implementation less of a hassle compared to a language where precise memory management is a priority.

And that is finally the end. Now, any questions or comments?

[KTSnowy]

Suggestion: SQL Database Connection Support

1. We strongly believe that functionality like executing SQL statements should not be embedded as a COBOL statement like the EXEC SQL extension. it should be provided as a library for a specific database, which allows for any DB provider to create their own instead of being stuck with a single one as a built-in extension statement.

2. The EXEC SQL extension statement might also conflict with other implementations. Some databases have a slightly different SQL syntax, meaning that we would have to choose a single database to support which is not ideal (or the parser would have to parse multiple SQL dialects, this is terrible for the parser's maintainability).

3. With standard COBOL's OO syntax we could have a class called Sqlite (or any other database name) that handles local and remote connections as well as executing SQL statements from concatenated strings (with methods to sanitize input when needed). This provides a lot more flexibility than the EXEC SQL extension.

We'd still have to choose one database for initial support, but after that it could be used as a reference implementation to support other databases. Extending it would also be a lot easier because we won't have to touch the compiler or runtime at all, only the library code.

[TriAttack238]

Would these be wrappers over C# APIs?

[KTSnowy]

@TriAttack238, Depends on which database we choose to support first. If it's something that's available as a C# API we could make a wrapper over it.

Do you have any ideas for which database we should support first?

[TriAttack238]

I would go for the big open-source SQL databases first: MySQL, MariaDB, and Postgress