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

Create a new repository for the language specification of Brain-Flak #41

Closed
1000000000 opened this issue Sep 8, 2016 · 2 comments
Closed

Comments

@1000000000
Copy link
Collaborator

I've been toying with the idea of writing an interpreter for Brain-Flak in C. I feel it would be nice to create a thorough language specification to aid the in the creation of interpreters (a javascript interpreter would be quite nice).

@DJMcMayhem
Copy link
Owner

It's funny that you mention that, because I have actually been thinking about writing a javascript interpreter for a while now. :) I agree that it would be nice to have a specification, but I don't know if it's worth making a separate repository for it. Is the description in the README not precise enough? I suppose one thing I can think of that the current version does that is left unspecified in the README is how the value of the {} is not reset after each loop. (which is why {{}} can sum the stack). Beyond that, there are some things I don't think we necessarily should specify, and instead leave that up to the interpreter. For example, I think ASCII mode is worth specifying, but I'm not sure if we should inlcude things like

  • File input VS command line args
  • Alternate overflow/underflow modes
  • Debug flags
  • Unicode mode
  • Separate input and output formats (To allow for decimal in ASCII out, or vice versa).

Not that any of these are bad features, I just view them as interpreter perks.

@1000000000
Copy link
Collaborator Author

Actually the differentiation between specifications and interpreter perks was the main thing I was interested in seeing in the specification. Namely how overflow/underflow should work and what the minimum maximum height of the stack should be.

As for about being in a separate repository, I felt that commits that tweaked the specification would create clutter when looking through the history of the repository as updates to the example programs have done (one of the things I have been meaning to do for a while is to migrate the example programs out of the README and into this repository's wiki). Speaking of the wiki, I was taking a look back at how it works and I was thinking that it might be the ideal place for such a thing (I had previously overlooked the wiki because I thought that it did not give you the ability to leave a description attached to your change like a commit message, but it turns out I was mistaken).

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

No branches or pull requests

3 participants