Comments on: What Constraints Entail: Part 1

By: zzo38

zzo38 — Tue, 26 Jun 2012 18:59:20 +0000

What I have decided for Ibtlfmm it does not use this kind of superkinds (and Constraint is named & while @ is used for program modules, although you can give them alphabetic names if you want using kind synonyms), rather I would think (,) and () and so on are macros that decide the corresponding types according to what fits. There could also be “kind classes” to rebind the syntax, although I prefer using macros. But yes () should be a constraint too. I do not think making up the new superkiind for this purpose is such a good idea (including for the reasons you have described).

By: Doug McClean

Doug McClean — Wed, 16 Nov 2011 21:13:56 +0000

This overloading problem with (,) and () seems like it’s just yet another case of there be insufficiently many kinds of bracketing characters that (a) Unicode encodes, (b) can be typed (keyboarded) easily, and (c) are visually distinguishable.

The same problem arises with {} signifying the empty set and the record with no attributes. Basically the same thing clutters up the possibility of having a nice concrete syntax for all of: lists, sets, bags, vectors, matrices.

At the same time, it adds a lot more noise to require writing Set { 3, 7, 2 } everywhere since just { 3, 7, 2 } doesn’t overlap with the concrete syntax for records like { frog := 2, apple := “moose” }.

It seems like the middle ground approach is to make a lot of granular “re-bindable syntax” type classes for all of the different literals.

Following that approach seems to work well, and ordinary type ascription expressions suffice to resolve the empty cases. Committing to it fully does feel a little silly in some cases though.

For example, zero is more polymorphic than other numeric literals. This arises because zero may have any dimension, but 3.7 is always dimensionless. The only language I know of that encodes this is CSS, although I’m sure there are others.

This sort of thing is leading to my pet language having a large number of type classes which play a role in desugaring, but I think that’s a tradeoff I’m willing to make.

By: Edward Kmett

Edward Kmett — Thu, 03 Nov 2011 15:28:41 +0000

@Dan,

Good catch. I’d had it drawn that way on the whiteboard at work, but somewhere along the way got it flipped.

In practice, I think just doing the right thing and adding @ so we can do the bounded quantification at the kind level is a better idea than trying to preserve the bandaid.

By: Dan Doel

Dan Doel — Thu, 03 Nov 2011 15:23:55 +0000

I don’t think your subtyping scheme fixes the problem for (), either. If ??? includes both Constraint and *, then making () : ??? doesn’t help, because that doesn’t imply the judgments of both () : * and () : Constraint. What you would need is to make ??? a common lower bound for * and Constraint that contains ().

And of course, this is a long way to go to resolve a single case of overloading.