Not a TS user, but looks like a really cool idea.
As per the questions, I'd go for the TS signatures for searching. All in all, ts-earch users will already be familiar with them, and forcing them to learn an additional DSL could hamper your adoption rate. Also, it's prone to have it's issues here and there, further difficulting the UX.
I have a similar-ish idea for a proyect (a "snippet-oriented", openly searchable, collaborative database) where I'll have to search leveraging code itself and descriptions. I might go for a machine learning/NLP solution. Although it's a tough road to take, you could look into it. Train some NN to sort out what method/function the user looks for based on the types mentioned. Overkill and hard? Absolutely; Fun? Hopefully.
And how to do inference/indexing/matching, I may be talking out of my a[s]{2}hole here, but I feel like some sort of tree datastructure may be of help here. For example, Scala types are sorta like this: oreilly.com/library/view/learning-...
If you could make something like that for TS, flexible enough so that you could add custom types based on the properties they contain, you could start matching them by traversing the tree.
Language theory is haaaard. I have a deep admiration for people who does that, and I'm sure you could find some here in dev.to. They'll be able to guide you a bit more with this.
I haven't made up my mind yet about the query language. A "DSL" could be much simpler than the actual definition. For simple signatures there's no much change:
But I did not consider the fact that it would mean learning something new. That is a strong argument.
Yeah a ML/NPL solution could also be the case. But I guess it makes more sense your your idea (which, btw, is really cool).
Yeah, I will definitely take a look at how other languages do and even how TS itself does the type resolution. Now I implemented something pretty naive. Will write a bit more in the coming week/s.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Not a TS user, but looks like a really cool idea.
As per the questions, I'd go for the TS signatures for searching. All in all, ts-earch users will already be familiar with them, and forcing them to learn an additional DSL could hamper your adoption rate. Also, it's prone to have it's issues here and there, further difficulting the UX.
I have a similar-ish idea for a proyect (a "snippet-oriented", openly searchable, collaborative database) where I'll have to search leveraging code itself and descriptions. I might go for a machine learning/NLP solution. Although it's a tough road to take, you could look into it. Train some NN to sort out what method/function the user looks for based on the types mentioned. Overkill and hard? Absolutely; Fun? Hopefully.
And how to do inference/indexing/matching, I may be talking out of my a[s]{2}hole here, but I feel like some sort of tree datastructure may be of help here. For example, Scala types are sorta like this: oreilly.com/library/view/learning-...
If you could make something like that for TS, flexible enough so that you could add custom types based on the properties they contain, you could start matching them by traversing the tree.
Language theory is haaaard. I have a deep admiration for people who does that, and I'm sure you could find some here in dev.to. They'll be able to guide you a bit more with this.
Thanks for the comments! Very useful suggestions!
I haven't made up my mind yet about the query language. A "DSL" could be much simpler than the actual definition. For simple signatures there's no much change:
But for more complex ones it could become easier to type:
But I did not consider the fact that it would mean learning something new. That is a strong argument.
Yeah a ML/NPL solution could also be the case. But I guess it makes more sense your your idea (which, btw, is really cool).
Yeah, I will definitely take a look at how other languages do and even how TS itself does the type resolution. Now I implemented something pretty naive. Will write a bit more in the coming week/s.