Merge returnType into env about ablec HOT 7 OPEN

On Mon, Feb 27, 2017 at 4:48 PM, Ted Kaminski ***@***.***> wrote: There are contexts where env makes sense but a return type does not. I'm not why trying to push these together is useful? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIE1ivvJ-iAbE-mLFbf9lVgwYHAlApSGks5rg1KwgaJpZM4MNuNn> .

The only thing I can find where env occurs but not returnType is Name (unless there are other, similar things), but it could still make sense to think about that a name occurs in a context where return is permitted (or not.) We are tending towards env being the entire state for a tree and not just a list of names with some of our extensions now, so in my opinion it makes more sense to be consistent. Also it is just weird in some places for extension writers to need to provide a return type in some places where it just adds clutter (such as in explicit decoration), or when the env would seem to be the only needed thing; this leads to unexpected flow errors when there seems to be no obvious reason to write a returnType equation when decorating a type expression, but really it is needed. Anyway, just my take on things, that we should try to keep the number of inherited attributes in the host to a minimum. I'd like to hear what Eric thinks on this as well. Lucas Kramer On Mon, Feb 27, 2017 at 4:48 PM, Ted Kaminski ***@***.***> wrote: > There are contexts where env makes sense but a return type does not. I'm > not why trying to push these together is useful? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#25 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AIE1ivvJ-iAbE- mLFbf9lVgwYHAlApSGks5rg1KwgaJpZM4MNuNn> > . > — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADOhd_9vxmpoAWHGrlmTRjT6brkVQ-_uks5rg1X3gaJpZM4MNuNn> .

It is true that we're adding more information into env, but I would prefer to keep something separate. return type seems like another form of context that is not something that gets looked up by a name. Having 2 inh attrs is hardly excessive. I'd leave them separate. -Eric On Mon, Feb 27, 2017 at 5:02 PM, Lucas Kramer ***@***.***> wrote: > The only thing I can find where env occurs but not returnType is Name > (unless there are other, similar things), but it could still make sense to > think about that a name occurs in a context where return is permitted (or > not.) We are tending towards env being the entire state for a tree and not > just a list of names with some of our extensions now, so in my opinion it > makes more sense to be consistent. > Also it is just weird in some places for extension writers to need to > provide a return type in some places where it just adds clutter (such as in > explicit decoration), or when the env would seem to be the only needed > thing; this leads to unexpected flow errors when there seems to be no > obvious reason to write a returnType equation when decorating a type > expression, but really it is needed. > > Anyway, just my take on things, that we should try to keep the number of > inherited attributes in the host to a minimum. I'd like to hear what Eric > thinks on this as well. > > Lucas Kramer > > On Mon, Feb 27, 2017 at 4:48 PM, Ted Kaminski ***@***.***> > wrote: > > > There are contexts where env makes sense but a return type does not. I'm > > not why trying to push these together is useful? > > > > — > > You are receiving this because you authored the thread. > > Reply to this email directly, view it on GitHub > > <#25 (comment)>, > or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/AIE1ivvJ-iAbE- > mLFbf9lVgwYHAlApSGks5rg1KwgaJpZM4MNuNn> > > > . > > > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#25 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ADOhd_ 9vxmpoAWHGrlmTRjT6brkVQ-_uks5rg1X3gaJpZM4MNuNn> > . > — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AIE1ilQWpS3xUTOi9q2h0aTevhumQm9_ks5rhirHgaJpZM4MNuNn> .

That is also a reasonable way of looking at things. But I would like to point out then, that if return types don't 'belong' in the env since they aren't actually names, then neither really does extension stuff like the current scope identifier - although in that case there isn't really much choice. Lucas Kramer On Wed, Mar 1, 2017 at 8:34 PM, Eric Van Wyk ***@***.***> wrote: > It is true that we're adding more information into env, but I would prefer > to keep something separate. return type seems like another form of context > that is not something that gets looked up by a name. > > Having 2 inh attrs is hardly excessive. I'd leave them separate. > > -Eric > > On Mon, Feb 27, 2017 at 5:02 PM, Lucas Kramer ***@***.***> > wrote: > > > The only thing I can find where env occurs but not returnType is Name > > (unless there are other, similar things), but it could still make sense > to > > think about that a name occurs in a context where return is permitted (or > > not.) We are tending towards env being the entire state for a tree and > not > > just a list of names with some of our extensions now, so in my opinion it > > makes more sense to be consistent. > > Also it is just weird in some places for extension writers to need to > > provide a return type in some places where it just adds clutter (such as > in > > explicit decoration), or when the env would seem to be the only needed > > thing; this leads to unexpected flow errors when there seems to be no > > obvious reason to write a returnType equation when decorating a type > > expression, but really it is needed. > > > > Anyway, just my take on things, that we should try to keep the number of > > inherited attributes in the host to a minimum. I'd like to hear what Eric > > thinks on this as well. > > > > Lucas Kramer > > > > On Mon, Feb 27, 2017 at 4:48 PM, Ted Kaminski < ***@***.***> > > wrote: > > > > > There are contexts where env makes sense but a return type does not. > I'm > > > not why trying to push these together is useful? > > > > > > — > > > You are receiving this because you authored the thread. > > > Reply to this email directly, view it on GitHub > > > <#25 (comment) >, > > or mute > > > the thread > > > <https://github.com/notifications/unsubscribe-auth/AIE1ivvJ-iAbE- > > mLFbf9lVgwYHAlApSGks5rg1KwgaJpZM4MNuNn> > > > > > . > > > > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#25 (comment)>, > or mute > > the thread > > <https://github.com/notifications/unsubscribe-auth/ADOhd_ > 9vxmpoAWHGrlmTRjT6brkVQ-_uks5rg1X3gaJpZM4MNuNn> > > . > > > > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#25 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/ AIE1ilQWpS3xUTOi9q2h0aTevhumQm9_ks5rhirHgaJpZM4MNuNn> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADOhd4XrNmvSmLnO9QGW1qtRpayKSSAFks5rhiurgaJpZM4MNuNn> .