issue-#29 inconsistent checks for valid subsystem names

[Josef Templ]

This issue is about fixing inconsistencies in the syntax check of valid subsystem names.
In addition, Unicode support needs to be added. This was forgotten in issue-#19.

@Helmut, I have assigned this issue to you in redmine.
Can you try to work on it in the standard way?
1. create a topic branch in github
2. clone the repository and switch to the topic branch
3. make the modifications locally
4. commit the changes locally
5. push back the changes to the topic branch
6. post a message in this topic when you are done or whenever there is some need for discussion
Let me know if I can help you in any way.

If only the modules DevSubTool and DevLinkChk are involved, there are
no merge conflicts to be expected.

- Josef

[Josef Templ]

Since nobody picked up this issue, I started working on it.

When looking up the docu I found in Docu/Tut-3 an explanation of subsystems and I also found an
inconsistent definition of the subsystem syntax there. This also needs to be fixed.

The correct definition IMHO is that the first transition of a non-uppercase character to an uppercase character
defines where the module name starts. In addition the complete name must be a valid identifier of CP.
This at least how it is implemented in the compiler and loader.

Surprisingly, I did not find the subsystem feature anywhere outside this tutorial.

- Josef

[Bernhard]

Surprisingly, I did not find the subsystem feature anywhere outside this tutorial.

yes, but I found several references with "-> 7.2 Modules and Subsystems"

It appears to me that these references should be changed to "3.2. Modules and Subsystems"

[Josef Templ]

thanks for the hint, Bernhard.
The inconsistent references are now fixed.

- Josef

[Josef Templ]

sorry, I accidentally merged issue-#29 when I actually wanted to merge issue-#28 to master.
This issue is of course still open and we can continue to work on it.

- Josef

[Josef Templ]

A valid subsystem name has no limitation on the number of characters until some undocumented
internal maximum is exceeded.
In particular, there is no minimum length of 3. This can be regarded as a convention, though.
In addition, a valid subsystem name does not need to start with a capital letter.
Again, this can be seen as a convention.

Our current DevSubTool checks for a minimum length of 3.
The BB1.6 DevSubTool also checked for a starting capital letter.

I am not sure how strict the checks in DevSubTool should be
or if we should introduce a warning instead of an error message in case
of violating a convention.

CPC1.7 increased the max. subsystem prefix in DevSubTool from 8 to to 15 characters,
which is reasonable. I think we should also use this limit in DevSubTool and DevLinkChk.

I found a missing check in SyntaxOk and added it to the implementation.
The problem was with subsystem names that consist of leading capital letters only.
The missing non-capital letters were not detected.
Please have a look at the diffs at
http://redmine.blackboxframework.org/pr ... c0a1/diff/


- Josef

[Josef Templ]

Are we ready to vote on issue-#29 (inconsistent checks for valid subsystem names)?

The fix also includes changelist item number 10 from CPC 1.7 rc5
(increasing the max. subsystem name length from 8 to 15 in DevLinkChk and DevSubTool).

The changes are fully compatible with BB 1.6.

- Josef

[ReneK]

I am not sure how strict the checks in DevSubTool should be
or if we should introduce a warning instead of an error message in case
of violating a convention.

I'm not sure. I haven't looked at the issue much, but just from the top of my head:

If subsystems need not start with a capital letter, do modules need to? And how do we safeguard against

Subsystem abc
Module def
AND
Subsystem ab
Module cdef

in the same BB system, where the system probably cannot discern which one to take.

Or:

Subsystem A
Module BCde
AND
Subsytem AB
Module Cde

Does this make sense? Doesn't it make the compiler/Linker more complex?

[Ivan Denisov]

What if we prohibit to start subsystem from lower-case?

This makes code less readable, because from lower-case are starting the constants and variables.

Code: Select all

someThing.Do;

for me this is some variable with POINTER TO RECORD type which has method Do!
However now it can be subsystem some with module Thing with PROCEDURE Do*();

I understand that some subsystems are already violating this rule, but if you will look here http://www.oberon.ch/blackbox/subsystems.html
you will not find any subsystem starting from lower-case.

[Josef Templ]

Thanks for the feedback.

Starting the subsystem prefix with an uppercase letter has never been enforced by BlackBox.
All you need is a valid CP identifier for a module, no matter how long it is and with
which letter to start. The subsystem prefix, which is the leftmost part of the module name,
ends at the first transition from non-uppercase to uppercase. Without such a transition there
is no named subsystem involved. This is enforced by the compiler and loader.
We should not change this. There may be private subsystems of any names
out there. There is no need to introduce an incompatibility because it does not solve
any problem. Every additional rule is a convention very much like starting
local variables with lower case or procedures with upper case.

With the changes in issue-#29 the modules DevSubTool and DevLinkChk stick to the rules
enforced by the compiler and loader. At least this was the intention.
In addition, the minimum length of 3 characters is enforced by DevSubTool.
In my opinion, it should be changed to a warning. There should also be a warning for
subsystems that start with a non-uppercase character.
In DevLinkChk there is no need for such warnings because it does not create
new subsystems but operates on existing ones.

- Josef