Search fails - why?

[Joseph]

Here is the first block that binds hello world to browser:

bind @browser

  [tag: "div", text: "Hello, world"]

  

I copied and pasted the commit and search for name with value Celia to the same block.

  

commit

  [name: "Celia"]

  

search

  [name] 

I re-run the block and "Hello, world" is still being displayed.

Now I replace the word "name" by "first-name", like so:

commit

  [first-name: "Celia"]

  

search

  [first-name] 

and re-run the block.

Now "Hello, world" disappears, implying that the search this time failed. Why?

[Joseph]

After playing around with the code a little, it appears that the reason the search failed in my previous example is,

that the search in the block is performed before the commit in the same block, 

even if the commit precedes the search. 

Since the search was already performed before the commit, 

therefore the search could not locate the searched tag and failed, 

and because the search failed, 

therefore the commit was never performed.

However, if a different block, even if it occurs later, contains a commit using the same tag, 

then the commit in that block succeeds (because in that block there is no search whose failure could prevent the commit), and 

consequently the search in the first block succeeds, 

and then the commit in that same first block as the search, now also succeeds, 

and then the search succeeds a second time, this time with respect to the value committed in its own block.

Is that a bug, or is it really the way it's supposed to work?

[co...@kodowa.com]

Joseph,

Do you mean you have written a block that looks like this?

```

bind @browser
  [tag: "div", text: "Hello, world"]

commit
  [name: "Celia"]
  
search
  [name] 

```

If that's the case, then the reason you saw "hello world" the first time is that there is probably already a record with a "name" attribute in the DB, so the block succeeds and prints the message. When you instead search for [first-name], there is no record matching that pattern, so the block fails to execute and "Hello world" isn't displayed anymore. When you add a record matching that pattern, then the search will again match a record, and the message will display again.

One thing to also note is that ach block is treated as a whole, so if you have two searches, both must pass for it to do anything. If you want them to be independent, they have to be in different blocks.

I made a little example to try to show this better. Go through and check each block active in turn, reloading the program after you activate each block.

http://play.witheve.com/#gist:f320b3cee21195f3742922cc5c0f8b1b-examples-untitled.eve

> is it really the way it's supposed to work?

With Eve, you usually don’t have to take an execution-focused view of how your program works. Things like the order of statements or the order of blocks don’t matter at all. Instead, here are 3 I keep in mind when writing blocks:

1. Blocks compose automatically - If you have two block in two parts of your program that affect the "name" attribute, the final value will be the composition of those two blocks
2. Blocks re-run every time their search records change - If a block searches for the same records it creates, this could potentially lead to an infinite loop.
3. Blocks are global - Every block can affect any other block.

These properties make it more natural to think of Eve from the perspective of the data that exists, as opposed to the execution of the blocks themselves. Instead of tracing the execution of code when writing an Eve program, you instead think about the presence or absence of records. Writing blocks is a very local task -- you define the condition under which the block runs, and then define how records are modified under that condition. "When I see this, do that". 

I hope that helps

Corey

On Sunday, May 21, 2017 at 7:13:50 PM UTC-7, Joseph wrote:

[Joseph]

Thanks.

That confirms what I concluded from the behavior that I observed.

Would it make sense to introduce a rule, whereby Eve performs all commits in a block, before any searches are performed in the same block? 

On Sunday, May 21, 2017 at 7:13:50 PM UTC-7, Joseph wrote:

[Josh Cole]

You can think of an Eve block as a function that runs each time its inputs change. If patterns in your search don't match, the function will bail out early. Commit and bind are like the function's return statement -- so if nothing matches, nothing will be returned. If you want to create something as the input to a block, you'll need to create it elsewhere.

Here's an example that'll accomplish your goal. It uses two blocks -- one to create the input for the other.

Create someone with a first name. With no search in the block, the commit will happen automatically.

```

commit

  [first-name: "Celia"]

```

Greet people with first names. The output here will only be produced if the search pattern is met.

```

search

  [first-name] 

bind @browser

  [tag: "div", text: "Hello, {{first-name}}"]
```

The reason why the original block wouldn't work is because something must initially exist that has a name. Once it does, the block would recursively match its own result, but it couldn't get there until something else matched its pattern.

[Joseph]

I like your comparison to a function's return value. Puts it well in perspective.

Thanks.