Does anyone know of any language servers that use the notebook capabilities introduced in LSP 3.17? Do any clients actually implement it?

I've found the official documentation from MS, but I haven't really found much else beyond that.

It seems promising for one of my long-term projects but I'm not even sure I understand what exactly it does, and I'm pretty sure what I have in mind is far from its intended use case.

Can't a neural network only ever achieve an O(1) time approximation of an NP hard problem? Unless you're using it as a heuristic inside some broader search algorithm.

No, I think the article is right. When a value goes out of scope, its drop method is called, which for Box values deallocates it.

The trick is that if it is (possibly) returned from a function, it is moved instead of dropped.

It's also important to distinguish Box from Rc. Both are heap values but have very different behavior.

The text I quoted seemed to suggest that the reference going out of scope could trigger deallocation.

Which is true.

The word "reference" is overloaded, it can be used to mean "anything pointery that's guaranteed to exist" too. Box<T> in this context is a reference.

The post does kind of dance between definitions of "reference" a bit, but I think that's intentional.

What is your favorite tool? Agda? I've been finding it much nicer to work with, but the ecosystem is just not there yet.

Rust's traits are basically Haskell typeclasses, with a few extensions enabled, like multiple parameters.

Trait objects are basically existential types, with a few more restrictions on them. But in essence polymorphism in Haskell and Rust are very similar.

The big thing Rust is missing is higher kinded polymorphism, ie the ability to abstract over type constructors. This makes it easy, for example, to abstract over a container type while putting different things in that container.

This has get approved in the Associated Type Constructors RFC, but it's still in the works for actually landing.

One thing no-one else has mentioned yet: in Haskell you can’t provide a specialised implementation of a generic function. In Rust you can.

Whilst this is obviously useful, it makes it impossible to perform parametricity type-based reasonbig.

Of course you can. The good old {-# LANGUAGE OverlappingInstances #-}.

In Haskell you have to supply the entire instance, versus just specializing one method as you can do in Rust. Also in Haskell this extension is not recommended for general use and you won’t often find specialization like this in the wild.

The typical way to do multiple instances for a given type is with trivial newtype wrappers for each instance. See the "Sum" and "Product" monoid instances (although these wrappers are also necessary for instance decidability). This is fine "in the wild."

Also, I'm not sure why you would ever want a "partial instance," as it would mean that your program could be unsafe but still typecheck (I haven't checked out Rust's implementation or motivation). Just use more specific classes, and you can even use a "generic" "instances of the components imply an instance of the whole" class and instance.

When you specialize an instance in Rust, by definition it already has a valid instance that covers that type. So implementing a single method is fine - the other ones are provided by the instance you are specializing.

Newtypes also exist in Rust but this is an alternative that is not the same as the overlapping instances extension.

Rust will find out why as soon as this gets widespread.

You can either have overloading classes or you can have your classes declaration independent of the type declarations. You can not have both.

I think you can using GHC Pragmas.

Rice's theorem, actually

This is not a true implication.

If all the executables in the archive were, say, loop-free trivial programs, then of course you could instantly confirm an absence of malware.

If there are some loops and complications in there, you would do some more logical work, and then depending on the power of your logical system, either conclude safety or unsafety, or time out.

Rice's theorem does not mean that static analysis is impossible, even of machine code!

Right, but Rice's theorem means that you either have false positives, false negatives, or "Unknown" answers in any static analysis. Which means that the CIA could never guarantee the absence of malware, for example, if any of the programs timed out in the static analysis.

It seems likely that they wouldn't be able to guarantee that, but we need to be more clear.

The fundamental limitations of computer science, as expressed by Rice's theorem, says that the CIA cannot make a program that given any archive says in finite time whether there is malware there.

It doesn't say that for some specific archive the CIA cannot guarantee the absence of malware.

There are infinitely many EXE files that you can prove malware-free, and this set expands with the progress of static analysis.

But of course, if one EXE file says "if (unsolved_math_problem()) { malware(); } else { harmless(); }" then the CIA would have to spend a lot of effort proving its status.

Algebraic data is just so perfectly suited to abstract syntax. It's clearly possible to model an AST in C, but not to do it in an ergonomic z typesafe way.

Removing them wasn't necessary, but it's better. Elm isn't 1.0 yet, so "does this make the language better" is the metric for feature addition or deletion.

Every other comment about these changes has expressed approval. An overwhelming majority of Elm community members I've heard discuss this feel the same way.

You are welcome to a dissenting opinion, of course, but throwing shade at Evan for his popular design decisions seems unlikely to change anyone's mind.

The "other way" is to use x_1, x_2, or to just use better variable names.

Haskellers are bad at coming up with informative variable names (and I say this as a Haskeller).

I think server side Elm will come eventually. It's just taking time.