4 ms·

Hmm. I usually see "nominal" in this context as "matched on basis on type name", as opposed to "matched on basis of isomorphism" ("structural").

by jhgb 5y ago

chrisseaton 5y ago
Right and you can’t match something by name if you can’t name it.
- jhgb 5y ago
  That's not really true -- in structural typing, you can name things but the names themselves are just a convenience; an alias for something too long to type without getting lost in it.
  - chrisseaton 5y ago
    Well I don't know then. If you've got a better name for a type that you cannot express in the domain language but can be tracked by the compiler that'll be understandable in a public blog post then I'll use it?
    - 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 ago
        To 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.

Hmm. I usually see "nominal" in this context as "matched on basis on type name", as opposed to "matched on basis of isomorphism" ("structural").

by jhgb 5y ago

Hmm. I usually see "nominal" in this context as "matched on basis on type name", as opposed to "matched on basis of isomorphism" ("structural").

chrisseaton 5y ago

Right and you can’t match something by name if you can’t name it.

jhgb 5y ago
That's not really true -- in structural typing, you can name things but the names themselves are just a convenience; an alias for something too long to type without getting lost in it.
- chrisseaton 5y ago
  Well I don't know then. If you've got a better name for a type that you cannot express in the domain language but can be tracked by the compiler that'll be understandable in a public blog post then I'll use it?
  - 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 ago
        To 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.