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/
i'm trying to speak DAP but the scala-debug-adapter is very closely integrated with being a JDI <-> DAP bridge
not at the JVM-level, but a higher level debugger for the processing going on
already have something like that
metals uses https://microsoft.github.io/debug-adapter-protocol/ to speak DAP, and that's a thin layer on top of https://github.com/microsoft/java-debug, which connects JDI to DAP.
DAP itself is pretty nice: https://microsoft.github.io/debug-adapter-protocol/
So after taking on scripting as a whole, it was clear to me it could be easier to write simple scripts.
https://github.com/davenverse/shellfish/blob/main/examples/src/main/scala/Main.scala - This is a prototype, its still clunky and the process architecture needs a lot of work. It also limits to singular shell by using the java mechanism for working directory which is a global, which I can design around if folks like this. It has less types than usual, but the plus is its very easy to write up without a compiler running every line.
https://github.com/davenverse/shellfish/blob/main/examples/src/main/scala/Main.scala - This is a prototype, its still clunky and the process architecture needs a lot of work. It also limits to singular shell by using the java mechanism for working directory which is a global, which I can design around if folks like this. It has less types than usual, but the plus is its very easy to write up without a compiler running every line.
Basically, I'm soliciting feedback as I think it needs a lot of work, but I want to confirm I'm headed in a decent direction.
@ChristopherDavenport: I have feedback: stdin/stdout/stderr in subprocesses 😅
Added one real quick, thanks
I've recently added a bunch of Scala 3 syntax under that flag to allow us to deprecate and potentially repurpose some old syntax without harming cross-compatibility with Scala 2, but this hinges on people actually using that flag so it'd be good to know if there's any issues with it
The potentially problematic thing is that besides the syntactic additions, this flag implements two semantic changes: it makes the apply/copy methods of
private case class also private (which isn't binary-compatible but should be workaround-able by adding back these methods manually?) and it makes contravariant resolution of typeclass instances behaves more like scala 3 (cf scala/scala#6037)
so I'm wondering if that's troublesome enough that the flag should be split into two flags: one with only syntactic changes and one with both syntactic and semantic changes, but I don't know how the Scala 2 team would feel about that.
for reference the only Scala 2 construct whose meaning would change is wildcard
_ in type applications: http://dotty.epfl.ch/docs/reference/changed-features/wildcards.html, additionally pattern bindings without case in front would be required to be exhaustive and error out otherwise: https://dotty.epfl.ch/docs/reference/changed-features/pattern-bindings.html
and the PRs implementing the new things for Scala 2 are: scala/scala#9560, scala/scala#9558, scala/scala#9582, scala/scala#9580, scala/scala#9584 and scala/scala#9594, all backported to 2.12 too
I think it'd be useful yeah
But cats-effect is very fast already. I’m more interested in the simplifications than anything else.
I’m not convinced that delimited continuations are useful for programming. Every formulation I have seen has been completely baffling.
to program in execution-as-evaluation ("imperative" programming, although that's a misnomer) vs programs-as-values (pure FP, which I also consider a misnomer in this context), but with roughly equivalent power
but I kinda think you need a language built with that in mind from the ground up
for cats-effect it will become an implementation detail at best, and I'm not convinced it's that valuable in that context
especially when it comes to subtler semantics such as interruption
I think it will be useful to be able to wrap synchronous java code whilst still being non blocking, which is great
