4 ms·

>Passing cursors quickly became tedious when trying to change code. If a function suddenly needed access to IO the cursor had to be passed down through every fu

>Passing cursors quickly became tedious when trying to change code. If a function suddenly needed access to IO the cursor had to be passed down through every function above it in the callstack. This is the function-calling train issue and what happens if you try to make a sort of quasi homoiconic language ("Hierarchical organisation of data complects the data itself with the common access paths.") and attempt a push-pull approach to programming (you push the data down into the hierarchy) with traditional data scoping through parameters. The bad is not the hierarchical organization of data. That is the correct direction. The bad is trying to use a traditional scoping approach to what is effectively a homoiconic type language. Homoiconic type systems need a different scoping approach.

DennisP 12y ago
So how should it be done?
- seanmcdirmid 12y ago
  Dynamic scoping?
- seabee 12y ago
  In my favourite homoiconic language, Racket (also in lisps, so it's surprising that OP didn't mention it) you'd typically accomplish it with parameterised dynamic binding. Think global variables, except the lifetime of the new value is limited to a body of code. A concrete example is a function that writes something to stdout. If you want to output to a file instead, parameterise the function call by setting current-output-port to the handle of your file.
- ericHosick 12y ago
  The way we do scoping now is to rely on the programming language which is basically the stack. But we can implement our own scoping mechanisms based on the domain we are developing a program in. For example, Eve mentioned that they were looking at a sort of "Excel" spreadsheet type visual language. The scoping mechanism of spreadsheets are a sheet with row/column. So, I would create objects that are able to quickly pull from a row/column and push into a row/column. For example, somewhere in their hierarchy they had an algorithm that required access to a cursor. Since it is a spreadsheet we can have our global active spreadsheet which, somewhere, contains the cursor. We know it is there because we put it there. Somewhere deep in the bowels of the data hierarchy we have this line of code to get a cursor: var cursorCurrent = global.curSpread[34,65]; because our scoping mechanism is based on an excel spreadsheet and not the one "forced" on us by the programming language: usually a stack. There is no need to push that current cursor down the function calling train and, in the end, it is probably faster because we are doing a simple cell lookup.
  - 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.
