> this also seems a way to declare types for your own code in an external file, thus keeping your code as runnable Lua and benefiting from type checking too
The declaration file isn't used to typecheck the code the declaration is for. It is only for consumers of the code.
Yes, according to the archived Rust implmentation[1] which in turn refers you to either clap[2] or structopt[3]. Other implmentations does not mention this but those I looked at had not been touched for years. Either very stable or unmaintained. Unfortunately the latter according to the Rust crate. The dotNet implmentation had a very small version bump in the dependencies but the rest of the project does not seem to have been touched the past 2 years.
It's abandoned, and tbh it's more trouble than it's worth. It's far easier and more reliable to specify the CLI and have it generate the help text than the other way around. All major languages have good CLI parsing libraries (some in the stdlib itself, like Go and Python).
Yeah..... it seems like it would be fragile and require lots of iterating to converge on a help doc that is both "pretty" and correctly parsed by docopt
Would be interesting to know what’s the plan regarding supporting effects in melange. IIRC jsoo (the another OCaml to JS compiler) is doing some whole program analysis to compile to efficient CPS.
I don't know about C#, but, yes Dart has quite sophisticated exhaustiveness checking over sealed class hiearchies, including hierarchies that are DAGs and not just trees. It also handles record/tuple types and generics, nested arbitrarily deeply. And patterns that call arbitrary getters on objects.
For example, if you have this class hierarchy:
sealed class A {}
sealed class B1 implements A {}
sealed class B2 implements A {}
class C1 implements B1 {}
class C2 implements B1, B2 {}
class C3 implements B2 {}
// A
// / \
// B1 B2
// / \ / \
// C1 C2 C3
Then it understands that this switch statement is exhaustive:
void test(A a1, A a2) {
switch ((a1, a2)) {
case (A(), C1()): print(1);
case (C2(), C2()): print(2);
case (C3(), B2()): print(3);
case (B1(), B2()): print(4);
}
}
Because they cover the Cartesian product of all possible combinations of subtypes like:
The real challenge is that pictures like this only work for simple two-element tuples. Once you have more fields in the tuple, or nested destructuring, the manifold of the value space the patterns have to cover quickly gets into higher dimensions that are basically impossible to visualize.
Not sure about Dart, but for C# I don't think it can (due to classes being open by default).
If anyone is interested in a deeper dive on C# and adding Discriminated Unions, this interview by Nick Chapsas with Mads Torgersen is a great discussion: https://youtu.be/Nuw3afaXLUc?t=3939 (note, I'm pretty sure this time stamp is the right part, but the discussion might start before this. I'm at work and can't listen too closely to the video atm).
Agreed here, it's impressive how easy it is to use and how performant it is.
Would be nice to add a seamless ability to call executable UDFs from clickhouse-local, last time I checked clickhouse-local required executables to be in a special directory (as in proper clickhouse). Instead it'd be nice to be able to reference any executable in an ad-hoc way.
Yes, however (neo)vim plugin installation still isn't as easy to work with as a one click package / language server install like in VSCode. I thought OniVim would bring that but it seems it is not anymore.
CodeMirror 6 is an awesome piece of software and very flexible — I was even able to build a notebook UI with it — https://bqnpad.mechanize.systems/notebook — this is a notebook (WIP) for BQN[1].
The nice thing is that the whole notebook is a single CodeMirror editor with cells stored as ranges in CodeMirror state. This way intercell actions like selection/copy/paste are possible and still you can control execution per cell.
