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

current object / dynamic scope #237

Closed
dobkeratops opened this issue May 28, 2016 · 5 comments
Closed

current object / dynamic scope #237

dobkeratops opened this issue May 28, 2016 · 5 comments

Comments

@dobkeratops
Copy link

The 'current object' feature is interesting, I think it's the same as (or similar to) 'dynamic scope'?
https://en.wikipedia.org/wiki/Scope_(computer_science)#Dynamic_scoping

In lisp I think they have 'defvar ' for this;

are there any differences, would you change the way you describe it?

I think it's uncommon in modern languages because the shadowing is less predictable (its also hard to do efficiently), but having 'lexical scope' as the default and something else to make something dynamically scoped seems like the best of both worlds.

The other suggestion I was going to make was to use a different syntax for it, because I remember the ~foo pointers rust used to have (not sure what though. maybe some keyword infront)

@bvssvni
Copy link
Member

bvssvni commented May 28, 2016

The syntax was an idea:

"~" looks like a wave
wave => stream => current

It has been a while since Rust used this syntax, so I don't think most people know about it.

@bvssvni
Copy link
Member

bvssvni commented May 28, 2016

The current implementation uses a separate stack for current objects, an association list. When an object becomes a current object, or put into dynamic scope, it is pushed to the stack, and removed when the object runs out of scope.

I wonder whether pushing it to the stack from the current stack when entering the function would be more efficient. Could put it after the arguments, in the order used by function declaration. This way one doesn't have to look through the current stack on each reference. Could it be used with statically resolving, by pointing directly to that reference on the stack just like a function argument.

That brings another idea about the semantics:

  • The dynamic scope is hidden by default, all the interactions with it are explicit
  • When declaring a current object, you are introducing the variable into the hidden dynamic scope
  • When using a current object, you are moving the variable from hidden dynamic scope to lexical scope

Right now it happens to be put in a dynamic scope with a higher precedence on lexical scope, but this is equivalent with a hidden dynamic scope since the lifetime checker prevents you from running the program unless the reference is resolved.

Wow! A lightbulb moment here.

@dobkeratops
Copy link
Author

dobkeratops commented May 28, 2016

"The dynamic scope is hidden by default, all the interactions with it are explicit" ...I guess that makes the ~ syntax useful , i.e it easy enough to write.

The lisp docs say they usually use 'varname' convention , i.e. they like it looking different (i'm not suggesting you copy that specific syntax, it wont fit in an infix language of course)

would a unary '.' work? like an anonymous object being silently passed down the calligraphy "self.foo = blah blah" ".foo = blah blah" (would that parse ok?)

@bvssvni
Copy link
Member

bvssvni commented May 28, 2016

Could try changing ~ to . in the parsing rules and see if it works. I guess it will have some problems with objects.

@bvssvni
Copy link
Member

bvssvni commented Sep 19, 2016

I'll try the ~ for now. Closing.

@bvssvni bvssvni closed this as completed Sep 19, 2016
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

2 participants