search

damonsk / onlinewardleymaps

OnlineWardleyMaps.com - Draw Wardley Maps in seconds using this free online tool
https://onlinewardleymaps.com/
MIT License
242 stars 60 forks source link

Use a grammar for the input definition #24

Open jimdowning opened 4 years ago

jimdowning commented 4 years ago

Have you thought of using a grammar to describe the syntax? Would make coping with its evolution a lot cleaner.

I'm guessing you'd like to constrain it to be a regular language so that the syntax highlighting keeps working? Or is that a secondary consideration?

ChristianDavis commented 4 years ago

@jimdowning do you have any use for the language in something like BNF?

jimdowning commented 4 years ago

@ChristianDavis To be honest, I've dropped off from participation and my time available for helping with dev has gone too. I don't think I ever sold the main contribs on the benefits of a grammar to the architecture. In my mind I imagined keeping the canonical runtime data structure in an AST, and being able to generate both the graphical map from that and roundtrip the text encoding of the map from it.

My hope was that this would mean that map alterations could be added simply as AST manipulations, without needing to worry about graphical form and text form alterations at the same time. It would also make it necessary that anything you can express in the graphical form could be expressed in the text form, which I think is needed so that maps can be fully versioned and managed in git without necessarily needing the back end system of OWM.

When I was looking at this, I was leaning towards nearley.js as it seemed a bit more accessible than e.g. ANTLR.

In a nutshell, I can't make use of a BNF grammar, but you're very welcome to pick up and carry the flag for a grammar in this project.

ChristianDavis commented 4 years ago

@jimdowning There would be benefits from it. I've never seen nearley.js, that could be a nice in-between step.

@damonsk has done a great job of getting his idea out there and getting it working. Essentially rolled his own scannerless parser and it seems to work well. I had the same initial plan of getting in and generating an AST, but I've changed my mind a bit. There is non-regular syntax in the language ATM that helps simplify things, and @damonsk's heuristic approach doesn't mind. It's funny because I think if the project had started with a formal approach, it would have ran into roadblocks when stuff got complicated and lost steam.

When I lay out the total scope of his intended features the language is almost complete as-is. I argue for starting some formal language work whenever there is interest (or a champion for it) and keep that committed to the repo, but prioritize finishing the features of the language. I like your nearley.js suggestion because it could potentially be worked right into the existing parser to streamline the work there.

I worked on a compiler for a long time and I know that the formal language route is rarely the easiest one 😆

damonsk commented 9 months ago

Similar issues #167 #99 #82 #39 #11 on the topic of syntax.

There has been some conversations in the community to attempt to standardise this, however not sure on progress. As OWM is quite established, this would be a fundamental change to the tool and one that I'd want the community to have input on.

Wardley-Mapping-Foundation DSL work - https://github.com/Wardley-Mapping-Foundation/wmf-standards-dsl