can't print dict, locals fails

[mpmilano]

print({"s" : 3}) yields: [Pointer to address 7305]

print(locals()) yields: exception: object dict has no attribute internaldict

[jpolitz]

There's no more MetaDict to print, so we should define str on %dict, and locals is broken because we didn't address make-under-dict when updating dictionaries. That's part of my desire to move it back to desugaring; it's a really complicated primitive.

I remember that Alejandro did some work with the stk parameter to the interpreter to handle locals, but I'm afraid I'm not sure if I ever understood it fully.

On Fri, Mar 15, 2013 at 12:57 PM, xlnagla notifications@github.com wrote:

print({"s" : 3}) yields: [Pointer to address 7305]

print(locals()) yields: exception: object dict has no attribute internaldict

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/50 .

[amtriathlon]

The use of stk allows locals() to be a function, instead of a macro as it was originally in base code: the local environment retrieved is the one active when locals() instead of the one inside locals() body.

Macro expansion of locals() and super() allows to get rid of stk, but it is quite difficult to get them right, see for example https://github.com/brownplt/lambda-py/issues/27

2013/3/15 Joe Politz notifications@github.com

I remember that Alejandro did some work with the stk parameter to the interpreter to handle locals, but I'm afraid I'm not sure if I ever understood it fully.

Alejandro.

[mpmilano]

I see how that might be complicated - it looks like if we want to make this a macro we'd have to trace locals through assignments and arguments in the entire program.

So it depends how much we need to get it exactly right. We could easily handle the less-complicated cases of this analysis in code right now, put the rest under "future work," and make locals() and globals() purely desugaring constructs. We already have decreed to not support assigning into locals() or globals(), so our implementation of these functions is already stunted.

If we're unwilling to do this, given our time frame it looks like stk needs to stay.

So what'll it be, folks? A macro that works in the majority of cases, or a complicated piece of the interpreter?

~matthew

On Fri, Mar 15, 2013 at 1:26 PM, Alejandro Martinez < notifications@github.com> wrote:

The use of stk allows locals() to be a function, instead of a macro as it was originally in base code: the local environment retrieved is the one active when locals() instead of the one inside locals() body.

Macro expansion of locals() and super() allows to get rid of stk, but it is quite difficult to get them right, see for example https://github.com/brownplt/lambda-py/issues/27

2013/3/15 Joe Politz notifications@github.com

I remember that Alejandro did some work with the stk parameter to the interpreter to handle locals, but I'm afraid I'm not sure if I ever understood it fully.

Alejandro.

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/50#issuecomment-14973939 .

[jpolitz]

I think having it be a piece of the interpreter is probably the right thing for now. I keep wanting it to be desugar-able, but it might just be that it's more complicated to have it out of the core than in it...

On Fri, Mar 15, 2013 at 1:38 PM, xlnagla notifications@github.com wrote:

I see how that might be complicated - it looks like if we want to make this a macro we'd have to trace locals through assignments and arguments in the entire program.

So it depends how much we need to get it exactly right. We could easily handle the less-complicated cases of this analysis in code right now, put the rest under "future work," and make locals() and globals() purely desugaring constructs. We already have decreed to not support assigning into locals() or globals(), so our implementation of these functions is already stunted.

If we're unwilling to do this, given our time frame it looks like stk needs to stay.

So what'll it be, folks? A macro that works in the majority of cases, or a complicated piece of the interpreter?

~matthew

On Fri, Mar 15, 2013 at 1:26 PM, Alejandro Martinez < notifications@github.com> wrote:

The use of stk allows locals() to be a function, instead of a macro as it was originally in base code: the local environment retrieved is the one active when locals() instead of the one inside locals() body.

Macro expansion of locals() and super() allows to get rid of stk, but it is quite difficult to get them right, see for example https://github.com/brownplt/lambda-py/issues/27

2013/3/15 Joe Politz notifications@github.com

I remember that Alejandro did some work with the stk parameter to the interpreter to handle locals, but I'm afraid I'm not sure if I ever understood it fully.

Alejandro.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/50#issuecomment-14973939> .

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/50#issuecomment-14974598 .

[jpolitz]

So just to be clear, we'd need to desugar every application of a (zero-argument?) function to:

if f is locals: do fancy locals stuff else: f(arg, ...)

In order to handle cases like:

def f(g): x = "my sooper seekret value" return g()

f(locals)

On Fri, Mar 15, 2013 at 3:57 PM, Joe Gibbs Politz joe@cs.brown.edu wrote:

I think having it be a piece of the interpreter is probably the right thing for now. I keep wanting it to be desugar-able, but it might just be that it's more complicated to have it out of the core than in it...

On Fri, Mar 15, 2013 at 1:38 PM, xlnagla notifications@github.com wrote:

I see how that might be complicated - it looks like if we want to make this a macro we'd have to trace locals through assignments and arguments in the entire program.

So it depends how much we need to get it exactly right. We could easily handle the less-complicated cases of this analysis in code right now, put the rest under "future work," and make locals() and globals() purely desugaring constructs. We already have decreed to not support assigning into locals() or globals(), so our implementation of these functions is already stunted.

If we're unwilling to do this, given our time frame it looks like stk needs to stay.

So what'll it be, folks? A macro that works in the majority of cases, or a complicated piece of the interpreter?

~matthew

On Fri, Mar 15, 2013 at 1:26 PM, Alejandro Martinez < notifications@github.com> wrote:

The use of stk allows locals() to be a function, instead of a macro as it was originally in base code: the local environment retrieved is the one active when locals() instead of the one inside locals() body.

Macro expansion of locals() and super() allows to get rid of stk, but it is quite difficult to get them right, see for example https://github.com/brownplt/lambda-py/issues/27

2013/3/15 Joe Politz notifications@github.com

I remember that Alejandro did some work with the stk parameter to the interpreter to handle locals, but I'm afraid I'm not sure if I ever understood it fully.

Alejandro.

— Reply to this email directly or view it on GitHub< https://github.com/brownplt/lambda-py/issues/50#issuecomment-14973939> .

— Reply to this email directly or view it on GitHubhttps://github.com/brownplt/lambda-py/issues/50#issuecomment-14974598 .

[mpmilano]

We discussed this further, and have implemented a version of locals.