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

Request for Implementation: Java #9

Open
breck7 opened this issue Sep 7, 2019 · 7 comments
Open

Request for Implementation: Java #9

breck7 opened this issue Sep 7, 2019 · 7 comments

Comments

@breck7
Copy link
Contributor

@breck7 breck7 commented Sep 7, 2019

No description provided.

@breck7 breck7 transferred this issue from publicdomaincompany/jtree Sep 18, 2019
@breck7 breck7 transferred this issue from treenotation/treenotation.org Oct 9, 2019
@justjake
Copy link

@justjake justjake commented Dec 10, 2020

I may take a swing in Kotlin

@breck7
Copy link
Contributor Author

@breck7 breck7 commented Dec 10, 2020

A few tips from the past 12 months:

  • it seems like it may be a better approach to use tabs after all, instead of spaces, as the edge and cell delimiter. then you get really nice "tri-somorphic" editing experiences (manipulating programs with code, with editors, and with spreadsheets). If there is a good Kotlin spreadsheet package (in typescript HandsOntable is the one to use), you can build some cool stuff.
  • starting with the even more basic "grid notation" seems to be the way to go, which is the same as tree notation but doesn't have nesting. you almost immediately want to jump to tree notation (scopes are ugly without it), but there is a logical hierarchy there.
  • the swim tests as is weren't a great choice of first tests. in particular, people who tried them get hung up on the CSV and JSON ones, since those languages are not directly isomorphic, so probably shouldn't be in a universal set of tests.

@justjake
Copy link

@justjake justjake commented Dec 12, 2020

@breck7 do you have any pointers with respect to tests? I was about to start in on Kotlin

@breck7
Copy link
Contributor Author

@breck7 breck7 commented Dec 12, 2020

Hi @justjake give me ~30 minutes to write up something more up to date.

@breck7
Copy link
Contributor Author

@breck7 breck7 commented Dec 12, 2020

Hi @justjake , I started a new explanatory approach here:

https://github.com/treenotation/thebook

If you had a chance, take a skim and let me know if you think that might be more useful than this "swim" approach. Thanks!

@justjake
Copy link

@justjake justjake commented Dec 20, 2020

@breck7

Anyways, here's my progress: https://github.com/justjake/ktree. I can construct trees by parsing or writing literals, and implemented some methods for moving nodes around the tree.

I didn't find the book style to be very helpful. For me, a thorough and unambiguous spec would be more useful - based on the actual spec, then I can choose my preferred approach. For me, SWIM test idea is clearer and more concise than the book idea (although, the separate test file in this repo is confusing, it's much easier to understand one with code in
it.

The area of tree notation that I am confused about, based on the spec at https://github.com/treenotation/faq.treenotation.org/blob/master/spec.txt, is how I should handle nodes that look over-indented.

My suggestion to make implementing easier is to improve the SWIM by using JSON to handle bootstrapping problems. If we define a canonical JSON serialization of tree notation, we can use it to cross-check parsers in new languages. I think it would help if we can write a test like this:

test basic parser example
 input tree notation
  parent dataword1 dataword2
   child childword1 childword2
 output json
  [{ cells: ['parent', 'dataword1', 'dataword2'], children: [{ cells: [child', 'childword1', 'childword2'] }] }]

test handles overindented children correctly
 input tree notation
  parent
          child
    child2
  output json
   (I don't actually know the answer)

The tests would attempt to parse the tree under input tree notation and then check that the canonical serialization of the parsed tree matches the expected output json.

To help with bootstrapping, the test suite could be saved as both test.swim tree notation files, and as test.swim.json files. Then, implementors can rely on the JSON version to get the test cases even if the tree notation parser is currently untrustworthy.

@breck7
Copy link
Contributor Author

@breck7 breck7 commented Dec 21, 2020

If we define a canonical JSON serialization of tree notation, we can use it to cross-check parsers in new languages.

Great idea! I don't know why I hadn't thought of that. I have this weird subset of JSON that is isomorphic to Tree Notation, which I think has been confusing the heck out of people, because they have been taking it for the canonical JSON form, when it's just really a tiny subset I find useful in certain niche situations.

I added that and shipped a new version of JTree now with the canonical JSON serialization form that you created above. I also added a new "toJson()" textarea to the "Sandbox" app for playing around with. And I added deep linking ability to the Sandbox so you can share test cases.

Here is your provided test case: https://jtree.treenotation.org/sandbox/#tree%0A%20parent%20dataword1%20dataword2%0A%20%20child%20childword1%20childword2

The "toJson()" box has the canonical form.

The "toGridJson()" box has Grid Notation, which is tree Notation without the "edgeSymbol" nor the concept of parent/children.

For the "over-indented" case, the 2nd edge symbol gets treated as just another symbol. After the current indent level has increased by one, the edge symbol is no longer special. Example: https://jtree.treenotation.org/sandbox/#tree%0A%20parent%0A%20%20%20child%20The%20%22over-indented%22%20child%20is%20the%20same%20as%20a%20normal%20child%2C%20with%20a%20blank%20first%20cell

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

Successfully merging a pull request may close this issue.

None yet
2 participants