koczkatamas
commented
6 years ago These are the preliminary steps for implementing StdLib support.
Stage 1 - Split current libs into packages
As a first step remove standard library related entries from the language YAML files, more precisely the root > classes node.
Add a packages folder and various packages as subfolders, eg. One.Reflect-v0.1 and put a package.yaml file there with metadata and the current inline implementations (alternatively put inline implementation separately). Also put language-specific files there (eg. One.Reflect.cs).
It would be good if the WebIDE could download multiple files at once, so we don't have to execute thousands of requests. Conveniently it could be a JSON payload generated at a publish step (for now) + an endpoint on static serve.
In this stage we just concatenate the various StdLib parts into one file (order matters for eg. C++!).
Interfaces and implementations maybe should be already separated at this point already (but still without tests).
Stage 2 - Add interface support + tests for existing stdlibs
Somehow separate interfaces and implementations. The best would be handle them separately: separate folders, separate API endpoints, separate package formats. I see no advantage to mix them together.
Then add tests and add test runner for current implementation.
Stage 3 - Create repository server + API endpoint for uploading / downloading packages
Authentication: some really simple (eg. Google / Github OAuth, no user reg.) OR no auth at all, only fetch Github repo and process package.yaml file and other repo files.
Then make it possible to download packages automatically if they are missing a local packages folder (a version cannot be overwritten, so we will exactly know what's missing).
Stage N
TODO
qwertie
The issue
OneLang does not really come with standard libraries (StdLibs) or more precisely wrappers around other languages' standard libraries.
One of the reasons is that providing a standard library is an enormous effort and requires a lot of time which is better spend on the compiler itself.
Other reason is that the choice is not clear in some cases: if the target language does not support a functionality then you have to use a library for that and if there are more wide-spread libraries for that purpose then it could be that OneLang would use one of them, and your project would use an other one and this could cause various conflict and issues (including you'd need to use two dependencies instead of one, etc.)
So I propose the following schema:
The plan
Creating (standard?) libraries for One will be a decentralized, community effort.
But we cannot expect from anyone to learn 11 languages and their standard libraries and create wrappers for all of them. I would expect most of the users will only use One for only two or three languages, so there would be incentive to create wrappers for just that many languages at once, not more.
So we split a StdLib wrappers into interfaces and implementations.
The interface and the implementation
The interface describes the classes, methods, parameters, input and output entities and their behaviors without a concrete implementation.
Emphasis is on the behavior as an interface comes with unit tests and these tests define the contract between the library's creator and the library's user: these show you what you can expect from an interface.
Instead of writing down in a textual form on a documentation website what this and that method should do if we pass this and that parameters, we write it down in tests!
If there is no test for an edge-case then it's an undefined behavior and you cannot assume that it will work as expected or work at all.
You can then publish an interface to a centralized repository (provided by onelang.io) where users can find your interface and start using it. The more users use your interface it has the better chance that others will create an implementation for it and vice versa: if you create an interface based on your implementation and your implementation becomes the popular one then you have a better chance that your interface will become the popular "standard" one as well and implementations supporting other languages will be created for your interface.
An implementation can implement one or more interfaces. It may depend on some external library which comes from the target language's dependency manager (if that exists), so its usage will be streamlined into the development process of the target language.
Also an implementation can only be published to the repository if it passes the tests specified by the interfaces it implements.
Wut
The whole concept may sound weird at first, but hopefully it will be an iterative process where we will converge to more and more better libraries.
It may come hard to some who are accustomed to a strong, centralized vendor who provides a well-tested, standard library for all their basic needs, but on the other hand, in some languages, it's usual that for even the basic needs (eg. JSON parsing) you need a third-party library and it's your decision and risk taking which one to use. I don't think this situation will be much different.
Some libraries will prefer staying backward-compatible and staying faithful to their existing users, while others will decide to give a better, cleaner interface and attract new users easier. Or to be frank they may kill two birds with one stone: they can implement both the old and the new interface while keeping the interfaces completely invisible to the other interface's user base.
State of affairs
These are just plans, nothing concrete have been implemented / tested.
Comments / questions are welcome.