Contributing guidelines?

[AndydeCleyre]

Hello!

I'd like to contribute a new language example, but I have some questions about contribution expectations:

• is it required to include the same Mozilla public license I'm seeing in the other examples?
• if the example can either be compiled or run more like a script, should both be reflected in the run file, or just the compilation route there while leaving a nice shebang on the source file, or what?
• if the compiler is not commonly packaged, should the run script download it, or instead download its source and compile the compiler itself?
• any other notes new contributors should be aware of before submitting a PR?

Thanks!

[c4augustus]

• MPL 2.0 is preferred but any original source that you provide can be under a more permissive license if you prefer, or none at all. Note that other authors may replace/rewrite your original work in the future. BBHW is not mission critical software but rather meant to be instructive. We will try to keep credit to original authors intact. Those who provide the first implementations for a language will definitely have the advantage, unless/until others provide significant improvements.
• A simple "run" shell command, like in established examples, is definitely preferred, for ease-of-use. As to running like a script, it doesn't matter as much as long as the UX is effectively the same. For example, Erlang can be coded entirely within an escript or the run command can launch erl and pass commands to launch a separate program file, thus from the user's point-of-view it is a similar experience. In cases like that it would nice to have both approaches though to show the differences, if any.
• auto-download and compile is not a requirement, but it is definitely my preference. This is obviously not possible for proprietary implementations (e.g., Dyalog, Mathematica, et. al.) or "open source" implementations that aren't actually buildable without downloading binaries releases (looking at you Rust).
• Each language may have many alternative BBHW implementations as you may have already seen, each with a name qualified in some way (bbhw-wordy.ext, bbhw-golfy.ext, etc.), so you are not likely to lose anything you submit other than possibly having it renamed. We reserve the privilege to decide which gets to be the most idiomatic default, just bbhw.ext

[c4augustus]

Adding to the auto-downloading and building inside the run script, it will only be allowed for downloads of source from bonafide repos, either the official home repos of language implementations or one of our own forks. We will not allow or promote the auto-downloading of anything binary or build scripts that download binaries (looking again at you Rust).

[AndydeCleyre]

Thanks!

Can you clarify this bit?

In cases like that it would nice to have both approaches though to show the differences, if any.

Would that look like two run files, or one run file that uses one method while the readme shows the alternative, or one run file that takes a flag to choose the method?

[c4augustus]

Make one run file for each and pick which ones are the default. So for example if script is not the default than "run" and "bbhw.ext" are the default and "run-script" and "bbhw-script.ext" are the script-based alternative; or something like that.