proposal: fully-qualified type representatives

[davidchambers]

This is an issue in spirit rather than a pull request. I am submitting the proposal in pull request form to facilitate threaded discussions and to allow changes to be made and tracked via Git.

The proposal is, I believe, sufficiently detailed, so I won't repeat myself here.

I asked @Avaq to review the proposal earlier today. He noted that this approach solves rpominov#3. Aldwin has many ideas on this topic, which I hope he will share here. :)

/cc @alexandru, @robotlolita, @rpominov

[Avaq]

I believe this to be an alternative to (if not an extension of) #286 which solves the problem described in rpominov#3 with the proposed type representative constructors.

Perhaps it could be worked into his fork of Fantasy Land, closing rpominov#3 and unblocking progress towards #286. Although this fork also introduces TypeScript types, which I think not everyone (including myself) would agree with.

---

The only idea that I think is worth sharing, is the idea of using a Symbol instead of a String ('fantasy-land') to associate values with their type representative. A Symbol would have the following benefits:

• Two conflicting versions of Fantasy Land would automatically not interact with each other, because they would have two different symbols. More on this thought (before Symbols existed) here: Reference to a canonical module in values static-land#45 (comment)
• Symbols can be used to mutate prototypes of built-ins without stepping on anyone's toes. Now I'm not entirely sure about this second point, but it seems to be similar to what would happen with first class protocols, and thus take a step towards First-Class Protocols #291. This would enable us to associate Type Representatives directly with String, Number, etc, without the need for a function like the proposed typeRep:

  fantasy-land/proposal.js

  Lines 123 to 138 in 6a4c689

  	//# FL.typeRep :: a -> TypeRep a
  	//.
  	//. Returns the given value's type representative.
  	FL.typeRep = function typeRep(x) {
  	switch (Object.prototype.toString.call (x)) {
  	case '[object Array]':
  	return FL.Array (x.length > 0 ? typeRep (x[0]) : FL.Unknown);
  	case '[object Number]':
  	return FL.Number;
  	case '[object String]':
  	return FL.String;
  	default:
  	if (x != null && 'fantasy-land' in x) return x['fantasy-land'];
  	throw new Error ('Not implemented');
  	}
  	};

[davidchambers]

---

I've been thinking of proposing a new Fantasy Land logo for some time. If we are to release a dramatically different version of the specification, I propose that it be accompanied by a new logo (the logo above is one option). We could encourage project maintainers to adopt the new logo coincident with supporting the new version of the specification, so users could tell at a glance which projects support the new version.

@puffnfresh, did you create the current logo? How do you feel about the possibility of replacing it?

[davidchambers]

[Symbols] would enable us to associate Type Representatives directly with String, Number, etc, without the need for a function like the proposed typeRep

That would work for nullary types, but we would still provide typeRep because the type representative of [1, 2, 3] should be Array (Number) rather than Array (Unknown).

[davidchambers]

I'm going to move ahead with this proposal. Expect a substantial pull request in the coming weeks. :)