Viewing profile — lkitching

I've already shown that type hints do not constitute type checking: (defn f [^String s] (.length s)) (f 3) is a valid Clojure program that fails at runtime with a cast error. class…

Of course Clojure has to ultimately be compiled into a native format for the host platform, bytecode in the case of the JVM implementation, but that doesn't require type checking i…

Protocols do not work like Java interfaces or classes. Their methods are compiled into regular functions which lookup the implementation to use at runtime based on the runtime type…

Neither defprotocol nor deftype introduce static typing into Clojure. Errors in their usage are not checked statically and are only discovered at runtime.

That just means the semantics of the language are defined by whatever the default implementation does. It's a big stretch to conclude that means Rust 'was' OCaml in some sense when…

I'm not convinced the implementation language of the compiler counts as a feature of the Rust language. If the argument is that Rust wouldn't have been invented without the origina…

Which OCaml features exist in Rust but not Haskell? The trait system looks very similar to Haskell typeclasses, but I'm not aware of any novel OCaml influence on the language.

The way in which monads are monoids isn't really helpful for understanding them for progamming.

Since this defines an interface, does this solve the null problem? e.g. Maybe foo = null; foo.map(s -> "bar"); explicit pattern matching is usually discouraged anyway though, and y…

How is this related to Brexit? Ireland have had a low corporation tax rate for the last 20 years, long before the Brexit vote.

Assuming you're referring to *1, *2, *3 and *e, these are only defined within the REPL and are never used in real programs.

The OP is contrasting between a 'validation' function with type e.g. validateEmail :: String -> IO () and a 'parsing' function validateEmail :: String -> Either EmailError ValidEma…

The post is suggesting that parsing and validation are different things, since the output of a parser captures the properties being checked in the type, and validation does not. Do…

Arguably the resource is the dataset of stock exchanges, and the CSV representation is forced to omit all the metadata but the HTML representation isn't.

There's been a fair amount of churn in the ecosystem, even if the language itself has been very stable. Leiningen was ubiquitous 5-6 years ago, but if you switched to using deps fo…

All those links are to the first game, not Wipeout 3.

Sorry for the confusion, but regardless of whether you call it casting, conversion, or something else, it's still trivial to do safely in one directly and impossible to do safely i…

> I said why does it even matter not why can't you do it I've explained why it matters - the types are more precise in my version and if you start from that you can always throw aw…

> First, Why does this even matter? The reason you can't write my version using yours is that the types are less precise and you can't recover the imprecision in the output type af…

> This is just your arbitrary preference It's not arbitrary since it's possible to write your function using mine but not vice versa. If you disagree then please implementing the f…

> The structure of the code handling this type of div is identical to code handling an actual exception You would never write an exception handler to handle such a failure from div…

> There is nothing weak going on here The type for your static version of div is: def div(x: Int, y: Int) -> Optional[Int]: The precondition for the dynamic behaviour of div is tha…

Div always returns an int as long as the precondition - that the divisor is non-zero - is satisfied. The caller is always responsible for ensuring the precondition is satisfied whi…

My first preference is to change the type of the divisor to NonZero[Int], and throwing an exception within div is only my second preference. It doesn't make sense to change the ret…