Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PHI 11 - Type Constructors #13

Open
wants to merge 181 commits into
base: master
Choose a base branch
from
Open

PHI 11 - Type Constructors #13

wants to merge 181 commits into from

Conversation

hejohns
Copy link

@hejohns hejohns commented Jul 16, 2021

No description provided.

bkase and others added 30 commits March 20, 2021 20:23
Merges in content from PHI 5 (type variables) with latex judgements
for bidirectional type elaboration and kind synthesis/analysis. Will
follow up with content from the PHI 3 (type aliases) later.
need to make a TypeEquiv^ and a TypeEquivv
except the rules are obnoxiously opaque and derivations tediously convuluted
@hejohns hejohns marked this pull request as ready for review July 10, 2022 05:34

## Introduction

see my SURE poster for a motivating example.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this still needs to be written

@@ -0,0 +1,699 @@
\ProvidesClass{joshuadunfield}[2015/06/20 - Minor revision]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

jana dunfield no longer goes by joshua so let's rename this style file

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,920 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are two 11-type-constructors.tex files, one here and one in the parent directory. which one am I reviewing? please consolidate.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

d549b0c

(I was using the upper .tex to generate the .md phi information)

I've been getting problems w/ \newcommand{\mathcolor}{..} redefinition
in this file recently (w/ the old 2015 version).
How did this ever compile? Something upstream with amsmath or something
must've changed since none of the previous commits build
I swear it worked before though
Copy link
Member

@cyrus- cyrus- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Gave everything at least a quick look. Have you checked that the rules in the PDF still correspond to what is implemented in algo?

See comments otherwise. Do you think you'll have time soon to implement into Hazel now that type variables are imminent?

@@ -0,0 +1,13 @@
\documentclass[12pt]{article}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this file should be deleted I think.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's to generate the markdown file
I can delete it since it seems like it's confusing

| Π TID Knd Knd
deriving (Show)

-- I'm afraid that sooner or later I'll run into a case where just using De
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why didn't you use de Bruijn indices? (that's what we're doing in the Hazel implementation)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the time, I thought:
-- the phi uses variable names, so the implementation might as well too to make sure the renaming rules are right
-- it might be easier to debug w/o de Bruijn indices
-- I was going to use a Barendregt convention anyways, so it should be a little easier to implement
(of course the third point doesn't actually make sense, and is somewhat opposed to the first)

I agree in retrospect that I should've done de Bruijn indices like you'd said at the beginning, but I was still learning these things and wrote all the renaming stuff early on

Now there's not much point in changing it in the haskell implementation right?

| Ctx :⌢⌢⌢ EAssump
deriving (Show)

-- TODO: this is c/p from ECtx
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is this TODO saying? that the external and internal languages are the same?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah that the external and internal type level languages are the same, but the internal language should have kind casts

-- The internal type language
-- (following ``convention'', we speak of terms and types, not types and kinds
-- in the context of normalization)
-- TODO: In the future, should contain kind casts for a full gradual
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what can't currently be expressed?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if you write something like

type T = Int in
type V = λt::KHole.t Bool in
type Bogus = V T in
...

kind casts would let you express why Bogus is bogus

False
, Nil ⊢ tequiv (Tλ "t" Type $ TVar "t") (Tλ "t" Type Bse) Type ~?= False
, Nil ⊢
tequiv (Tλ "t" Type $ TVar "t") (Tλ "t" Type Bse) (Π "t" Type Type) ~?=
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"t" isn't in scope in the annotation on Tλ right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, although I'm confused what that has to do with those tests?

-- tequiv τ1 τ2 κ = \aΓ -> Algo.tequiv aΓ τ1 τ2 κ
-- since application precedence is so high (and can't be competed against)
tequiv :: _
tequiv = ((.) . (.) $ flip) . ((.) flip) . flip $ Algo.tequiv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uhhh

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just wanted to try to rearrange the arguments point free/with combinators. To see if I could do it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants