specify Show type class

I would ❤️ a Haskell-like Show type class. Useful functions such as R.toString, S.toString, and Z.toString rely on toString methods, but there’s a problem with this approach:

//  Person :: (String, String, String) -> Person
function Person(firstName, lastName, emailAddress) {
  if (!(this instanceof Person)) return new Person(firstName, lastName, emailAddress);
  this.firstName = firstName;
  this.lastName = lastName;
  this.emailAddress = emailAddress;
}

//  Person#toString :: Person ~> () -> String
Person.prototype.toString = function() {
  return '"' + this.firstName + ' ' + this.lastName + '" <' + this.emailAddress + '>';
};

In this case, Person#toString serves some other useful role.

It would be nice to be able to define this as well:

//  Person#fantasy-land/show :: Person ~> () -> String
Person.prototype['fantasy-land/show'] = function() {
  return 'Person(' + Z.show(this.firstName) + ', '
                   + Z.show(this.lastName) + ', '
                   + Z.show(this.emailAddress) + ')';
};

With a suitable definition for Person#fantasy-land/equals, one could then write:

> var puffnfresh = Person('Brian', 'McKenna', '[e-mail]')

> Z.equals(eval(Z.show(puffnfresh)), puffnfresh)
true

I’ve found myself giving a function a Showable a constraint from time to time, but this is currently almost meaningless as the presence of a toString method does not imply eval(show(x)) = x.

[paldepind]

@davidchambers

Thank you for explaining. If I understand correctly, actually using the output with eval is not the primary goal. It’s just a guideline for implementing the show method. I can definitely see how such a method can be useful 😄 . It’s purpose does lies very close to the toString method though.

It’s currently the place for defining type classes.

I would argue that what Fantasy Land specifies is not type classes but interfaces. It specifies methods on objects. That is exactly what many languages calls “interfaces”. Type classes, on the other hand, are something else. It may seem like nitpicking, but I think it’s an important distinction to make. Type classes and interfaces are different in ways that make a difference for several of the Fantasy Land abstractions. At leas monoids and applicatives. Therefore I think that calling what Fantasy Land defines “type classes” is misleading. “Interfaces” fit the bill.

I suppose we could specify sanctuary/show in sanctuary-type-classes. Do you think this would be more natural?

Yes, I think so. I think the scope of Fantasy Land is to define interfaces for algebraic structures. That is also what the readme seems to imply. There are practically an unlimited number of possible interfaces so putting the line somewhere is nececarry.

[davidchambers]

I get a bit worried at 4 and 5. Will S.show continue to provide sane @@show implementations for primitives and built-ins?

Nothing would change in this respect. We’d simply move Array$prototype$toString and friends to the new package and replace toString with show.

I like @paldepind’s idea with serialize/deserialize.

I now realize the issue description is misleading. I should have made it clear that eval(show(x)) = x is a guide for producing useful string representations for logging and for REPLs. It is not intended to be used for serialization (though it may occasionally be suitable for this purpose).