Imortis wrote:
FBC does some magic that would be cumbersome/impossible to duplicate in a standalone library. For Example:
Print is not 1 function. It is not even 3 functions (print, print #, print using).
Because of all the qb quirks, an awful lot of the RTLIB NEEDS to be passed through the compiler to maintain its usefulness.
In a more advanced stage, you can still mix that. E.g. only enable certain intrinsics/built-ins after a dummy declaration with a special attribute in an header.
Maybe in-order for the RTLIB itself to become more consistent (even with itself in some cases) it would need to be restructured quite a bit and quite a few quirks either standardized (used everywhere) or dropped (used nowhere). This has made me re-consider putting the rtlib in a namespace by default, at least for now. As it stands, it could make things MORE confusing rather than simplifying things, but I do think that other new features could stand to be added in new namespaces so as to keep the global namespace clean.
I think a first step would be to do what you can do to modularize the RTL and the default namespace, and then enable some implicit namespace for the existing language modes so that the result remains transparent to the user.
It doesn't matter than that some things are built-in, and some things are purely a library invention, as long as they appear in the default namespace as the user expects.
Or maybe even better, distribute all functions in the RTLIB that are plain functions into groups. And find some way to combine them into the default namespace (e.g. by including several headers by default, or have a per dialect mode header that include the group headers).
Later you can worry on per dialect enabling/disabling of builtins using headers, or some other ways to enable/disable built-ins per dialect, but that will always require compiler work.