lexi-lambda

9 ms·

1.
by lexi-lambda 1y ago
I can say that I am not particularly concerned with compile-time range checking. I agree with you that it is a massive headache that is almost always a huge waste of time. Even in dependently-typed languages, tracking ranges and bounds ends
2.
by lexi-lambda 4y ago
Yes, certainly. Constructive data modeling is useful for many things, but it’s not a panacea. Other techniques are useful in cases where it’s not practical; I discuss some of the tradeoffs in this followup post: https://lexi-lamb
3.
by lexi-lambda 4y ago
Well, like I said, the subject is extremely broad, so it is difficult to give concrete suggestions without knowing what specifically you’d like to get into. But I can give some potential options. If you’d like to learn Haskell, I think htt
4.
by lexi-lambda 4y ago
You know what, you’re right—I misread your original comment. I was just going through this thread and replying to a number of comments making that particular misconception, since it is particularly common, but upon taking a closer look, you
5.
by lexi-lambda 4y ago
Yes, that’s about right. But really do read the followup blog post ( https://lexi-lambda.github.io/blog/2020/11/01/names-are-not-... ), as it explains that in much more depth! In particular, it says: >
6.
by lexi-lambda 4y ago
Generic is quite specific to Haskell, so it is probably difficult to explain without a little more understanding of Haskell-like type systems. (Rust has some similar capabilities, so that would help, too.) I wouldn’t worry about it too much
7.
by lexi-lambda 4y ago
You come off as a crank. Perhaps you are one, perhaps you are not, I don’t know, but either way, you certainly write like one. If you want people to take you seriously, I think it would behoove you to adopt a more leveled writing style. Man
8.
by lexi-lambda 4y ago
Haskell’s `newtype` keyword defines a genuinely fresh (nominal) type that is distinct from all other types. There is no direct analogue in TypeScript, but using branded types would be the closest you could get. That’s still not quite the sa
9.
by lexi-lambda 4y ago
> In Java, you'd implement this by making a class with a private constructor, no mutator methods, and a static factory method that throws an exception if the parsing fails. This is similar, and is indeed quite useful in many cases,
10.
by lexi-lambda 4y ago
There is really no difference between doing this and returning a `Maybe`, which is the standard Haskell pattern, except that the `Maybe` result also allows the result to be structurally different rather than simply a refinement of the input
11.
by lexi-lambda 4y ago
> As a result I have not found this article a good one to share with junior developers to help them understand how to design types to capture the notion of validity, and to replace validation with narrowing type conversions (which amount
12.
by lexi-lambda 4y ago
> If you are trying to mix NonEmpty and AllEven and AllGreaterThan100 for the List example, then you would get the combinatorial explosion of types. This is overthinking it. Usually, when people are not used to doing constructive data mo
13.
by lexi-lambda 4y ago
Certainly I don’t think `parseNonEmpty` would be especially useful in a real program, it’s only there as an example to provide a particularly simple contrasting example against `validateNonEmpty`. The example earlier in the blog post using
14.
by lexi-lambda 4y ago
You are sort of mistaken. I wrote a followup blog post that discusses what you are describing at some length: https://lexi-lambda.github.io/blog/2020/11/01/names-are-not-... However, TypeScript does not
15.
by lexi-lambda 4y ago
There is a fairly obvious difference between a dynamic enforcement mechanism like contracts or SQL constraints. Though I think it is a bit silly to suggest that I have “never even considered” such things given the blog post itself is render
16.
by lexi-lambda 4y ago
> If you can't create a value of type PrimeNumber that doesn't contain a prime number, there's a bit more to it than naming. Yes, indeed. This is quite useful! But crabbone isn’t entirely wrong that it isn’t quite what the
17.
by lexi-lambda 4y ago
I discussed how/why the point of this article is very much not to “parse everything” in this followup: https://lexi-lambda.github.io/blog/2020/01/19/no-dynamic-typ... In particular, it articulates
18.
by lexi-lambda 4y ago
Amusingly, the tweet that inspired this blog post—which is linked in the second paragraph of the article—is specifically about how automatically generating a JSON parser from your datatypes means you don’t have to implement that kind of
19.
by lexi-lambda 4y ago
> While an element of type bool is an instance of type a, an element of type bool -> bool is not an instance of type a -> a. This sentence is true if you interpret `a -> a` to mean `∀ a. a -> a`, i.e. a universally-quantified
20.
by lexi-lambda 4y ago
I don’t think the complaints about evaluation order in this blog post really make sense. The evaluation order of `map` in SML is no more mysterious than the evaluation order of `mapM` in Haskell. The use of explicit monadic sequencing has i
21.
by lexi-lambda 4y ago
All these explanations seem somewhat confused to me because they don’t pin down what the variables represent. In a traditional formulation of Hindley-Milner, there are two distinct notions of a “variable”: (1) a bound variable under a quant
22.
by lexi-lambda 5y ago
This is sort of a perplexing perspective to me. It seems tantamount to saying “you can’t predict whether a value will be a string or a number AND have static type safety because the value only exists at runtime, and static type safety only
23.
by lexi-lambda 6y ago
In Haskell, a newtype can be a single-field record with a named field, so from a Haskell perspective, I would definitely consider both of them “newtypes.”
24.
by lexi-lambda 6y ago
As was already mentioned in another reply, what you are describing are refinement types . A refinement type system actually exists for Haskell: it’s called LiquidHaskell,[1] and though I have not used it for anything serious, it seems to w
25.
by lexi-lambda 6y ago
Yes, on its own, a newtype is nothing more than a name. The safety comes from pairing a newtype with an encapsulation mechanism and a carefully-designed trust boundary. Without an encapsulation mechanism, I do not consider using newtypes to
26.
by lexi-lambda 6y ago
> What's a better alternative though? I’m not really suggesting there needs to be an alternative. Using newtypes to achieve safety via encapsulation is fine, good even, and I say as such at several points in the article.[1] The poin
27.
by lexi-lambda 6y ago
Read the article more carefully. I wrote in multiple places that the use of newtypes does provide real safety. > If you are fond of newtypes, this whole argument may seem a bit troubling. It may seem like I’m implying newtypes are scar
28.
by lexi-lambda 6y ago
It actually does, though I didn’t mention it in the blog post. Here’s how you write it: data EvenList a = EvenNil | EvenCons a a (EvenList a) deriving (Functor, Foldable, Traversable) But that isn’t really the point of the exampl
29.
by lexi-lambda 6y ago
What is “reasonable”? Suppose we take your argument to its logical conclusion—a type system ought to be able to statically detect any property we desire. In general, this would amount to predicting exactly which value each variable cont
30.
by lexi-lambda 6y ago
I (the author) did not imply that the definition of EvenList I gave would admit [1, 2, 3, 4]—it only admits [1, 2, [3, 4, []]]. Indeed, this is the whole point of the second half of the blog post: you can enforce lots of invariants by mod

More ›