| bin | ||
| docs | ||
| images | ||
| integration | ||
| lib | ||
| tests | ||
| .gitignore | ||
| .rdoc_options | ||
| demo.rb | ||
| fOOrth.gemspec | ||
| fOOrth.reek | ||
| Gemfile | ||
| license.txt | ||
| rakefile.rb | ||
| README.md | ||
| reek.txt | ||
| sire.rb | ||
| t.txt | ||
| test.foorth | ||
The fOOrth language is an experimental variant of FORTH that attempts to incorporate object oriented and functional programming concepts. It also tries to extrapolate an alternate reality where FORTH was not frozen in the past, but continued to grow and develop with the times. Above all this project is the result of nearly 30 years of thought on the design of threaded compilers and languages with simplified grammars and syntax.
Usage
Adding fOOrth can be as simple as:
require 'fOOrth'
XfOOrth.main
This will launch an interactive fOOrth session. Alternatively this can be done with:
rake run
Be sure to be in the folder that contains the rakefile in order for this command to work.
If, instead, a non-interactive facility is required, use:
require 'fOOrth'
XfOOrth.virtual_machine.process_string '1 2 +'
where the string is fOOrth code to be executed, or for a file of code, use:
require 'fOOrth'
XfOOrth.virtual_machine.process_file 'my_file.foorth'
Further Documentation
The fOOrth Language System is documented in The fOOrth User Guide. This is currently only available in Open Office format, and is still also very much a work in progress. Please see The_fOOrth_User_Guide.odt in the docs folder.
Also for those who do not have or don't want Open Office: As each major version of fOOrth is made available, expect to see portable document format (pdf) versions of the guide. (In the docs folder in the repository)
Contributing
Plan A
- Fork it
- Switch to the development branch ('git branch development')
- Create your feature branch ('git checkout -b my-new-feature')
- Commit your changes ('git commit -am "Add some feature"')
- Push to the branch ('git push origin my-new-feature')
- Create new Pull Request
For more details on the branching strategy, please see: http://nvie.com/posts/a-successful-git-branching-model/
Plan B
Go to the GitHub repository and raise an issue calling attention to some aspect that could use some TLC or a suggestion or an idea. Apply labels to the issue that match the point you are trying to make. Then follow your issue and keep up-to-date as it is worked on. All input are greatly appreciated.