Skip to content

feat: allow mutual recursion in letrec#26

Open
StoneyJackson wants to merge 1 commit intomainfrom
type1-letrec
Open

feat: allow mutual recursion in letrec#26
StoneyJackson wants to merge 1 commit intomainfrom
type1-letrec

Conversation

@StoneyJackson
Copy link
Member

@jashelio
@fosler

This pull-request attempts to allow mutual recursion in TYPE1's letrec.

I had to use an instanceof in an if statement. I'm not happy with it. Should I add a new method to Exp that either returns the defined type for ProcExp or evaluates the expression for its type? Maybe call it evalTypeInLetrecDecl? Other suggestions?

@StoneyJackson
Copy link
Member Author

For easy reference, here is the offending code fragment

     public TypeEnv addLetrecTypeBindings(TypeEnv tenv) {
        List<String> stringVarList = new ArrayList<String>(varList.size());
        for(Token t : varList) {
            stringVarList.add(t.toString());
        }
        tenv = tenv.extendTypeEnv(new TypeBindings());
        Iterator<Token> varIter = varList.iterator();
        Iterator<Exp> expIter = expList.iterator();
        while (varIter.hasNext()) {
            String str = varIter.next().toString();
            Exp e = expIter.next();
            Type typ = null;
            if (e instanceof ProcExp) {
                typ = ((ProcExp) e).proc.definedType();
            } else {
                typ = e.evalType(tenv);
            }
            tenv.add(new TypeBinding(str, typ));
        }
        expIter = expList.iterator();
        while (varIter.hasNext()) {
            Type typ = expIter.next().evalType(tenv);
        }
        return tenv;
    }

@jashelio
Copy link

Small comment first: I don’t see the point of stringVarList. It’s never used.
I don’t understand what the code after the first while loop is doing. The second while loop will be skipped, and even if that weren’t true, typ is never used. Side effect?
I am surprised that you have to make an exception for a ProcExp. I’m going to have to look at that code.
This is still not checking for repeated variable names, right?
We can talk more tomorrow if there’s time.

@jashelio
Copy link

PS I understand a need to go through twice. You’re trying to deal with mutual recursion.

@jashelio
Copy link

Reviewing the code in the file named "code” in TYPE1,, specifically the Proc class, I understand the dilemma. No quick answer revealed itself, of course. Will continue to think…

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.

2 participants