Implement type aliases

[AlexKnauth]

Adds a type form for type aliases.

(type name-id maybe-fixity type-expr)
(type (name-id param-id ...) type-expr)

• document type

[lexi-lambda]

I haven’t had the chance to look over this in detail yet—I definitely will soon—but my immediate comment is whether or not we want to use a name other than type for this. It’s really one of the worst-named features of Haskell.

(I’ve also been sort of reconsidering naming definition forms things like data, class, and instance lately, but that’s a whole separate question that’s probably out of scope for this pull request.)

[iitalics]

Thats a really good point. At the very least, a more racket-y name like define-type will help indentation since many editors use identifier names to guide indentation style.

If you have a particular name in mind I think we should use it, and that could help get the ball rolling for renaming other forms.

[lexi-lambda]

define-type-alias is a good, long, Racket-y name. It’s also wildly inconsistent with the rest of Hackett as it currently stands, which uses names like def, defn, and data. def-type-alias looks weird to my eye, but maybe I just need to get used to it. deftype or defalias seem icky, and deftypealias is abhorrent. Naming is hard!

[AlexKnauth]

I would lean toward one of these sets of names:

1. type, data, class
2. def-type, def-data, def-class
3. define-type, define-data, define-class

(1) is closest to Haskell, and closest to how Hackett looks currently. It's what I'm leaning toward under the assumption that we don't want to change the existing Hackett forms too much. (3) is closest to Racket's convention. (2) is in between, and could look reasonable next to def and defn definitions.

I don't think we need the word "alias" in the name. The documentation can clarify that. Both Haskell's and Racket's forms don't normally include "alias".

[lexi-lambda]

I don't think we need the word "alias" in the name. The documentation can clarify that. Both Haskell's and Racket's forms don't normally include "alias".

Personally, I think we do. I’ve experienced firsthand the amount of confusion the awful data / newtype / type naming scheme creates. Maybe the issue lies with newtype more than type, but I’m wary either way. What’s wrong with type-alias as a name? Putting the issue of not using def or define prefixes aside for the moment, it seems short enough to be palatable and leaves no chance for confusion.

[iitalics]

For some reason if I uncomment this line, I get an error on line 342. Can you reproduce this?

[lexi-lambda]

Not preserving source locations currently has the unfortunate side-effect of dropping syntax properties, so your use of { curly braces } will be lost. This is a bug in scribble/example that I haven’t bothered fixing.

[lexi-lambda]

This is (morally) Haskell; type variables should be lowercase by convention.

[iitalics]

That's right. Fixed!

[AlexKnauth]

Should we rename it from type to type-alias?

[lexi-lambda]

I think I’m okay with type for now; we can deal with thinking about renaming another time. Is this good to merge?

[AlexKnauth]

Almost. The last think is whether infix should work. Something like this currently fails:

(type (~> t u) #:fixity right (-> t (Maybe u)))
(defn pure : (∀ [t] {t ~> t}) [[x] (Just x)])
;. ~>: expected 2 argument(s) to type alias in: ~>

While writing it as (∀ [t] (~> t t)) works fine.

[AlexKnauth]

Although if we needed to we could specify in the Docs that only prefix syntax is supported when applying type aliases to arguments.

[lexi-lambda]

Ah, yes—the issue here is essentially that infix notation is controlled by #%app, and currently, #%app ensures the expansion is, in fact, a function application. I’ve been thinking this is wrong. There isn’t really a fundamental reason that infix notation shouldn’t be usable with macros, as far as I can tell, so long as the macro accepts two subforms.

I think the fix is to change the #%app/infix desugaring so that it rearranges its subforms but does not implicitly introduce #%app/prefix. The only difficulty is that #%app/infix must take care to prevent getting into an infinite loop due to the way the expander copies syntax properties (since the 'paren-shape property will get copied onto the output syntax and cause problems if the output template has no such property).

[AlexKnauth]

It sounds like that will be a more major change. Should we keep aliases without infix support for now, and think about reworking #%app/infix later?

[lexi-lambda]

I don’t think it should be too difficult, but I agree that it’s outside the immediate scope of this particular feature. I’m happy to deal with the infix issue myself when I get a moment to look at it, if you’d prefer.

[AlexKnauth]

Okay. Should I remove the #:fixity keyword and note the prefix restriction in the Docs?

[lexi-lambda]

I’d leave it as it is for now. I’d consider the lack of infix support a bug in Hackett’s infix implementation a bug more than anything else; I’ll plan to fix it quickly.

[AlexKnauth]

I've changed the docs, adding a margin note to say that they can only be used with prefix notation.

[AlexKnauth]

I would feel comfortable with this being merged now.