Initial Algol 68g implementation

[rzuckerm]

Description

Initial Algol 68g implementation.

Contributing requirements

• [x] I read the contribution guidelines in CONTRIBUTING.md.
• [x] I placed my solution in the correct solution folder.
• [x] I added a README.md with the right badge(s).
• [x] I added a Dockerfile that builds and runs my solution.
• [x] I selected drag-race as the target branch.
• [x] All code herein is licensed compatible with BSD-3.

[rzuckerm]

@rbergen I think I addressed all your comments. Please approve the workflow so that I can see if anything else needs to be changed. Thanks!

[rbergen]

@rbergen I think I addressed all your comments. Please approve the workflow so that I can see if anything else needs to be changed. Thanks!

I don't think I agree, for the following reasons:

• You've now marked your solution as faithful, which I explained it (currently) isn't. As it stands, this will need to be reverted.
• I don't think we've come to a conclusion about the appropriate number of bits per prime yet (1, another number, or unknown).

My apologies, I overlooked some of the changes you made when I wrote the previous text. My actual response is that I don't think we're there yet, because a CHAR definitely does not have a bit size of 1, but at least 8.

A question I have is if you've definitely established that a "delete" of an instantiated struct is not something you can trigger?

I'd (still) really like to have a "semifinal" version of the solution (i.e. one without open topics) in place before I trigger CI. Otherwise, it will have to run after every change that is made, even if it only concerns documentation.

[rzuckerm]

My apologies, I overlooked some of the changes you made when I wrote the previous text. My actual response is that I don't think we're there yet, because a CHAR definitely does not have a bit size of 1, but at least 8.

I change the bit size to 8

A question I have is if you've definitely established that a "delete" of an instantiated struct is not something you can trigger?

Algol automatically implements garbage collection, so there is no way to directly trigger a delete. However, garbage collection can be forced with the sweep heap function. I have added this. I also added some heap debugging to show how many bytes were recovered due to garbage collection in the main loop. This is currently disabled, but I ran it once with it enabled, and here's what is showed:

                                  +0
                            +4000664
                            +4000664
                            +4000664
                            +4000664
                            +4000664
...

[rbergen]

I really appreciate you triggering the garbage collection manually, but it's not necessary to take it to that level. We don't demand this of any other managed memory language/platform either. At the same time, I think your debug run actually shows that the number of bits per prime is not 8, but 32; the sweep heap function seems to clear a little over 4 million bytes for 1 million prime candidates. Which makes sense if the CHAR type actually represents UTF-32 characters.

I'd like to propose the following:

• Switch the prime candidate type back from CHAR to BOOL.
• Use the sweep heap/heap debugging combination to determine the size of the BOOL type. Base the bit count in README and program output on that.
• Remove the sweep heap and anything related to heap debugging from the source code.
• Commit one more time with these changes in place.

After these changes have been made, I'm happy to trigger CI and move forward towards merging this.

[rzuckerm]

I changed back to BOOL, and the heap didn't change by much:

4000896

Since I only store odd values, there are only 500000 bins. Based on this, it looks like it might be 64-bits, which seems really wasteful. :frowning_face:

[rzuckerm]

I'm just going to use unknown and be done with it. I suspect, the value changes based on machine word size, which is 64 for my case.

[rbergen]

It would be wasteful. It could just be that under the hood, every integer type is implemented as a "long int". I have seen that before. You may also be right that it is machine dependent. I'm happy to accept your findings as support for a prime candidate bit size of 64, but you can also choose to stick to "unknown" as you seem to prefer. Do note that in the benchmark output line that the program outputs, the "bits" flag then needs to be removed. Its absence in the output is the indication that the actual bit size is unknown.

[rbergen]

I've taken the liberty of removing the flag from the benchmark output myself. I hope that's ok. It does come with the benefit that CI is triggered immediately.

[rzuckerm]

Looks like the CI worked. Thanks for your help @rbergen !