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

Roadmap to v1.0 #71

Closed
9 of 11 tasks
jakobnissen opened this issue Mar 21, 2021 · 6 comments · Fixed by #95 or #119
Closed
9 of 11 tasks

Roadmap to v1.0 #71

jakobnissen opened this issue Mar 21, 2021 · 6 comments · Fixed by #95 or #119
Milestone

Comments

@jakobnissen
Copy link
Member

jakobnissen commented Mar 21, 2021

Automa has been at the core of BioJulia for around four years, so it's probably about time it got the "finally stable" batch and a shiny 1.0 release. In particular I'm worried that too few people are really "into" Automa, and, if we lose interest or get too busy to work on BioJulia, the knowledge necessary to effective use Automa is lost.

At its core, a 1.0 release means that we settle on an interface. Hence, this issue is about how Automa should feel, not how it should work. For this part, I would appreciate getting feedback from as many users as possible: What did you find hardest about Automa? How could it be made nicer to use? Could the interface be simplified?

A few suggestions:

  • CodeGenContext should be optional, because people shouldn't need to go deep into Automa to be able to use it. It should default to something equivalent to CodeGenContext(:goto) or maybe just CodeGenContext()
  • Perhaps p_eof = sizeof(mem); p_end = sizeof(mem) should be included in gen_init_code() to make it easier?
  • Add the error handling in Improve debugging of Automa #64 when an unexpected input is seen. Allow users to paste this generated code into their functions.
  • Add this error handling to default implementations like generate_validator_function
  • Rewrite Automa.RegExp if possible

There are a few non-API things I would like to have done before 1.0, but these are not critical to get done before v1.0.

  • Merge :goto and :simd generator, optionally improving the underlying codegen ( Generated code is highly redundant #53 )
  • Improve docs with examples (which implies we need to have nailed the interface before then.
  • Docs: Explain very clearly that Automa is byte-oriented
  • Docs: Advice using function calls as Expr objects, explain why, and amend the examples
  • Add extra debugging capabilities and general quality-of-life improvements (Improve debugging of Automa #64 )
  • Enforce the symbols in the passed Dict in generate_exec_code are the same as those in the Machine.

I'm envisioning tagging v1.0 some time before end of northern hemisphere summer 2022.

@jakobnissen jakobnissen added this to the v1.0 milestone Mar 21, 2021
@kescobo
Copy link
Member

kescobo commented Mar 21, 2021

Great idea! Timeline is not overly ambitious, which seems good. I think that will be enough time and motivation for me to finally make that genbank parser, which will give me a much better sense of what the pain points are.

@richardreeve
Copy link

It's strange coming back to Automa after all of these years (#17) and seeing it still (#59) doesn't handle recursion. It seems such a massive missing chunk to me for a FSM parser. It would be make Automa genuinely useful (to me at least) if it did for 1.0 - as it is I've had to roll my own (buggy) parser instead. I appreciate there doesn't seem to be much enthusiasm for that though, sadly, despite it being necessary for all phylogenetic formats.

@jakobnissen
Copy link
Member Author

jakobnissen commented Apr 7, 2021

FSM parsers can't handle recursion by definition. I think the reason why no-one has done it is that PDAs are harder to build and especially to minimize than FSMs - and that Automa is currently a FSM package only, so the changes would need to go deep.

@richardreeve
Copy link

My mistake with the name. Still a shame though.

@Azzaare
Copy link

Azzaare commented Apr 14, 2021

I am also interested in PDAs. That could be a feature target for v2 or some v1.x, though.
Regarding the syntax, what changes would be necessary to handle PDAs?

@jakobnissen
Copy link
Member Author

@Azzaare for syntax, we can settle on whatever. I would recommend using a macro to parse a Backus-Naur expression The hard thing is actually making the PDA.

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

Successfully merging a pull request may close this issue.

4 participants