Juergen Kuehlwein wrote:
If i interpret Jeff´s post right (correct me, if i´m wrong), his goal is to make the global namespace initially empty, that is, to put all existing statements in a namespace, which must be activated (using ..., or explicit prefix "fbc." or the like).
Where (I think) you are wrong is that you assume that the minimal situation is something that an average user will ever see. Usually the extreme minimal configurations are for things like bootloaders, to tie into the windows device driver SDK, or compiling the RTS (once it is 100% FB). The minimal state is not necessary the default
IOW, the default startup scope will be that minimal state, augmented with some default options that enable additional compiler state + the default header/namespaces. And that can be whatever you want it to be, and both are subject to parameters. It is just that the very minimal compiler principle will make other (more minimal, but also more elaborate) alternate startup states possible because every end situation is the result of a minimal state and certain additions, never subtractions. Also move as many of the predefined identifiers (keywords, reserved or whatever) to headers rather than builtins. It is simply more flexible that way.
Forgive me, if I compare to FPC again, its default state would be QB (well, Turbo Pascal in our case, but same era) minus some very dos and 16-bit oriented stuff (like port handling, segment and offset stuff etc). Yes. That is the FPC default startup state, and it was that way in 1998, and it still is, even though the bulk of developers have shifted to the VB(read: Delphi) dialect or variants.
IOW the default adds all clean QB keywords and namespace over the default scope, but if parameter -XX is passed to the compiler it won't add anything. And if parameter --ImAnOldFart is passed, the non-clean QB stuff will be added too.
My point was not to remove all statements, but to leave at least the core language (FOR ... NEXT, IF, SELECT, ...) always in the global namespace.
I think those would indeed remain. Rule of thumb is to keep all keywords that are common to most dialectsand require elaborate helpers.
And maybe reduce the number of default statements in the global namespace by putting topic related statements like graphic, file, console, etc. in separate namespaces. Not everyone wants to use graphics or the console in a program, or wants to read or write to files.
True. If only because by default proper Windows GUI programs don't even open an console. It is wise to not fall for the *nix pitfall and assume a console is always there.
Jeff´s proposal would make heavy use of the USING statement or explicit prefixing a requirement, which, and this is my personal opinion, would make code look ugly - at least not more readable.
As said not necessarily. Usually for the default startup state some popular dialect is chosen, and the compiler enables additional keywords and adds implicit USINGs (IOW that the user doesn't have to type). But keeping the core free of such concerns means that other parameters can NOT enable those.
Additive parametrization is easier to test in isolation than subtractive. If you choose a more complex base state and then try to hide based on parameters, then every time the base state changes, you have to validate all parameters.
In the additive situation, the compiler base state rarely changes, since even if the default compiler startup scope changes, it is more likely to be in a library. Or implemented in the parameter layer by default setting some mode unless a parameter is added.
Restricting the need for USING or explicit prefixing to certain distinct categories of statements would make it more acceptable in my view. In procedural and in object oriented code i would like to handle different things in different procedures. It would be of help to be able to handle certain related things inside a procedure or method without the need of switching namespaces to and fro all the time. In other words in most cases one single USING statement per procedure would be sufficient, which seems acceptable and reasonable.
The default startup state is political and a matter of taste. Progressive and conservative forces will always war about that. But this is not about that, it is about having the internal architecture to easily make and manage several such modes, regardless of which one is default or parameter.
As a personal point, I would however advise to clean the worst and most dated things from the default state. People that want them then must add additional dialect options (e.g. --QB-FULL) or so. And keep an eye open for multi-dialect programs (selected dialect a per module basis)