What impresses me most about this language is its syntax. There are so many small, clever innovations that I’d love to see more widely used. For example:
Simple macro expressions: IO { ... } makes everything inside the { ... } a do expression in the context of the IO monad.
Sequenced let expressions that just look like variable assignments. (The only other place I’ve seen this is ReasonML)
C-style function calls that are actually curried.
Using ! to infer arguments (usually type arguments), making inference explicit without boilerplate.
Lots of syntax sugar for common FP patterns: <- functional-update setters, <> as shorthand for Option.getOrElse, and an abort operator that’s similar to Rust’s ?.
And, most importantly: the cleanest, most intuitive pattern matching syntax I’ve seen.
What would be opt match { case Some(x) => x; case None => "foo" } in Scala becomes something like case opt { some: opt.value; none: "foo" } in Kind. (That might not be the right names for Kind’s option type.) It knows that opt is a variable and that its type can be narrowed, so in the some branch, its type is some and opt.value is accessible. There’s no destructuring, no ordered arguments, and no special pattern sublanguage.
I completely agree. Having more ways of making the whole milieu of FP/dependent types accessible is an area that I think is underexplored. Rust starts down this path, but I don’t particularly think it’s as ‘nice’ as it could be.
And accessibility is the game. Rust does well enough by having freaking phenomenal compiler errors. You can learn by doing. Go goes the other way, accessibility by minimalism.
This is a very small thing and not really specific to Kind as a language spec or it’s semantics. But over the years I’ve had enough issues with tools installed by npm causing problems for me in the future with upgrade breakages or environmental degradation that I’m always leary to install them.
What impresses me most about this language is its syntax. There are so many small, clever innovations that I’d love to see more widely used. For example:
Simple macro expressions:
IO { ... }makes everything inside the{ ... }adoexpression in the context of theIOmonad.Sequenced
letexpressions that just look like variable assignments. (The only other place I’ve seen this is ReasonML)C-style function calls that are actually curried.
Using
!to infer arguments (usually type arguments), making inference explicit without boilerplate.Lots of syntax sugar for common FP patterns:
<-functional-update setters,<>as shorthand forOption.getOrElse, and anabortoperator that’s similar to Rust’s?.And, most importantly: the cleanest, most intuitive pattern matching syntax I’ve seen.
What would be
opt match { case Some(x) => x; case None => "foo" }in Scala becomes something likecase opt { some: opt.value; none: "foo" }in Kind. (That might not be the right names for Kind’s option type.) It knows thatoptis a variable and that its type can be narrowed, so in thesomebranch, its type issomeandopt.valueis accessible. There’s no destructuring, no ordered arguments, and no special pattern sublanguage.I completely agree. Having more ways of making the whole milieu of FP/dependent types accessible is an area that I think is underexplored. Rust starts down this path, but I don’t particularly think it’s as ‘nice’ as it could be.
And accessibility is the game. Rust does well enough by having freaking phenomenal compiler errors. You can learn by doing. Go goes the other way, accessibility by minimalism.
It’s an art, not a science.
This is a very small thing and not really specific to Kind as a language spec or it’s semantics. But over the years I’ve had enough issues with tools installed by npm causing problems for me in the future with upgrade breakages or environmental degradation that I’m always leary to install them.
Seems you can install it as a Scheme release! I agree about being weary of
npmthough.Interesting, I totally missed the scheme implementation. That makes this much more interesting now.