4 ms·

The cursors were long before we were thinking explicitly of spreadsheets. Our model now has no encapsulating scope, which is just like access to some global obj

by ibdknox 12y ago

The cursors were long before we were thinking explicitly of spreadsheets. Our model now has no encapsulating scope, which is just like access to some global object like you're suggesting here.

seanmcdirmid 12y ago
Why not full on adopt dynamic scoping? This is what McCarthy did in the original LISP (some say it was an accident, but it has lots of advantages compared to lexical scoping). Global scope, in contrast, is like having no scope at all. There is also nothing really wrong with this if you can manage your namespace separately Subtext style, but the use cases are still different from dynamic scoping.
- jamii 12y ago
  > if you can manage your namespace separately Subtext style We do > the use cases are still different from dynamic scoping. What are the use cases? We so far haven't felt the need for any kind of scoping (although we admittedly have only written a few 'real' programs). It's not clear what dynamic scope would even really mean in Eve - there is no control-flow stack to set the scope and no notion of computer-time to dictate when a nested scope exists. A better analog might be ML functors. We could take a chunk of Eve code and parametrise it by the input/output tables. Then you could wire it into your dataflow graph in multiple places.
  - seanmcdirmid 12y ago
    LISP being technically based on the lambda calculus doesn't have any control flow either, but it does have hierarchy defined by callee/caller relationships. If you have any kind of hierarchy at all in your program execution (even if its just rules being used to for other rules...), you can leverage that as a "scope." Dynamic scoping is useful when you want to configure different executions with different behaviors without invasively passing down contexts to do that. There is a whole body of work on context-oriented programming which essentially leverages dynamic scoping to make code execution more adaptive without sacrificing viscosity.
    - ericHosick 12y ago
      > but it does have hierarchy defined by callee/caller relationships. If you have any kind of hierarchy at all in your program execution (even if its just rules being used to for other rules...), you can leverage that as a "scope." This is so true. You can take advantage of having access to a "parent" to change context. It allows you to re-use your code by just accessing information from your parent. It does lead to some coupling (it limits what types of parents you can have) but it does let you re-use code. And hay Sean!
    - jamii 12y ago
      > when you want to configure different executions with different behaviors without invasively passing down contexts That is certainly something we want, but I don't know if scoping is definitely the right way to do it, especially since both our code and data are entirely flat at the moment. We will likely have some kind of tagging of tables/rules for organisation and those tags could be the unit of reuse. The mechanism I have in mind feels more like copy-and-paste (I want that chunk of code but with these changes) or ML functors than it does dynamic scoping. In particular, the ability to change the dataflow graph at runtime without recompilation prevents lots of important optimisations.
      - seanmcdirmid 12y ago
        With ML functors, however, you are duplicating the code and managing separately; you could already do that for each scope (what I basically do in Glitch), or better yet, try and optimize duplication away (copy your data flow graph, but memoize and try to reuse). Anyways, the right path to take will probably become apparent as you do more development...keeping it simple at first is a good idea.
        jamii 12y ago
        > try and optimize duplication away (copy your data flow graph, but memoize and try to reuse) We sort of do that by hand at the moment. Rather than parametrise code, we attach ids to the data that is pushed through it. For example, instead of having a reusable 'compile' function we have a dataflow that just compiles anything thats added to the code tables and anything that wants to compile pushes code in one end and looks for the matching id coming out the other end. I'm not sure how far that will take us. It's certainly annoying when what you want is more like a function with a return value rather than a side effect. Still, we might be able to address that with a little sugar. We'll see.

by ibdknox 12y ago

The cursors were long before we were thinking explicitly of spreadsheets. Our model now has no encapsulating scope, which is just like access to some global object like you're suggesting here.

seanmcdirmid 12y ago

Why not full on adopt dynamic scoping? This is what McCarthy did in the original LISP (some say it was an accident, but it has lots of advantages compared to lexical scoping). Global scope, in contrast, is like having no scope at all. There is also nothing really wrong with this if you can manage your namespace separately Subtext style, but the use cases are still different from dynamic scoping.

jamii 12y ago
> if you can manage your namespace separately Subtext style We do > the use cases are still different from dynamic scoping. What are the use cases? We so far haven't felt the need for any kind of scoping (although we admittedly have only written a few 'real' programs). It's not clear what dynamic scope would even really mean in Eve - there is no control-flow stack to set the scope and no notion of computer-time to dictate when a nested scope exists. A better analog might be ML functors. We could take a chunk of Eve code and parametrise it by the input/output tables. Then you could wire it into your dataflow graph in multiple places.
- seanmcdirmid 12y ago
  LISP being technically based on the lambda calculus doesn't have any control flow either, but it does have hierarchy defined by callee/caller relationships. If you have any kind of hierarchy at all in your program execution (even if its just rules being used to for other rules...), you can leverage that as a "scope." Dynamic scoping is useful when you want to configure different executions with different behaviors without invasively passing down contexts to do that. There is a whole body of work on context-oriented programming which essentially leverages dynamic scoping to make code execution more adaptive without sacrificing viscosity.
  - ericHosick 12y ago
    > but it does have hierarchy defined by callee/caller relationships. If you have any kind of hierarchy at all in your program execution (even if its just rules being used to for other rules...), you can leverage that as a "scope." This is so true. You can take advantage of having access to a "parent" to change context. It allows you to re-use your code by just accessing information from your parent. It does lead to some coupling (it limits what types of parents you can have) but it does let you re-use code. And hay Sean!
  - jamii 12y ago
    > when you want to configure different executions with different behaviors without invasively passing down contexts That is certainly something we want, but I don't know if scoping is definitely the right way to do it, especially since both our code and data are entirely flat at the moment. We will likely have some kind of tagging of tables/rules for organisation and those tags could be the unit of reuse. The mechanism I have in mind feels more like copy-and-paste (I want that chunk of code but with these changes) or ML functors than it does dynamic scoping. In particular, the ability to change the dataflow graph at runtime without recompilation prevents lots of important optimisations.
    - seanmcdirmid 12y ago
      With ML functors, however, you are duplicating the code and managing separately; you could already do that for each scope (what I basically do in Glitch), or better yet, try and optimize duplication away (copy your data flow graph, but memoize and try to reuse). Anyways, the right path to take will probably become apparent as you do more development...keeping it simple at first is a good idea.
      - jamii 12y ago
        > try and optimize duplication away (copy your data flow graph, but memoize and try to reuse) We sort of do that by hand at the moment. Rather than parametrise code, we attach ids to the data that is pushed through it. For example, instead of having a reusable 'compile' function we have a dataflow that just compiles anything thats added to the code tables and anything that wants to compile pushes code in one end and looks for the matching id coming out the other end. I'm not sure how far that will take us. It's certainly annoying when what you want is more like a function with a return value rather than a side effect. Still, we might be able to address that with a little sugar. We'll see.