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

Delay analysis of assignability of default values to invocation #594

Open
quintesse opened this issue Feb 8, 2013 · 4 comments
Open

Delay analysis of assignability of default values to invocation #594

quintesse opened this issue Feb 8, 2013 · 4 comments
Assignees
Milestone

Comments

@quintesse
Copy link
Member

I'd asked @gavinking if this was possible:

Integer|Absent parseInt<Absent>(String? intstr, Integer|Absent default = null)
       given Absent satisfies Null {
   if (exists intstr) {
       return parseInteger(intstr) else default;
   } else {
       return default;
   }
}

and it is except for the default value of null, which results in null not assignable to Integer|Absent. Postponing that check to the invocation site would make this work.

Low priority.

@lucaswerkmeister
Copy link
Member

I’m a bit afraid that the error message for

Integer i = parseInt<Nothing>("10");

might be confusing, because the argument that’s not assignable to its type (null) isn’t present here. Would the error be attached to the parseInt node?

@gavinking
Copy link
Member

Would the error be attached to the parseInt node?

Um, that, or to the argument list, perhaps. Not sure.

@lucaswerkmeister
Copy link
Member

Would this also apply to default type arguments? (Of course, that question doesn’t make much sense until #961 is fixed.)

That would make my type system Turing machine a lot easier to use. At the moment, I have the following function:

// humongous return type omitted
t
<out State, out LeftStack, out LeftRest, out RightStack, out RightRest, Left, Right>
(B<State, LeftStack, RightStack> state, Left left, LeftRest leftRest, Right right, RightRest rightRest)
given State satisfies Q
given Left satisfies S
given Right satisfies S
given LeftRest satisfies Stack
given RightRest satisfies Stack
given LeftStack of StackEnd|StackHead<Left, LeftRest>
             satisfies Stack
given RightStack of StackEnd|StackHead<Right, RightRest>
             satisfies Stack

The arguments for left, leftRest, right and rightRest are always state.second.first, state.second.rest, state.third.first, state.third.rest, but in the t declaration that’s not necessarily well-typed, so I can’t use these as default arguments and instead need to always specify them like this.

@lucaswerkmeister
Copy link
Member

Maybe this should only happen for especially annotated parameters (e. g. with 'late')?

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

No branches or pull requests

3 participants