Yes, the graph is equivalent to an s-expr (with subgraphs being nested scopes).
The reason that I’m not just representing the graph as a single expression is for efficiency – I’m doing incremental updates and change tracking, so you can update one of the node's expressions and have the changes propagate through the graph with a minimum number of re-evaluations. A similar Python engine is documented here: http://www.mattkeeter.com/projects/graph/ Regards, Matt On Jun 11, 2016, at 11:15 AM, Basa Centro <basa.cen...@gmail.com> wrote: > It seems in essence you are building up a Scheme expression using the > graph and the code snippets and evaluating that expression. If this > is the case, do you even need to use a module system and/or to > explicitly create environments? Prima facie, it looks like you are > trying to reinvent the wheel. Is your graph really just equivalent to > an S-exp? > > Scheme is lexically scoped, and creates a "transient environment" for > you through the use of lambdas. > > Your use of thunks suggests that you are doing caching or lazy-eval. > > I'm not sure this helps, but I hope so. When thinking about this > topic, I had this mental image of a GUI for building Scheme > expressions--like "Visual Scheme". :) > > (Basa) > > On 6/10/16, Matthew Keeter <matt.j.kee...@gmail.com> wrote: >> The specific use case is for dataflow graphs, where you’re evaluating a >> bunch of small >> snippets of code that can refer to each other by name. >> >> I’d like to make an environment in which the variables in the same subgraph >> are >> exposed as no-argument thunks. >> >> For example, let’s say I have one subgraph that contains >> a = “12” => evaluates to 12 >> b = “(+ 1 (a))” => evaluates to 13, since the (a) thunk evaluates to 12 >> >> and another subgraph which contains >> x = “1” => evaluates to 1 >> y = “(* (x) 2)” => evaluates to 2 >> >> If I insert the thunks into (scheme-report-environment 5), they leak from >> one graph >> to another – and to be fair, the docs to say that assigning into this >> environment is >> undefined behavior. >> >> However, if I make an empty environment with (null-environment), it doesn’t >> have >> useful functions like + and *; looks like (make-module) has the same issue. >> >> I'm sure that this is possible in Guile, but I got tired of reading through >> the source >> files to hunt down undocumented function that do what I need [1]. >> >> -Matt >> >> [1] Another recent incident: How do you programmatically list all of the >> variables in a module? >> You search the web, find http://www.draketo.de/proj/guile-basics/#sec-3-2, >> see a a reference to >> module-map, which doesn’t exist in the documentation, dig it up in the >> source to see its >> arguments, etc… >> >> On Jun 10, 2016, at 6:11 PM, Basa Centro <basa.cen...@gmail.com> wrote: >> >>>> First of all: is the "sandboxing" aspect of these environment important? >>> >>> Taylan, >>> >>> Thanks, that's exactly what I meant by "motivation" in my first reply. >>> (There was a recent, 6 months ago or so, thread on sandboxing in >>> guile-user by the way.) >>> >>> Was Matt trying to prevent _access_ (inaccessible vs. read-only vs. >>> read/write) to data? Or was he trying to prevent only _visibility_ >>> (e.g. for hygeine)? >>> >>> I think we need to know more about "what" and "why" to answer his >>> question, rather than just "how"--if that makes any sense. Does >>> Racket [1] even _really_ achieve what he needs to do (_prevent_ access >>> for example)? We don't even know if we don't understand the >>> higher-level purpose. >>> >>> (Basa) >>> >>> [1] Disclaimer: I like Racket too--it is a great project. I just hate >>> to see someone leave Guile because of a minor technicality. >> >>