3 ms·
Well...that's still just a type. I never found any reason to name it specially myself, even when I was thinking of similar things that are being described in th
by jhgb 5y ago
Well...that's still just a type. I never found any reason to name it specially myself, even when I was thinking of similar things that are being described in the article (though not about Ruby, but rather about Lisp-y languages). Maybe I'm a bit influenced by the fact that there isn't such thing as "a type that you cannot express in the domain language" if you have SATISFIES (http://www.lispworks.com/documentation/HyperSpec/Body/t_satisf.htm http://www.lispworks.com/documentation/HyperSpec/Body/t_sati...), but still - a compiler can certainly synthesize "ad-hoc", unnamed types and perform reasoning with them.
- chrisseaton 5y ago> Well...that's still just a type. By this argument I might as well call everything a 'thing' since everything is still just a thing. Different names for subclasses of things that already have names is useful. I get this discussion with people who don't like the word 'transpiler' because they reason it's just another compiler. Yeah nobody's denying that - it's a subclass of compiler with a specific name.
- jhgb 5y agoTo be fair, "lispy" thinking promoted the notion of closure property in me - just like a list of lists is still a list, a type composed of other types, be it by conjunction or by disjunction, is still a type, and its components are types as well. Uniform treatment seems more logical specifically for programming it into a machine since it eliminates special cases. So I'm tempted to disagree with the assertion that I may need special cases for this.