Right now we have 2 inherited attributes that get passed around to basicly everything:

Merge returnType into env,about melt-umn/ablec

tedinski commented on June 27, 2024

There are contexts where env makes sense but a return type does not. I'm not why trying to push these together is useful?

from ablec.

krame505 commented on June 27, 2024

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> .

from ablec.

ericvanwyk commented on June 27, 2024

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 <[email protected]> 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> .

from ablec.

krame505 commented on June 27, 2024

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 <[email protected]> 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> .

from ablec.

ericvanwyk commented on June 27, 2024

Fair point, but I think that for host language concerns we don't have to put them in the env. But for extensions that need this information for forwarding then we have less choice. On Wed, Mar 1, 2017 at 8:38 PM, Lucas Kramer <[email protected]> wrote:

…

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> .

from ablec.

krame505 commented on June 27, 2024

Just wanted to mention another motivation for this that I discovered.
I have found when working on the templating extension that it really is needed in many cases to include a 'resolved' type as a parameter to custom type productions (the refId hack only gets you so far, especially when you are forwarding to something that is injecting globalDecls that are based on something in a header file.) Because of this, we sometimes want to be able to write 'factory' functions to generate types, parameterized by the environment instead of a resolved type. These work by constructing the coresponding type expression, and then decorating it to find the type.
In order to do that decoration, we need to supply returnType as well as the env. We could just set returnType to nothing() since a TypeName that uses returnType somehow to determine its typerep is only possible in some really bizarre ASTs... but to do things right, returnType should be another parameter to these factory productions.
Then another extension writer who wants to use mkVectorType for some reason needs to pass in the current return type, which is extremely non-intuitive.

from ablec.

krame505 commented on June 27, 2024

Hmm, as a side-note, I just realised that we already do have this information in the environment, via currentFunctionItem in the MiscItem namespace. Is this item actually being used for anything? This is never looked up in the host, and I can't seem to find or think of any extension that would utilize this.

from ablec.

Merge returnType into env about ablec HOT 7 OPEN

Comments (7)

Related Issues (20)

Recommend Projects

React

Vue.js

Typescript

TensorFlow

Django

Laravel

D3

Recommend Topics

javascript

web

server

Machine learning

Visualization

Game

Recommend Org

Facebook

Microsoft

Google

Alibaba

D3

Tencent