General topics relating to the the Typelevel project http://typelevel.org/ | See also individual project channels | Code of conduct https://www.scala-lang.org/conduct/
such a thing could be pretty trainable too.
Imagine hoogle but using a massive corpus of codebases. Put in the signature you want and it will find matching ones from the corpus, show them to you to select. Want to pick an impl? Insert an import to the library automatically and call it, or auto-add it as a project dep and do the same, or auto-inline it
A signature that simple would get implemented because you need a specific rule
I don't imagine this being "AI" in that way. More of a rules engine + database + constraint solver
score possible answers with simple weights, make a cutoff point, display for the user to take action on
I'm not going to get into the whole "is a rules engine AI" thing
yeah, there is work on autocomplete based on sequence prediction, so you can start typing some code and it starts to fill it in… you can imagine leveraging type information and test constraints and sequence prediction, and it work pretty well, fairly soon.
of course, I think FP works better in this context since you can combine sequence prediction (generating source code), with the compiler restricting the set of possible valid programs.
you can imagine a generative approach where you use the compiler as an oracle, so you take code from GitHub, remove some trailing bit of a function, then predict completions that will compile.
combining that with a prompt of comment code describing how the function should work, and some text examples, I think it is probably totally possible right now to make ML assisted IDE that substantially reduces the effort to write the code.
Next they really need to attack the hard problem: getting it to manage the build for you. :)
[insert comment about source dependencies here]
isovector in the Haskell community also made some pretty cool type hole autocompletion stuff for hls, so it’s definitely doable
@tpolecat speaking of dependent languages, and recalling that you expressed annoyance about repetition between match types and corresponding implementation, have you seen this?
@tpolecat if your time is short skip to https://youtu.be/t4yJCDB-_H4?t=1439
I quite like how the emacs community one is set up.
I primarily use it for Haskell.
I also use it for some Go and Ruby dependencies I don't want to learn more about. And it's my primary package manager for system tools, and for my dotfiles. And of course my Emacs. :smile:
Thoughts on something like this?
https://gist.github.com/ChristopherDavenport/2b067138ebad8c4fcf5c6cc9819cefe8 - Just a basic rate-limiter implementation. Not sure if its worth it to put somewhere though.
https://gist.github.com/ChristopherDavenport/2b067138ebad8c4fcf5c6cc9819cefe8 - Just a basic rate-limiter implementation. Not sure if its worth it to put somewhere though.
Basically a rolling window out the back. Could likely just count the strikes against people for hitting again when already at the end. But it should work in a distributed fashion and apply to http4s with something simple either a user identifier or ip
Not really related to typelevel, but a member of the scala community needs our help and I was hoping for some support (even RTs!) from the good people here: https://twitter.com/Oleksandra_A/status/1346484655223169031 (you can read the full story in the attached medium post)
here is an example of the manual changes i needed to make after the scala fix: https://github.com/johnynek/bosatsu/pull/649/commits/eb4453d0a333f6609250f7e08e84bbcf48267fe0
But seriously, I'm delighted how smoothly such big changes went, and I like the new API.
I can't seem to find the google foo to answer my question. Where did the
scala.tools stuff get moved to in 2.13? I'm way behind on migrating some of our projects to 2.13 and I need something from scala.tools.nsc and it's not found without an explicit dependency but I can't figure out where that got moved to.