chipsy 12y ago
Why is hierarchical organization correct?
- ericHosick 12y ago
  They are going for a visual language, and visual languages are inherently hierarchal. The goal is to easily represent context of any part of a program in a visual way. Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent. Trying to represent the stack in a visual way makes for a icky looking visual language. However, if you can keep all of the context/state of your program in one area and it is hierarchal... Then, you can build great visual representations of your program because, really, you are displaying a data-structure (your program becomes a data-structure). So, all the cool things you can do visually representing data-structures, you can do with your actual program.
  - jamii 12y ago
    > They are going for a visual language 'Visual language' is a very overloaded term and we are in no way set on any particular ideology. Textual languages and visual layout have different strengths and weaknesses and there are lots of cases where it makes sense to mix both. There is plenty of evidence that both are useful (eg http://www.amazon.com/Small-Matter-Programming-Perspectives-Computing/dp/0262140535/ http://www.amazon.com/Small-Matter-Programming-Perspectives-...). My only aversion to text is as an unstructured storage and communication format - it makes much more sense to allow tools to communicate using a shared, versioned and structured database rather than watching for changes in text files. > visual languages are inherently hierarchal Excel - https://www.google.com/search?q=excel&client=ubuntu&hs=fRx&channel=fs&source=lnms&tbm=isch&sa=X&ei=rmVAVNyJFoKMoQTS5ID4Ag&ved=0CAgQ_AUoAQ https://www.google.com/search?q=excel&client=ubuntu&hs=fRx&c... Access - https://www.google.com/search?q=access&client=ubuntu&hs=Jnc&channel=fs&source=lnms&tbm=isch&sa=X&ei=6WVAVILxN9CZoQTn14DABA&ved=0CAgQ_AUoAQ&biw=628&bih=1051 https://www.google.com/search?q=access&client=ubuntu&hs=Jnc&... Labview - https://www.google.com/search?q=labview&client=ubuntu&hs=v5H&channel=fs&source=lnms&tbm=isch&sa=X&ei=aGVAVL23FoKrogS4oYE4&ved=0CAgQ_AUoAQ&biw=628&bih=1051 https://www.google.com/search?q=labview&client=ubuntu&hs=v5H... Blender - https://www.google.com/search?q=blender+node+editor&client=ubuntu&hs=TRx&channel=fs&source=lnms&tbm=isch&sa=X&ei=omVAVMnKFIjwoATN-IDYBg&ved=0CAkQ_AUoAg&biw=628&bih=1051 https://www.google.com/search?q=blender+node+editor&client=u... PureData - https://www.google.com/search?q=puredata&client=ubuntu&hs=4Sx&channel=fs&source=lnms&tbm=isch&sa=X&ei=BWZAVLqgJ4KRoQS81ILYCA&ved=0CAkQ_AUoAg&biw=628&bih=1051 https://www.google.com/search?q=puredata&client=ubuntu&hs=4S... TouchDevelop - https://www.google.com/search?q=touchdevelop&client=ubuntu&hs=Toc&channel=fs&source=lnms&tbm=isch&sa=X&ei=MWZAVL7sEMasogSn9oLQDw&ved=0CAoQ_AUoAw&biw=628&bih=1051 https://www.google.com/search?q=touchdevelop&client=ubuntu&h... Kodu - https://www.google.com/search?q=kodu&client=ubuntu&hs=N9H&channel=fs&source=lnms&tbm=isch&sa=X&ei=PmZAVLPYFoT3oASf2IH4CQ&ved=0CAgQ_AUoAQ&biw=628&bih=1051#channel=fs&tbm=isch&q=kodu+program https://www.google.com/search?q=kodu&client=ubuntu&hs=N9H&ch... Pretty much the only hierarchical example that comes to mind is Scratch. > Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent. Yes. But non-local scope and control flow are also pretty hard to represent and understand. That's why we ended up avoiding both. > However, if you can keep all of the context/state of your program in one area and it is hierarchal... It doesn't have to be hierarchical. Excel and Access both have amazing (by programming tool standards) visual representations of your program and your data. > So, all the cool things you can do visually representing data-structures, you can do with your actual program. Data and code are different though. Eve is homoiconic-ish (code is stored in tables) but the actual visualisations and manipulations applied in 99% of the use cases are very different. We don't spend nearly as much time manipulating code as data compared to reading, writing and understanding code so it makes sense to default to visualisations that optimise for the latter.
jamii 12y ago
> The bad is not the hierarchical organization of data. That is the correct direction. This is just a repeat of the xml database vs relational database debate. This fight has been fought so many times before - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113.5640 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113....
- ericHosick 12y ago
  The context of the discussion is the representation of state within an executing program. Xml database, key-value-store, relational databases, csv files, etc. are all ways of persisting. These are very different disciplines with very different problems being solved.
  - jamii 12y ago
    That distinction is a historical accident. You can page a program heap to disk and you can run a relational database entirely in-memory (this is one of the common use cases for sqlite). True, databases and programming languages are usually optimised for different use cases but that says more about the particular implementation and the way we think about using them then it does about the data models. The question in both cases is how should we model, query and update our data. The original tradeoff was that hierarchical databases and network databases were faster but relational databases were more flexible and maintainable (due to the separation of logical and physical data representation). Better implementations (eg http://en.wikipedia.org/wiki/IBM_System_R http://en.wikipedia.org/wiki/IBM_System_R) narrowed the divide and made relational databases more attractive. Systems like Bloom (http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/) and LogicBlox (http://www.infoq.com/presentations/wavefront http://www.infoq.com/presentations/wavefront) show that the same tipping point could be reached for programming languages.
    - ericHosick 12y ago
      Ok, I see what you are saying now. I really agree that there is no difference really between programs and databases. It really is "how should we model, query and update our data." So, ya, the question is "How do you pass information between sub-routines". Databases aren't expected to do much data manipulation between sub-routines. Programs are just wow so many ways to do it. Thank you for taking the time to have this discussion.

DennisP 12y ago

So how should it be done?

seanmcdirmid 12y ago
Dynamic scoping?
seabee 12y ago
In my favourite homoiconic language, Racket (also in lisps, so it's surprising that OP didn't mention it) you'd typically accomplish it with parameterised dynamic binding. Think global variables, except the lifetime of the new value is limited to a body of code. A concrete example is a function that writes something to stdout. If you want to output to a file instead, parameterise the function call by setting current-output-port to the handle of your file.
ericHosick 12y ago
The way we do scoping now is to rely on the programming language which is basically the stack. But we can implement our own scoping mechanisms based on the domain we are developing a program in. For example, Eve mentioned that they were looking at a sort of "Excel" spreadsheet type visual language. The scoping mechanism of spreadsheets are a sheet with row/column. So, I would create objects that are able to quickly pull from a row/column and push into a row/column. For example, somewhere in their hierarchy they had an algorithm that required access to a cursor. Since it is a spreadsheet we can have our global active spreadsheet which, somewhere, contains the cursor. We know it is there because we put it there. Somewhere deep in the bowels of the data hierarchy we have this line of code to get a cursor: var cursorCurrent = global.curSpread[34,65]; because our scoping mechanism is based on an excel spreadsheet and not the one "forced" on us by the programming language: usually a stack. There is no need to push that current cursor down the function calling train and, in the end, it is probably faster because we are doing a simple cell lookup.
- 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.

chipsy 12y ago

Why is hierarchical organization correct?

ericHosick 12y ago
They are going for a visual language, and visual languages are inherently hierarchal. The goal is to easily represent context of any part of a program in a visual way. Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent. Trying to represent the stack in a visual way makes for a icky looking visual language. However, if you can keep all of the context/state of your program in one area and it is hierarchal... Then, you can build great visual representations of your program because, really, you are displaying a data-structure (your program becomes a data-structure). So, all the cool things you can do visually representing data-structures, you can do with your actual program.
- jamii 12y ago
  > They are going for a visual language 'Visual language' is a very overloaded term and we are in no way set on any particular ideology. Textual languages and visual layout have different strengths and weaknesses and there are lots of cases where it makes sense to mix both. There is plenty of evidence that both are useful (eg http://www.amazon.com/Small-Matter-Programming-Perspectives-Computing/dp/0262140535/ http://www.amazon.com/Small-Matter-Programming-Perspectives-...). My only aversion to text is as an unstructured storage and communication format - it makes much more sense to allow tools to communicate using a shared, versioned and structured database rather than watching for changes in text files. > visual languages are inherently hierarchal Excel - https://www.google.com/search?q=excel&client=ubuntu&hs=fRx&channel=fs&source=lnms&tbm=isch&sa=X&ei=rmVAVNyJFoKMoQTS5ID4Ag&ved=0CAgQ_AUoAQ https://www.google.com/search?q=excel&client=ubuntu&hs=fRx&c... Access - https://www.google.com/search?q=access&client=ubuntu&hs=Jnc&channel=fs&source=lnms&tbm=isch&sa=X&ei=6WVAVILxN9CZoQTn14DABA&ved=0CAgQ_AUoAQ&biw=628&bih=1051 https://www.google.com/search?q=access&client=ubuntu&hs=Jnc&... Labview - https://www.google.com/search?q=labview&client=ubuntu&hs=v5H&channel=fs&source=lnms&tbm=isch&sa=X&ei=aGVAVL23FoKrogS4oYE4&ved=0CAgQ_AUoAQ&biw=628&bih=1051 https://www.google.com/search?q=labview&client=ubuntu&hs=v5H... Blender - https://www.google.com/search?q=blender+node+editor&client=ubuntu&hs=TRx&channel=fs&source=lnms&tbm=isch&sa=X&ei=omVAVMnKFIjwoATN-IDYBg&ved=0CAkQ_AUoAg&biw=628&bih=1051 https://www.google.com/search?q=blender+node+editor&client=u... PureData - https://www.google.com/search?q=puredata&client=ubuntu&hs=4Sx&channel=fs&source=lnms&tbm=isch&sa=X&ei=BWZAVLqgJ4KRoQS81ILYCA&ved=0CAkQ_AUoAg&biw=628&bih=1051 https://www.google.com/search?q=puredata&client=ubuntu&hs=4S... TouchDevelop - https://www.google.com/search?q=touchdevelop&client=ubuntu&hs=Toc&channel=fs&source=lnms&tbm=isch&sa=X&ei=MWZAVL7sEMasogSn9oLQDw&ved=0CAoQ_AUoAw&biw=628&bih=1051 https://www.google.com/search?q=touchdevelop&client=ubuntu&h... Kodu - https://www.google.com/search?q=kodu&client=ubuntu&hs=N9H&channel=fs&source=lnms&tbm=isch&sa=X&ei=PmZAVLPYFoT3oASf2IH4CQ&ved=0CAgQ_AUoAQ&biw=628&bih=1051#channel=fs&tbm=isch&q=kodu+program https://www.google.com/search?q=kodu&client=ubuntu&hs=N9H&ch... Pretty much the only hierarchical example that comes to mind is Scratch. > Trying to map source-code that stores a lot of it's context on the stack is really hard to visually represent. Yes. But non-local scope and control flow are also pretty hard to represent and understand. That's why we ended up avoiding both. > However, if you can keep all of the context/state of your program in one area and it is hierarchal... It doesn't have to be hierarchical. Excel and Access both have amazing (by programming tool standards) visual representations of your program and your data. > So, all the cool things you can do visually representing data-structures, you can do with your actual program. Data and code are different though. Eve is homoiconic-ish (code is stored in tables) but the actual visualisations and manipulations applied in 99% of the use cases are very different. We don't spend nearly as much time manipulating code as data compared to reading, writing and understanding code so it makes sense to default to visualisations that optimise for the latter.

jamii 12y ago

> The bad is not the hierarchical organization of data. That is the correct direction. This is just a repeat of the xml database vs relational database debate. This fight has been fought so many times before - http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113.5640 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.113....

ericHosick 12y ago
The context of the discussion is the representation of state within an executing program. Xml database, key-value-store, relational databases, csv files, etc. are all ways of persisting. These are very different disciplines with very different problems being solved.
- jamii 12y ago
  That distinction is a historical accident. You can page a program heap to disk and you can run a relational database entirely in-memory (this is one of the common use cases for sqlite). True, databases and programming languages are usually optimised for different use cases but that says more about the particular implementation and the way we think about using them then it does about the data models. The question in both cases is how should we model, query and update our data. The original tradeoff was that hierarchical databases and network databases were faster but relational databases were more flexible and maintainable (due to the separation of logical and physical data representation). Better implementations (eg http://en.wikipedia.org/wiki/IBM_System_R http://en.wikipedia.org/wiki/IBM_System_R) narrowed the divide and made relational databases more attractive. Systems like Bloom (http://boom.cs.berkeley.edu/ http://boom.cs.berkeley.edu/) and LogicBlox (http://www.infoq.com/presentations/wavefront http://www.infoq.com/presentations/wavefront) show that the same tipping point could be reached for programming languages.
  - ericHosick 12y ago
    Ok, I see what you are saying now. I really agree that there is no difference really between programs and databases. It really is "how should we model, query and update our data." So, ya, the question is "How do you pass information between sub-routines". Databases aren't expected to do much data manipulation between sub-routines. Programs are just wow so many ways to do it. Thank you for taking the time to have this discussion.