jmite

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.

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.

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.

Rice's theorem, actually

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.

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.

I like my types, without runtime overhead of type checks

To be clear, I am not the "I" in that quote, that's Evan Czaplicki

"I do not expect to be compiling to JavaScript forever": in the 0.17 announcement

http://elm-lang.org/blog/farewell-to-frp

I wouldn't say that it's about performance for Elm. Its virtual-dom has been shown to be wickedly fast with pure code.

It's more that real programs need real effects: you need to send HTTP requests, read from user input, etc. Elm gives you a managed way to deal with those effects, while keeping the program declarative, and making as much of the logic side-effect free as is possible.

It should at least be able to compile with GHC 7.10 now.

I don't think the semantics are any more imperative than IO in Haskell, it's just that there's a different abstraction used for dealing with it.

Moreover, Tasks are absolutely monadic, with `andThen` being the bind operator. Elm just chooses to focus on the individual use-case, as opposed to focusing on the broader abstraction.

Under "other cool stuff" it's mentioned that error reporting when parsing fails is greatly improved. Not sure if that's what you meant.

They do, and have been made much clearer: http://guide.elm-lang.org/interop/javascript.html

It has changed, in that the language is moving away from Native code, and instead is trying to provide the web-platform as part of the language/core libs.

And for everything else, there's Ports. You can't use them in libraries, but for your own projects they're a much better JS FFI.

Author here.

LPP is a small language with dependent types. The idea is that it's a small set of features for people who are just starting with DTs to learn, and it's also a small enough code base that if you're doing research with DTs, it can serve as a platform for testing new features.

It's been compiled to JavaScript, so you can try it in your browser, though right now there's no way to run programs, only to typecheck them. The error messages right now are pretty terrible, but this is partially intentional, since I'm working on new message generation techniques.

As you find issues (as I'm sure there are many), feel free to report them on Github .

I created LambdaPiPlus as the starting language for the research of my Masters Thesis, on the subject of improving error messages in dependently-typed languages. I found in my research that it's hard to artificially create poorly-typed programs that resemble what a programmer (especially a novice DT programmer) would write.

Part of my motivation for releasing LPP is to allow others to try it and, if they consent, collecting the source of small programs that fail to type-check. Source-code collection can be turned off by checking the box at the bottom of the "Try" page.

It seems to work for NoRedInk and CircuitHub...

The learning curve is not terribly steep, compared to Haskell. There are a lot of good resources, and many friendly people on the mailing list to help you if you decide to learn Elm!

I think it has as much to do with standardization as ease of use. This way, if there are multiple experts, they don't each do it their own way.

Plus, it gives a degree of reliability to those using the packages, which is something you can't necessarily count on in Haskell right now.

The thing is, "sum types" really only works if you're familiar with the analogy between boolean algebra and arithmetic (why OR becomes +).

Yes, they are disjoint union, but there's really no such thing as non-disjoint union in a statically typed language i.e. that's what makes it typesafe.