first cli stub

Author: Matthias Wahl

.gitignore

@@ -0,0 +1,2 @@
+/.deps/
+/build/

CODE_OF_CONDUCT.md

@@ -0,0 +1,70 @@
+# Code of Conduct
+
+## Our Pledge
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+## Our Standards
+
+Examples of behavior that contributes to creating a positive environment include:
+
+* Using welcoming and inclusive language
+* Being respectful of differing viewpoints and experiences
+* Gracefully accepting constructive criticism
+* Focusing on what is best for the community
+* Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+* The use of sexualized language or imagery and unwelcome sexual attention or advances
+* Trolling, insulting/derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or electronic address, without explicit permission
+* Other conduct which could reasonably be considered inappropriate in a professional setting
+
+## Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project maintainers at {COC_EMAIL}. All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
+
+[homepage]: http://contributor-covenant.org
+[version]: http://contributor-covenant.org/version/1/4/
+
+# Social Rules
+
+In addition to having a code of conduct as an anti-harassment policy, we have a small set of [social rules](https://www.recurse.com/manual#sub-sec-social-rules) we follow. We (the project maintainers) lifted these rules from the [Recurse Center](https://www.recurse.com). We've seen these rules in effect in other environments. We'd like the Pony community to share a similar positive environment. These rules are intended to be lightweight, and to make more explicit certain social norms that are normally implicit. Most of our social rules really boil down to “don't be a jerk” or “don't be annoying.” Of course, almost nobody sets out to be a jerk or annoying, so telling people not to be jerks isn't a very productive strategy.
+
+Unlike the anti-harassment policy, violation of the social rules will not result in expulsion from the Pony community or a strong warning from project maintainers. Rather, they are designed to provide some lightweight social structure for community members to use when interacting with each other.
+
+## No feigning surprise.
+
+The first rule means you shouldn't act surprised when people say they don't know something. This applies to both technical things ("What?! I can't believe you don't know what the stack is!") and non-technical things ("You don't know who RMS is?!"). Feigning surprise has absolutely no social or educational benefit: When people feign surprise, it's usually to make them feel better about themselves and others feel worse. And even when that's not the intention, it's almost always the effect.
+
+## No well-actually's
+
+A well-actually happens when someone says something that's almost - but not entirely - correct, and you say, "well, actually…" and then give a minor correction. This is especially annoying when the correction has no bearing on the actual conversation. This doesn't mean we aren't about truth-seeking or that we don't care about being precise. Almost all well-actually's in our experience are about grandstanding, not truth-seeking.
+
+## No subtle -isms
+
+Our last social rule bans subtle racism, sexism, homophobia, transphobia, and other kinds of bias. This one is different from the rest, because it covers a class of behaviors instead of one very specific pattern.
+
+Subtle -isms are small things that make others feel uncomfortable, things that we all sometimes do by mistake. For example, saying "It's so easy my grandmother could do it" is a subtle -ism. Like the other three social rules, this one is often accidentally broken. Like the other three, it's not a big deal to mess up – you just apologize and move on.
+
+If you see a subtle -ism in the Pony community, you can point it out to the relevant person, either publicly or privately, or you can ask one of the project maintainers to say something. After this, we ask that all further discussion move off of public channels. If you are a third party, and you don't see what could be biased about the comment that was made, feel free to talk to the project maintainers. Please don't say, "Comment X wasn't homophobic!" Similarly, please don't pile on to someone who made a mistake. The "subtle" in "subtle -isms" means that it's probably not obvious to everyone right away what was wrong with the comment.
+
+If you have any questions about any part of the code of conduct or social rules, please feel free to reach out to any of the project maintainers.

CONTRIBUTING.md

@@ -0,0 +1,136 @@
+# Contributing
+
+You want to contribute to ponyfmt? Awesome.
+
+There are a number of ways to contribute. As this document is a little long, feel free to jump to the section that applies to you currently:
+
+* [Bug report](#bug-report)
+* [How to contribute](#how-to-contribute)
+* [Pull request](#pull-request)
+
+Additional notes regarding formatting:
+
+* [Documentation formatting](#documentation-formatting)
+* [Code formatting](#code-formatting)
+* [File Naming](#standard-library-file-naming)
+
+## Bug report
+
+First of all please [search existing issues](https://github.com/mfelsche/ponyfmt/issues) to make sure your issue hasn't already been reported. If you cannot find a suitable issue — [create a new one](https://github.com/mfelsche/ponyfmt/issues/new).
+
+Provide the following details:
+
+  - short summary of what you were trying to achieve,
+  - a code snippet causing the bug,
+  - expected result,
+  - actual results and
+  - environment details: at least operating system version
+
+If possible, try to isolate the problem and provide just enough code to demonstrate it. Add any related information which might help to fix the issue.
+
+## How to Contribute
+
+This project uses a fairly standard GitHub pull request workflow. If you have already contributed to a project via GitHub pull request, you can skip this section and proceed to the [specific details of what we ask for in a pull request](#pull-request). If this is your first time contributing to a project via GitHub, read on.
+
+Here is the basic GitHub workflow:
+
+1. Fork this repo. you can do this via the GitHub website. This will result in you having your own copy of the repo under your GitHub account. 
+2. Clone your forked repo to your local machine
+3. Make a branch for your change
+4. Make your change on that branch
+5. Push your change to your repo 
+6. Use the github ui to open a PR
+
+Some things to note that aren't immediately obvious to folks just starting out:
+
+1. Your fork doesn't automatically stay up to date with changes in the main repo.
+2. Any changes you make on your branch that you used for one PR will automatically appear in another PR so if you have more than 1 PR, be sure to always create different branches for them.
+3. Weird things happen with commit history if you don't create your PR branches off of `master` so always make sure you have the `master` branch checked out before creating a branch for a PR
+
+If you feel overwhelmed at any point, don't worry, it can be a lot to learn when you get started. You can usually find me on the [Pony IRC](https://webchat.freenode.net/?channels=%ponylang) if you need help.
+
+You can get help using GitHub via [the official documentation](https://help.github.com/). Some hightlights include:
+
+- [Fork A Repo](https://help.github.com/articles/fork-a-repo/)
+- [Creating a pull request](https://help.github.com/articles/creating-a-pull-request/)
+- [Syncing a fork](https://help.github.com/articles/syncing-a-fork/)
+
+## Pull request
+
+Before issuing a pull request we ask that you squash all your commits into a single logical commit. While your PR is in review, we may ask for additional changes, please do not squash those commits while the review is underway. Once everything is good, I'll then ask you to further squash those commits before merging. We ask that you not squash while a review is underway as it can make it hard to follow what is going on. Additionally, we ask that you:
+
+* [Write a good commit message](http://chris.beams.io/posts/git-commit/)
+* Issue 1 Pull Request per feature. Don't lump unrelated changes together.
+
+If you aren't sure how to squash multiple commits into one, Steve Klabnik wrote [a handy guide](http://blog.steveklabnik.com/posts/2012-11-08-how-to-squash-commits-in-a-github-pull-request) that you can refer to.
+
+Once those conditions are met, the PR can be merged.
+
+Please note, if your changes are purely to things like README, CHANGELOG etc, you can add [skip ci] as the last line of your commit message and your PR won't be run through our continuous integration systems. We ask that you use [skip ci] where appropriate as it helps to get changes through CI faster and doesn't waste resources that TravisCI is kindly donating to the Open Source community.
+
+## Documentation formatting
+
+When contributing to documentation, try to keep the following style guidelines in mind:
+
+As much as possible all documentation should be textual and in Markdown format. Diagrams are often needed to clarify a point. For any images, an original high-resolution source should be provided as well so updates can be made.
+
+Documentation is not "source code." As such, it should not be wrapped at 80 columns. Documentation should be allowed to flow naturally until the end of a paragraph. It is expected that the reader will turn on soft wrapping as needed.
+
+All code examples in documentation should be formatted in a fashion appropriate to the language in question.
+
+All command line examples in documentation should be presented in a copy and paste friendly fashion. Assume the user is using the `bash` shell. GitHub formatting on long command lines can be unfriendly to copy-and-paste. Long command lines should be broken up using `\` so that each line is no more than 80 columns. Wrapping at 80 columns should result in a good display experience in GitHub. Additionally, continuation lines should be indented two spaces. 
+
+OK:
+
+```bash
+my_command --some-option foo --path-to-file ../../wallaroo/long/line/foo \
+  --some-other-option bar
+```
+
+Not OK:
+
+```bash
+my_command --some-option foo --path-to-file ../../wallaroo/long/line/foo --some-other-option bar
+```
+
+Wherever possible when writing documentation, favor full command options rather than short versions. Full flags are usually much easier to modify because the meaning is clearer.
+
+OK:
+
+```bash
+my_command --messages 100
+```
+
+Not OK:
+
+```bash
+my_command -m 100
+```
+
+## Code formatting
+
+The basics:
+
+* Indentation
+
+Indent using spaces, not tabs. Indentation is language specific.
+
+* Watch your whitespace!
+
+Use an editor plugin to remove unused trailing whitespace including both at the end of a line and at the end of a file. By the same token, remember to leave a single newline only line at the end of each file. It makes output files to the console much more pleasant.
+
+* Line Length
+
+We all have different sized monitors. What might look good on yours might look like awful on another. Be kind and wrap all lines at 80 columns unless you have a good reason not to.
+
+* Reformatting code to meet standards
+
+Try to avoid doing it. A commit that changes the formatting for large chunks of a file makes for an ugly commit history when looking for changes. Don't commit code that doesn't conform to coding standards in the first place. If you do reformat code, make sure it is either standalone reformatting with no logic changes or confined solely to code whose logic you touched. For example, updating the indentation in a file? Do not make logic changes along with it. Editing a line that has extra whitespace at the end? Feel free to remove it.
+
+The details:
+
+All Pony sources should follow the [Pony standard library style guide](https://github.com/ponylang/ponyc/blob/master/STYLE_GUIDE.md).
+
+##  File naming
+
+Pony code follows the [Pony standard library file naming guidelines](https://github.com/ponylang/ponyc/blob/master/STYLE_GUIDE.md#naming).

Makefile

@@ -0,0 +1,14 @@
+
+build/ponyfmt: build ponyfmt/*.pony
+	stable env ponyc ponyfmt -o build --debug
+
+build:
+	mkdir build
+
+test: build/ponyfmt
+	build/ponyfmt
+
+clean:
+	rm -rf build
+
+.PHONY: clean test

README.md

@@ -1,10 +1,25 @@
 # ponyfmt
-autoformatting for pony code
 
-## Current Status
+Source Code Formatter for the ponylang programming language
 
-This repository is pure vaporware.
+## Status
 
-Its sole purpose is a future repository for the actual ponyfmt code
-and, most importantly a place for discussion about the idea, approach and implementation 
-of a ponylang autoformatter.
+[![Build Status](https://travis-ci.org/mfelsche/ponyfmt.svg?branch=master)](https://travis-ci.org/mfelsche/ponyfmt)
+
+This project is still in pre-alpha state and might damage your sources.
+
+## Installation
+
+* Install [pony-stable](https://github.com/ponylang/pony-stable)
+* Update your `bundle.json`
+
+```json
+{ 
+  "type": "github",
+  "repo": "mfelsche/ponyfmt"
+}
+```
+
+* `stable fetch` to fetch your dependencies
+* `use "ponyfmt"` to include this package
+* `stable env ponyc` to compile your application

STYLE_GUIDE.md

@@ -0,0 +1,3 @@
+# Style Guide
+
+ponyfmt follows the [Pony standard library Style Guide](https://github.com/ponylang/ponyc/blob/master/STYLE_GUIDE.md).

bundle.json

@@ -0,0 +1,8 @@
+{
+  "deps": [
+    {
+      "type": "github",
+      "repo": "jemc/ponycc"
+    }
+  ]
+}

ponyfmt/formatter.pony

@@ -0,0 +1,8 @@
+
+class val FormatterConfig
+
+actor Formatter
+  let config: FormatterConfig
+
+  new create(config': FormatterConfig) =>
+    config = config'

ponyfmt/main.pony

@@ -0,0 +1,86 @@
+use "ponycc/ast"
+use "cli"
+use "files"
+use "ponycc/ast/print"
+
+actor Main
+  let env: Env
+
+  new create(env': Env) =>
+    env = env'
+    let commandSpec =
+      try
+        CommandSpec.leaf(
+          "ponyfmt",
+          "A Pony Code Formatter",
+          [
+            OptionSpec.string("output", "Output directory", 'o', ".")],
+          [
+            ArgSpec.string_seq("modules", "The pony modules to format")
+          ])? .> add_help()?
+      else
+        env'.err.print("Invalid CommandSpec")
+        env'.exitcode(1)
+        return
+      end
+    let cmd =
+      match CommandParser(commandSpec).parse(env.args, env.vars())
+      | let c: Command => c
+      | let ch: CommandHelp =>
+        ch.print_help(env.out)
+        env'.exitcode(0)
+        return
+      | let se: SyntaxError =>
+        env'.err.print(se.string())
+        env'.exitcode(1)
+        return
+      end
+
+    let modules = cmd.arg("modules").string_seq()
+    for modulePath in modules.values() do
+      formatModule(modulePath)
+    end
+
+  fun box reportErrors(errs: Array[(String, SourcePosAny)]) =>
+    """
+    """
+
+  fun formatModule(modulePath: String) =>
+    let moduleSource: Source =
+      try
+        loadModule(modulePath)?
+      else
+        env.err.print("unable to load module @ " + modulePath)
+        return
+      end
+    ModuleParser.parseModule(
+      moduleSource,
+      {(errs: Array[(String, SourcePosAny)] box) =>
+        env.err.print(modulePath)
+        for err in errs.values() do
+          (let line, let arrow) = err._2.show_in_line()
+          env.err
+            .>print("  ERROR:")
+            .>print("    " + err._1)
+            .>print("    " + line)
+            .>print("    " + arrow)
+            .>print("")
+        end
+      } val,
+      {(module: Module) =>
+        // TODO: use Formatter
+        env.out
+          .>print(modulePath)
+          .>print(Print(module))
+      } val)
+
+
+
+  fun loadModule(path: String): Source ? =>
+    let filePath = FilePath(env.root as AmbientAuth, path)?
+    match OpenFile(filePath)
+    | let file: File =>
+      Source(file.read_string(file.size()), path)
+    else
+      error
+    end