That's really neat! But doesn't this just mean that instead of writing your code and logic in Ruby you're writing it in RDL?
Also, it would be great to see some examples in the README or in an examples folder. It's kind of hard for me to tell exactly what I need to write and what to call to generate the Ruby.
RDL allows the specification of types and effect labels only. You still write the tests in standard Ruby and synthesized code should satisfy the logic as checked by the tests.
> Also, it would be great to see some examples in the README or in an examples folder. It's kind of hard for me to tell exactly what I need to write and what to call to generate the Ruby.
Sorry for the sparse documentation, I plan to improve that. I have added an example to the readme. Other examples can be found in `test/benchmark` folder.
What it can do now. What are the limits. What’s planned next? Are questions we have as first time visitors.
I think its important that the code still be user-modifiable:
Take this function, y = 2 * x.
Write a test, which proves for all real numbers, that y = 2 * x.
Can't do it, can you?
Tests can't fully specify code - this effort is doomed to be incomplete.
..and write a test for it..? :|
It was an interesting idea but in reality we spent so much time having to spoon-feed it more and more carefully constructed examples that it just seemed pointless.
Not to say that this will suffer from the same issue, but I do wonder if the benefit will really be significant enough to make it worth it.
However, not all program values can be easily lifted to solvers. So the goal with RbSyn is to allow the programmer to write the same tests they would have written anyway to check their program correctness, without any extra fiddling. As tests subsume examples, we expect more program behavior can be specified than just using simple examples.
> I do wonder if the benefit will really be significant enough to make it worth it.
I have often pondered on what makes a program synthesis tool useful. I expect writing code as art as much as it is science, and people like to express code in the way they model system behavior in their head. In that regard, I do not think program synthesis tools will enable you to automate away large parts of code, but I do think it will automate mundane parts of a program; like writing utility methods, or filling in a partial program when enough information can be gathered from surrounding context (such as the arguments you write for a substring function).
Specifically, I've been working on a activity tracking app that can take plain text and create structured data from it. For example
> I played tennis with Kevin and won 6-2
would turn into
```
type: tennis
opponent: Kevin
my_score: 6
their_score: 2
outcome: win
```
As you can imagine, when it comes to natural language there are many variations of I won (outcome: win), he/she/they won (outcome: loss), I was beat, etc which means that my inputs are not nearly as structured as the examples used in the paper I'm reading. Given that I'm not trying to cover every use case in the English language, which I assume would require some form of NLP, but rather just a subset that a single user would input, do you think think it would be possible to solve this with PBE techniques?
We might just have really different brains but "read the code and figure out everything it doesn't do" is one of the hardest possible tasks for me?