Skip to content

Fork with completion support #91

Open
@jchapuis

Description

@jchapuis

Hi all,

I've created a fork which adds completion support to the library, which allows providing as-you-type autocomplete or TAB-completion experiences: https://github.com/jchapuis/scala-parser-combinators.git

In a nutshell, additions are:

  • def completions(in: Input): Completions method which allows querying the list of possible completions for a certain input. This returns a structured type which can contain tagged and ranked completions.
  • implementations of this method for all the combinators
  • a new set of operators which allows tagging and ranking elements of the grammar

I have also implemented fuzzy matching completion parsers which are not present in the fork right now but that I could potentially integrate.

Would you consider this as a possible PR? It's of course extending the "traditional" functionality of parser combinators, so it add extra complexity and testing requirements that are maybe not desirable for the core library. At any rate I'm creating this issue also to to point out that building completion experiences using parser-combinators is feasible and actually works well with the functional nature of these grammars.

Activity

gourlaysama

gourlaysama commented on Dec 16, 2016

@gourlaysama
Contributor

Wow, that's interesting!

Does this have a performance impact for people that don't use the completion support at all?

Yes, that would be an interesting PR (for v1.1.0, the master branch). It would be easier to get it in if the completion stuff could all be moved into some trait that the user could just mix in if they need it, as in:

object MyParsers extends RegexParsers with CompletionSupport

That way it would be opt-in, and not as invasive.
Looking quickly at the code, I think this should be possible with a few changes to Parsers to allow that trait to subclass the Parser class used and change how it is created...

SethTisue

SethTisue commented on Dec 16, 2016

@SethTisue
Member

It would be easier to get it in if the completion stuff could all be moved into some trait that the user could just mix in if they need it

agree. if that's possible, it would be much better

jchapuis

jchapuis commented on Dec 19, 2016

@jchapuis
Author

Thanks for your feedback, I also agree, this is what I wanted to do initially actually. I'll investigate further along those lines.

jchapuis

jchapuis commented on Feb 10, 2017

@jchapuis
Author

Hi there, I've just created a PR (#101) with the completion aspects now separate from the main code and exposed in a CompletionSupport trait as suggested. Note that a separate RegexCompletionSupport trait is also defined which adds completion support to the literal parser, and can be used like so:

object MyParsers extends RegexParsers with RegexCompletionSupport

This CompletionSupport trait is a subtype of Parsers (and not a self-type) as it subclasses Parser to add the completions method and overrides some methods. Let me know what you think!

Also in the case this can be considered, thanks for letting me know what is required in terms of copyright notice, licensing etc. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      Fork with completion support · Issue #91 · scala/scala-parser-combinators