Type Values and "Accessible Pseudotype" in Sanctuary.js (Fantasy Land)

167 views Asked by At

I am working through the documentation on Sanctuary.js. I've been working on learning Haskell also, and struggled a bit with FP concepts.

  1. 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, like Functors requiring a map 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?

  2. The Sanctuary documentation talks about an "accessible pseudotype" - the type of values which support property access, or every value except null and undefined. It says that "Object is close, but Object.create(null) produces a value which supports property access but which is not a member of the Object type". But printing an object created with null shows {}, and its typeof being object. It seems like a member of the Object type to me. What am I misunderstanding? Why is the Accessible 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 the Number class to me.

1

There are 1 answers

4
Bergi On BEST ANSWER

What is the difference between a FP type value and normal object-oriented objects, besides the type value not having any state?

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.

Am I free to create my user types and require the methods I like on them?

Yes!

Do those methods have to conform to any algebraic design principles or laws?

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.

Are types like interfaces?

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.

Printing an object created with null shows {}, and its typeof being object. It seems like a member of the Object type to me. What am I misunderstanding?

"Member" probably refers to instanceof here - and Object.create(null) instanceof Object is false, because it does not inherit from Object.prototype. Other accessible but non-Object objects might be values from other realms, like an iframe environment.