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

Split records of TauT and RhoT #388

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

Conversation

matil019
Copy link
Member

Part of #382, continuation of #384

This PR refacters the internal of the compiler so that the two types, TauT and RhoT no longer are simultaneously sum types and record types.

I tried as much as possible for each commit to have API change of one function, so refer to the commit logs for the detailed changes. The following are the important changes.

A breaking change

There is a breaking change visible outside of the compiler.

Only type variables are accepted as generics parameters. The following code is no longer valid:

native emptyListFoo java.util.Collections.emptyList {[a]} :: () -> STMutable s (List [a])

(the {[a]} is the offending part.) It had been an unintended use of generics parameters. This change was introduced to refine the type of the grammar gargs (see below).

Main changes

TauT

  • TauT.TCon and .TVar were split into independent data types: TCon and TVar, respectively.
  • The type of SigmaT.vars was changed from [Tau] to [TVar QName].
  • The types of SymT.gargs SymV.gargs and SymA.vars was changed from [Tau] to [TVar QName].
  • SymC.tau :: Tau was changed to SymC.clvar :: TVar QName.

RhoT

  • TauT.RhoTau and .RhoFun were split into dependent data types.

Grammar (Frege.y)

  • The type of gargs was changed from [TauS] to [TVar SName].
  • The types of tyvar, dvars, nativespec and methodspec were changed similarly.
  • A new grammar gargvars :: [TVar SName] was added.

New errors

Internal errors

The following are internal errors. I doubt any of them actually occurs unless something goes very wrong.

  • frege.compiler.gen.java.InstanceCode.symItau :: SymI a -> RhoTau QName is a new function that tries to extract RhoTau QName from SymI.typ.
  • frege.compiler.passes.Imp: a new local function nTVar was added. It is a partial function that tries to extract TVar QName from a TauA annotation. As long as annotations are kept intact, it succeeds.

Performance concerns

fregec

The performance of the compiler was tested by compiling the source at master with different versions of fregec.jar.

The command make clean compiler1 was run 15 times each.

branch commit id average secs %
master a3c4f77 78.583 100
no-sum-symbolt 11bdb3f 81.900 104.2
(refactor TauT) f688cda 81.908 104.2
no-sum-rhot 0d51a6c 82.024 104.3

fregedoc

TODO

frege IDE

Not tested because I don't have an IDE but the same performance drop as fregedoc is expected.

This is needed by the lenses to be added later.
See frege/compiler/types/Symbols.fr

As a first step to decomposing the sum-record SymbolT, SymT was isolated
to an independent data type.

Some parts of code were deliberately rewritten into refutable case
analyses so that compiler warnings are triggered.
The field accessors of SymbolT were replaced with lenses.

Partial functions were deliberately introduced to trigger compilation
warnings where certain constructor is implicitly assumed (for example,
an unsafe conversion `SymbolT g -> SymD g` is inserted to a piece of
code which accesses `flds`, which exists only on `SymD`.)
Lots of redundant unsafeToSymVs and its friends were removed.
by tightening the types of parameters
- removed redundant pattern from `sref`
- changed the type of `overSig` to take `SymV Global`
By changing the type of the local function `rbSymT` to return `SymT`
by tightening the types of parameters
allvars was changed from monadic value to a plain function because it
doesn't change nay state.

Some functions in other modules had their parameters tightened.
For consistency with NatDcl.gargs
nTVar is a new partial function that pattern matches the return value of
nTau and throws an error against non-TVars.
Unless annotations are corrupted, it should not encounter an error.
Now all of the unsafe functions (partial matches) are no longer used,
they were removed.
In the original implementation, it always returned 'false' if one of its
argument was 'Meta'.

The all use-sites of 'Methods.matches' were checked to make sure no
'Meta's are passed to it.

Now the function is an alias of 'TauT.textualEq', which does compare two
'Meta' for textual equality.
The original function was renamed to tcTau for the sake of (use-site)
abbreviation
Now all of the unsafe functions (partial matches) are no longer used,
they were removed.
I added them because I thought they would be useful, but they weren't.
Without changing any "public" api.
Added lenses and unsafe accessors. The uses of the latter will be
removed in following commits.
The pattern matching becomes partial.
Perhaps the return type has to be reverted to Rho but the fact that a
lot of use-sites assume that the return value is RhoTau.
It's unused.
Uses of unsafe functions in unifyRho were removed.
It's unused.
Actually, sigmaInst itself is unused.
Changes in this commit affect the internals of functions or the
parameters of private functions only.
The error case occurs when a data constructor is not a RhoFun i.e. has
no parameter. It should never happen because matchNew is supposed to
handle newtypes only.
Ignoring pattern match failure cannot be justified because otherwise
higher order functions with possibly Rank-N types will be corrupted.

I think the new return type @maybe (RhoTau QName)@ is more descriptive
than the original @rho@ in case of pattern match failure.

Some error cases were restored. A couple of partial cases were added.
A new partial case was introduced to frege.ide.Utilities.label, but I
believe it never happen because SymI.typ is not really a Sigma but a
pair of [Context] and Tau.
I expect the partial case will be eliminated in my upcoming work for
MultiParamTypeClasses.
All of ide.Utilities, tools.doc.Utilities, and
compiler.gen.java.InstanceCode rely on the same (type-unsafe) invariant,
so it was extracted as a new function.

Note that the function is intended to be a a temporary measure until I
implement MultiParamTypeClasses and perform a required refactoring in
which SymI.typ will be broken down into ctxs :: [Context] and
tau :: Tau.
To avoid unnecesary performance drop. Indeed, this commit appears to
eliminate the drop introduced by this branch.
Since the record update syntax @foo.{bar <- f, baz <- g, ...}@ is
desugered into individual updates @foo.{bar <- f}.{baz <- g,}...@, it
may be a performance loss, as it was in using lenses.
Removed unwanted diffs introduced by a series of modifications
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.

1 participant