Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Output standardization and formatting #864

Closed
stormofice opened this issue Sep 12, 2021 · 6 comments
Closed

Output standardization and formatting #864

stormofice opened this issue Sep 12, 2021 · 6 comments

Comments

@stormofice
Copy link
Contributor

This is related to: #824

The current accepted solution to format output looks somewhat like this:

[#] Informational [and human readable] output
10.0

While this works fine for simple outputs, it does not really transform very well for more formatted output [like tables] as you can see here:
computus output, which is misaligned
The table header is shifted four characters to the right, which breaks the alignment with the actual values below.

As human-readability is important for the AAA, this should be formatted in a better way, so the header conforms to the values below properly.

Now there are several ways to circumvent this, some better and more practical than others:

1. Allow [#] to occur at the end of the string

This may introduce some inconsistencies, as there could be a mix of implementations using [#] at the end instead of the start, but it would be a pretty simple fix for these kinds of issues.

2. Use some kind of zero-width unicode character

It would be possible to print out a unicode character which takes up no space, such as the zero-width space.

Now this has the big advantage of being invisible to someone just executing the implementation or looking at its source code.

However it would be very unintuitive for developers, as you need to copy paste the char in front of every string and depending on the IDE/Text editor this may be more or less difficult. It also may not be displayed properly on GitHub (which makes reviewing harder) or in terminals that do not support non ASCII chars.
Older languages and esolangs may also not have support for unicode characters.

3. Use some kind of control ASCII character

This is basically the same as above, but instead of using a unicode character, it would be possible to use C0/C1 ASCII control codes.

All the points above (unintuive for developers/reviewers, difficulties with rendering) do still apply, but nearly every language does support ASCII.

However this does not seem to be a suitable solution, as these chars often get rendered like this:
control char shown as question mark in box
While I haven't tried all of the control characters, it looks like they all get rendered the same (which disqualifies them, as they are not zero-width in nature, which was the original goal).

4. Use smaller character to indicate non-result output

It would be possible to use | instead of [#], which would mitigate the problem as it does not shift the output as much.
However it would not be that clear to the reader why it is there and it does not look as good as the original solution.


None of these ways seem ideal to me, but currently I think that the first or fourth way would be the best, as the others do have major limitations which may have unforeseen impact in the future.

As this is kind of blocking the output standardization, comments and thoughts on this would be greatly appreciated.

@Amaras
Copy link
Member

Amaras commented Sep 12, 2021

I'd think using [#] at the end of all control strings would be a better idea, and we would need to remove inconsistencies afterwards for the already-standardized one (I think it's a bit of work, but not that bad, except for annoying languages).
You really can't use | for now, because of the way the Computus table is displayed for JavaScript... As it uses console.table(values);, the output uses | for everything...

@leios
Copy link
Member

leios commented Sep 15, 2021

As a naive question, would it be possible to have the character be [#]\n instead of [#]? This way we don't have to change things too much, and can still get readable output?

The other comment here is that we need the tables to be consistent for each implementation so that they can be properly verified. Should we create a "print table" command and put it in some sort of "aux code" directory where we can also put any code that is necessary to format output for the validator?

@stormofice
Copy link
Contributor Author

stormofice commented Sep 16, 2021

As a naive question, would it be possible to have the character be [#]\n instead of [#]? This way we don't have to change things too much, and can still get readable output?

It would be possible to use [#]\n, however in my opinion it clutters up the output a bit, as we would now have two lines without the actual result, see:

[#] 
Result One:
400

vs

[#] Result One:
400

vs

Result One: [#] 
400

I don't have strong feelings about any of these options, but I think that more concise output should be favored.

The other comment here is that we need the tables to be consistent for each implementation so that they can be properly verified. Should we create a "print table" command and put it in some sort of "aux code" directory where we can also put any code that is necessary to format output for the validator?

While it would be possible, this would require a print table function for every language which would need to be included in every implementation printing this (adding non algorithm related code to the implementations).

There has already been some discussion on this topic on discord [here] (related to how lists get printed out) and the outcome was that writing a parser which accepts lists/tables from multiple languages and transforms them into a more consistent format should be done.
This way no implementations would need to get changed and it would not be required to print out lists/tables in non language-idiomatic ways.

@leios
Copy link
Member

leios commented Oct 9, 2021

I am still pushing for the [#]\n character as it makes formatting tables in the terminal slightly easier; however, I am happy to be overruled.

@leios
Copy link
Member

leios commented Oct 9, 2021

Also note that we need to add this to the how to contribute wiki as well

@stormofice
Copy link
Contributor Author

Okay, as we decided on using [#]\n #855 and #857 need to be reworked as they are currently using the old style. Apart from that, nothing stands in the way of output standardization. I'll update related issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants