I am working through the documentation on Sanctuary.js. I've been working on learning Haskell also, and struggled a bit with FP concepts.
I understand that a type value is an object that has (a) a constructor (the type representative), (b) a type identifier (the name of the type as a property named
@@type
, and (c) any methods required to be implemented by the type. What is the difference between a FP type value and normal object-oriented objects, besides the type value not having any state? The Fantasy-Land specification gives standard types to implement, including methods on them. Some (all?) of those methods obey algebraic laws, likeFunctors
requiring amap
method that obeys the identity and composition laws. Am I free to create my user types and require the methods I like on them? Do those methods have to conform to any algebraic design principles or laws? If not, it sure seems like OO design (minus state in the object) to me! I don't know what I'm missing. Are types like interfaces? Parent objects?The Sanctuary documentation talks about an "accessible pseudotype" - the type of values which support property access, or every value except
null
andundefined
. It says that "Object
is close, butObject.create(null)
produces a value which supports property access but which is not a member of the Object type". But printing an object created withnull
shows{}
, and itstypeof
beingobject
. It seems like a member of the Object type to me. What am I misunderstanding? Why is theAccessible
psuedo-type necessary? And what is the difference between a pseudo-type and a regular type?Integer
, for example, is called a pseudo-class, but it seems like an extension of theNumber
class to me.
It's not only that they don't have any mutable state, they don't carry any values like OOP instances do. They're more like the class of OOP object. They are JS objects with only static methods, or put differently: a record that contains plain functions.
Yes!
No. Yes. You can write unlawful methods, and nothing will stop you. Even in Haskell, these laws are not enforced by the compiler/typechecker. (Usually).
They might even work. But they break the assumptions of other developers, and they break the assumptions that code written by those developers relies on to work.
Yes, that might be a good metaphor. Or at least, the type classes instantiated by the type objects (a reification necessary in JavaScript) are the interfaces that are implemented by the type.
"Member" probably refers to
instanceof
here - andObject.create(null) instanceof Object
isfalse
, because it does not inherit fromObject.prototype
. Other accessible but non-Object
objects might be values from other realms, like an iframe environment.