-
Notifications
You must be signed in to change notification settings - Fork 13
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
Import module collisions #235
base: main
Are you sure you want to change the base?
Conversation
0xtimmy
commented
Dec 7, 2023
•
edited by ulysses4ever
Loading
edited by ulysses4ever
- added compiler passes to resolve imports:
- ModuleFillImports.hs runs in the parser to handle import metadata (qualified/unqualified, specs, aliases)
- ModuleRename.hs renames imported identifiers so they have compliant characters
…, next up is actual resolution logic
minor cleanup of README and gibbon-compiler/gibbon.cabal
Cool! The current issue is that some tests fail in the build phase when you run them in bulk via
(as can be seen in the CI here) versus when you run them individually via
Is that right? |
yes, I'm also not sure why it's printing out the rust and c config |
It looks like it does this on the In the meantime: can you try to rebase on |
Fingers crossed, it should pass the tests. I hope to look into code quality this coming week, so let’s maybe not merge it right away. In the meantime, you absolutely have to rebase your branch on top of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some excellent work here. But please, act on the comments.
{-# LANGUAGE FlexibleInstances #-} | ||
{-# LANGUAGE FlexibleContexts #-} | ||
|
||
module Gibbon.Passes.FreshConstructors (freshConstructors) where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please, add haddock-comments for every of the three passes you add: module-level and the main-function level. For inspiration, see Fllatten.hs
:
- module-level:
gibbon/gibbon-compiler/src/Gibbon/Passes/Flatten.hs
Lines 6 to 7 in efd6b60
-- | Put the program in A-normal form where only varrefs and literals are -- allowed in operand position. - main-function level:
gibbon/gibbon-compiler/src/Gibbon/Passes/Flatten.hs
Lines 24 to 31 in efd6b60
-- | Flatten ensures that function operands are "trivial". -- -- In the process, it also lifts lets out of case scrutinees, if -- conditions, and tuple operands. -- -- Note that it does not require tail expressions to be trivial. -- For example, it allows AppE and PrimAppE in the body of a -- let-expression.
@@ -313,6 +313,7 @@ data FunMeta = | |||
FunMeta | |||
{ funRec :: FunRec | |||
, funInline :: FunInline | |||
--, funModule :: String |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mm, why is this commented-out?
Nothing -> acc | ||
Nothing -> error "how did we get here?" | ||
|
||
let importedConstrs = foldr (\(Prog idefs _ _) acc -> acc ++ (foldr applyImportMeta [] (L.map (\(constrName, _) -> (toVar constrName)) (foldr (\(DDef _ _ dataCons) acc -> acc ++ dataCons) [] idefs)))) initImportedNames imported_progs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about we split this line into several? E.g. one foldr
per line...
@@ -179,6 +181,40 @@ type TopTyEnv = TyEnv TyScheme | |||
|
|||
type TypeSynEnv = M.Map TyCon Ty0 | |||
|
|||
-- ======================================================== | |||
|
|||
getImportMeta :: [H.ImportDecl a] -> M.Map Var (Var, Bool, Maybe [Var]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I may have mentioned it elsewhere but I want to reiterate: this Map is a core data structure in your work, and that's why It should have a name introduced either as type
or a newtype
(the former is easier of a change but long-term less sustainable).
… of internal type names
Test case changes
gibbon-compiler/solve_ilp_-34.py
Outdated
@@ -0,0 +1,22 @@ | |||
from docplex.mp.model import Model |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR adds three py-files inside gibbon-compiler
: I don't think they should be there. they seem to be leftovers from the layout work which is not related to this PR?..
@@ -148,7 +148,7 @@ newUniq = state (\x -> (x, x+1)) | |||
|
|||
-- | Generate a unique symbol by attaching a numeric suffix. | |||
gensym :: MonadState Int m => Var -> m Var | |||
gensym v = state (\n -> (cleanFunName v `varAppend` "_" `varAppend` toVar (show n), n + 1)) | |||
gensym v = state (\n -> (cleanFunName v `varAppend` toVar (show n), n + 1)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you explain why this underscore was removed? Preferably with examples.
gibbon-compiler/build.log
Outdated
@@ -0,0 +1,8 @@ | |||
Build profile: -w ghc-9.2.8 -O1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The *.log files don't belong in the repo.
deriving instance | ||
(NFData (TyOf ex), NFData (ArrowTy (TyOf ex)), NFData ex, | ||
Generic (ArrowTy (TyOf ex))) => | ||
NFData (Prog ex) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did you actually edit this line or just reformatted it? If the latter, then better to revert this. If you want to improve formatting, please, submit a separate patch. Alternatively, you could have a separate commit for formatting changes. Currently, there are 73 commits in this PR: that's too many. Please, research (or ask me) how to "squash" commits. One commit is probably enough for the feature (modules) itself. Another commit could be about formatting.
Same applies to all the formatting-only changes, not just this line. E.g. in this file above there are many import-list changes that only reformat it. It better go into a separate commit.
data ProgModule ex = ProgModule String (Prog ex) [ImportDecl SrcSpanInfo] | ||
data ProgBundle ex = ProgBundle [ProgModule ex] (ProgModule ex) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be awesome to add comments to individual fields, see an example here: https://kowainik.github.io/posts/haddock-tips#what-can-be-documented
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is great, I'll go through and clean up what comments I have
|
||
type Prog0 = Prog Exp0 | ||
|
||
------------------------------------------------------------------------------- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why the empty lines and the dashes? I'd just continue the list of aliases that was already there (with Ddfe0, FunDef0, etc.)
@@ -34,13 +34,24 @@ newtype TcM a = TcM (ExceptT Doc PassM a) | |||
instance MonadFail TcM where | |||
fail = error | |||
|
|||
runTcM :: TcM a -> PassM (Either Doc a) | |||
runTcM :: TcM a -> PassM (Either Doc a) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are many space-only edits in type signatures in this file that don't make sense to me. Could we revert them?
(PrintChar, [c]) -> do | ||
tell $ string8 (show c) | ||
pure $ VProd [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mm, I'm surprised to see this change. Is it related to modules at all?
{- | ||
fst $ runPassM defaultConfig cnt0 | ||
(freshNames l0 >>= | ||
(\fresh -> dbgTrace 5 ("\nFreshen:\n"++sepline++ "\n" ++pprender fresh) (L0.tcProg fresh))) | ||
(freshBundleNames l0_bundle >>= | ||
(\bundled -> dbgTrace 5 ("\nFreshen:\n" ++ sepline ++ "\n" ++ pprender bundled) | ||
(L0.tcProg (fst $ runPassM defaultConfig 1 | ||
(freshNames (fst $ runPassM defaultConfig 0 | ||
(bundleModules bundled) | ||
)) | ||
)) | ||
) | ||
) | ||
-} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The stuff that's commented out should just be erased.
@@ -0,0 +1,61 @@ | |||
# Poly |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file is also a layout-patch leftover?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was leftover notes for myself, good to remove from the diff
Hey @0xtimmy! I pushed the first bulk of comments to your modules work. The comments are very cosmetic so far, but addressing them would make further reviewing easier... |
tcFun :: DDefs0 -> Gamma -> FunDef0 -> PassM FunDef0 | ||
tcFun :: DDefs0 -> Gamma -> FunDef0 -> PassM FunDef0 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a bunch of this <space><space>
in the diff. How did it happen and can we get rid of them?
main :: Tree | ||
main = add1 (Node (Leaf 1) (Leaf 2)) | ||
gibbon_main :: Tree | ||
gibbon_main = Add.add1 (Node (Leaf 1) (Leaf 2)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was annoyed that this example doesn't compile too. But does this change fix it? I seem to remember that gibbon_main
can only return scalar types, I think (Int
, etc.). Maybe adding a summation over the resulting tree could make it work?
Hey @0xtimmy! Will you be able to work on finishing touches to it a little more over the semester? (It's okay if not, we just need an idea of what to expect.) There's some minor comments left. And then the CI (GitHub Actions) is red: we have to make it green... Rebasing on top of |