Eve Syntax Changes

[co...@kodowa.com]

Hi all,

We're taking the steps to put the Eve syntax in the v0.3 runtime, so we thought now would be a good time to see if anyone had suggestions for changes they'd like to see.

One big change so far that follows from the semantics is that @ is no longer and operator, since databases are no longer a thing.

Are there any other changes you might suggest?

Thanks,

Corey

[Owen Williams]

I’m still in favor of using “<“ and “>” instead of square brackets to indicate things in the former “browser” domain — eg: things that map to HTML elements.

In essence, clearly this separates “invisible” elements (which use “[]”) from “output” elements (which use “<>”).

This is especially true as it sounds like “@browser” is going away, meaning that there’s no explicit way to specify that you want to match/manipulate HTML elements as opposed to “invisible” records in the database.

1) With the new database-less syntax, how will I indicate that something should translate to an “external” HTML element?

- e.g with this:

commit

[#div title=“Foo”]

- Does the fact that there is a “div” tag there mean that I’m going to get an HTML element, because `div` is somehow “blessed"?

- If so, this is inherently dangerous — there are a LOT of arbitrary HTML elements that people don’t know about, so I might think that this is just creating an “invisible” element with tag “section” if I don’t know that <section> is a thing:

commit

[#section title:”Foo”]

- and what if I do:

commit

[#div #section title=“Foo”]

??  What do we get as output?

- If, instead, we use < and > to denote HTML elements, we get the unambiguous semantics:

commit

<div title:“Foo”>

[section title:Foo]

<div #section title:“Foo”>

2) The overloading of “#“ to mean “one of an arbitrary set of tags” as well as “the html tag name which is used to match an element” feels inherently dangerous, especially given Eve’s lack of order.

- What does this mean to eve?

search

[#div #section name:”Hello”]

- Is that going to match an HTML <div> or an HTML <section>?  an “invisible” element with both tags?

- If I understand correctly, this is ambiguous and could return any of those three things, depending on what’s in your database at the moment.

- Whereas this very clearly means that I want you to match an HTML div:

search

<div #section name:”Hello”>

3) The use of <> to output elements can inherently signal to eve “order is important for the stuff in here.”

- having to add silly “order” properties to HTML output to force output order is a non-starter in my opinion.

4) As for “nesting elements”, I’d MUCH rather look at XML with its end tags for nesting rather than a dangling series of brackets:

[#div #container class: "container" children: 

 [#div class: "scroll" children: 

 [#div class: “banner” children:

 [#div class: "bio-info" children:

...

]

]

]

]

or worse

]]]]]

- Maybe I just haven’t spent enough time in LISP to like the 100’s of parentheses thing, but I find the above really tedious to read and work with.

- Yes, typing the end tags takes a little longer, but it’s easier to see what’s going on IMO.

- the implicit closing “>” in the <> specification also means you can ovoid the “children:” attribute in each of the elements above:

4) Note that I’m NOT saying that Eve needs to “parse XML” 

- naive users presumably don’t know XML semantics, so it is not a problem for them that your <> semantics are a little different.

- the rise of JSX in the React community shows that developers are quite comfortable with something that “feels kinda like HTML/XML but works a bit differently” as long as it’s consistent and convenient.

- I would, however, allow using “=“ as well as “:”, so

<div name=“Hello” tabIndex=1 >

would work just fine, so that:

5) In many cases, with the <> syntax, I may be able to copy and paste static HTML into an input or output block and then just decorate it with “variables”.

- This makes the round trip from a designer’s HTML, or from the “elements” drawer in the browser console, much, much, much faster.

thanks for asking

Owen

--
You received this message because you are subscribed to the Google Groups "Eve talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
To post to this group, send email to eve-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/fd31efba-7186-4ebf-b663-d25d91befcf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[thierry....@gmail.com]

What is the rationale for removing databases?
Writing data driven programs without databases will be hard to explain to newcomers.

[co...@kodowa.com]

@thierry

> What is the rationale for removing databases? Writing data driven programs without databases will be hard to explain to newcomers.

Databases seemed like a pretty intuitive and straightforward idea at the time, but we actually found it was one of the biggest sources of confusion for newcomers. The problem was you had to not only think about the presence of records, but the presence of records in specific places. Whatsmore, the concept of databases made records a leaky abstraction; when you dealt with records that spanned multiple databases, you had to consider the subset of the record that existed in one database versus another. This commonly cropped up with events, where the event itself was in @event, but the element attribute held a reference to a record in the @browser database, which in turn could possibly hold references to records in the @session DB.

Users faced problems of UI not being displayed because it wasn't in the @browser database. Another problem was when using multiple databases, it was difficult to keep track of what was where. This could have been solved with a database explorer, but it would still lead to code that looked like this:

```

search @browser @event @session

 [#click element: [#div children: [#foo]]]

```

It's not clear what is coming from where in that case. Databases will be replaced with explicit namespacing on tags (which we will probably call groups). Some benefits of this direction:

1 - you no longer have to worry about "where" a record is located. If you search for the right shape, you'll find the record.

2 - you can write special rules for groups in Eve itself instead of having to worry about custom "blessed" databases with opaque rules. If you want to know the rules associated with a group, you can just look them up, and even modify them yourself to get custom behavior.

3 - because of 2, this means a record gains the properties of the group simply by becoming a member of that group. This paves the way to things like permissions.

@owen

Thanks for taking the time to present your suggestions. Let me address some of your points, to let you know how we’re handling your concerns:

> With the new database-less syntax, how will I indicate that something should translate to an “external” HTML element?

Databases are being replaced with explicit namespacing. So instead of putting records in the `@browser` database, you'll put them in the "html" namespace. To render a div, you would write this

```

commit

 [#html/div text: “Foo”]

```

Which at the low level would look like this:

```

commit

 [#html/element tagname: "div" text: "Foo"]

```

Unfortunately this makes html records a little more verbose, but it also means we've removed a special case from the language and made it more uniform, so there's one less thing to explain/learn. So no, there are no "blessed" tags anymore, but there are namespaces that have special meaning. This also means that you can write special rules to confer this meaning in Eve itself. This wasn't possible before with databases.

> The overloading of “#“ to mean “one of an arbitrary set of tags” as well as “the html tag name which is used to match an element” feels inherently dangerous, especially given Eve’s lack of order.

As you can see in the example above, we don't give special meaning to tags in the case of the renderer anymore. The type of an elements is now explicitly called out in the record, so there isn't any confusion. Users have run into the problem you describe, so this will fix that issue.

> The use of <> to output elements can inherently signal to eve “order is important for the stuff in here.”

I definitely agree with you that having to do this is onerous. Writing UI is not one of the strengths of Eve at the moment. That said, instead of adding order in special cases, I think we have opportunities to lessen this pain in other areas. In general, our philosophy is keep the language small and uniform, and handle sharp edges with good tooling.

Since we're still very much in the language development phase, a dearth of tooling exposes our rough edges. I think if the text syntax were the end-point for our language, your angle bracket suggestion would work out pretty well. But wouldn't it be better to have a graphical UI builder, something like Sketch, that interfaces directly with Eve? We explored a prototype here (http://incidentalcomplexity.com/2015/07/02/mar-jun/) which worked pretty well given how rough it was, so we'd like to do something like this again in the future. This would allow us to sidestep the order issue in the language, and give us a tool that is better than both what we have now and keep the language small.

> Maybe I just haven’t spent enough time in LISP to like the 100’s of parentheses thing, but I find the above really tedious to read and work with.

I agree fully. I've never been a huge lisp user, and there's a reason most lisp tooling focuses on making parenthesis easier to work with. In the programs we've written, the proliferation of parens usually occurs only in UI, where elements tend to be deeply nested. In non-UI eve code, records end up being flatter, so this issue isn't as painful. That said, I think there are still some tooling solutions here for us as well (matching paren highlighting, auto closing parens, or even rainbow coloring parens)

> In many cases, with the <> syntax, I may be able to copy and paste static HTML into an input or output block and then just decorate it with “variables”.

This is a very good point, but I think again we might have a good tooling solution here. For example, in a UI specific editor there could be a way to import HTML, and then you can bind Eve records into the template you paste in. This would effectively turn static HTML into a live site backed by data pretty quickly.

Corey

[Jeff Bone]

Imho, having a top-level construct called "commit" w/o "a database" seems odd.

I've long thought "find/bind/save" would be better, or even "get/set/put."  Though that feels rather imperative and might be misleading.  But it seems to me that there's a strong kinship here w/ Linda and multiple tuple spaces and their small set of primitives.

--
You received this message because you are subscribed to the Google Groups "Eve talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
To post to this group, send email to eve-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/6c1488f1-c700-48ce-bf11-011e05cfb9a5%40googlegroups.com.

[nickgoo...@gmail.com]

To render a div, you would write this

```

commit

 [#html/div text: “Foo”]

```

I'm a product designer and front-end guy, so forgive me if I'm naive… but why not just pull the HTML out into another block like you do with CSS already? I've found the way vue.js organizes things to be really easy to understand. Vue uses single-file components, and separates the HTML, CSS, JAVASCRIPT(EVE?) to allow existing preprocessors to be used (pug, sass etc…). From my perspective EVE is awesome, but crippling the ability to organize and read HTML/CSS (and losing all the great existing tooling) makes building things a nightmare. 

EVE BLOCK

search

  [name]

bind

  element := #foo

HTML BLOCK

<div id=“foo” class=“bar”>Hello, {{name}}</div>

CSS BLOCK

.bar {

  font-family: “Awesome-sauce”

}

Also, Vue lets you define components as new HTML tags and use them declaratively in your markup, passing in props for data and sprinkling in function calls for handling interactions. This makes it easy to compose with and share your single-file components with others (<data-grid :data="gridData"><data-grid>). I'd love to see EVE start to get savvy about organizing apps and components. :)

[Ionuț G. Stan]

The thing is, that HTML snippet needs to react to some changes (appear
or disappear), so it needs to pattern match on data changes. HTML alone
doesn't have an ability to do that, whereas CSS already has a pattern
matching ability with its selectors. Also, blocks, in Eve, are treated
as separate units of computation. You can only link blocks my means of
data matching: `search` and CSS selectors.

That's my explanation anyway.

On 29/04/2017 08:40, nickgoo...@gmail.com wrote:
> *To render a div, you would write this*
>
> *
> *
>
> *```*
>
> *commit*
>
> * [#html/div text: “Foo”]*
>
> *```*

>
> I'm a product designer and front-end guy, so forgive me if I'm naive…
> but why not just pull the HTML out into another block like you do with
> CSS already? I've found the way vue.js organizes things to be really
> easy to understand. Vue uses single-file components, and separates the
> HTML, CSS, JAVASCRIPT(EVE?) to allow existing preprocessors to be used
> (pug, sass etc…). From my perspective EVE is awesome, but crippling the
> ability to organize and read HTML/CSS (and losing all the great existing
> tooling) makes building things a nightmare.
>

> *EVE BLOCK*

> search
> [name]
>
> bind
> element := #foo
>

> *HTML BLOCK*

> <div id=“foo” class=“bar”>Hello, {{name}}</div>
>

> *CSS BLOCK*

> .bar {
> font-family: “Awesome-sauce”
> }
>
> Also, Vue lets you define components as new HTML tags and use
> them declaratively in your markup, passing in props for data and
> sprinkling in function calls for handling interactions. This makes it
> easy to compose with and share your single-file components with others
> (<data-grid :data="gridData"><data-grid>). I'd love to see EVE start to
> get savvy about organizing apps and components. :)
>
> On Friday, April 28, 2017 at 2:15:25 PM UTC-7, co...@kodowa.com wrote:
>

> *

> <http://incidentalcomplexity.com/2015/07/02/mar-jun/>) which worked

> pretty well given how rough it was, so we'd like to do something
> like this again in the future. This would allow us to sidestep the
> order issue in the language, and give us a tool that is better than
> both what we have now and keep the language small.
>
>
> > Maybe I just haven’t spent enough time in LISP to like the 100’s of parentheses thing, but I find the above really tedious to read and work with.
>
>
> I agree fully. I've never been a huge lisp user, and there's a
> reason most lisp tooling focuses on making parenthesis easier to
> work with. In the programs we've written, the proliferation of
> parens usually occurs only in UI, where elements tend to be deeply
> nested. In non-UI eve code, records end up being flatter, so this
> issue isn't as painful. That said, I think there are still some
> tooling solutions here for us as well (matching paren highlighting,
> auto closing parens, or even rainbow coloring parens)
>
>
> > In many cases, with the <> syntax, I may be able to copy and paste static HTML into an input or output block and then just decorate it with “variables”.
>
>
> This is a very good point, but I think again we might have a good
> tooling solution here. For example, in a UI specific editor there
> could be a way to import HTML, and then you can bind Eve records
> into the template you paste in. This would effectively turn static
> HTML into a live site backed by data pretty quickly.
>
>
>
> Corey
>
>

> *

>
> --
> You received this message because you are subscribed to the Google
> Groups "Eve talk" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eve-talk+u...@googlegroups.com

> <mailto:eve-talk+u...@googlegroups.com>.

> To post to this group, send email to eve-...@googlegroups.com

> <mailto:eve-...@googlegroups.com>.

> To view this discussion on the web visit

> https://groups.google.com/d/msgid/eve-talk/365ec282-8595-41d1-a049-0b9e25dbf4f8%40googlegroups.com
> <https://groups.google.com/d/msgid/eve-talk/365ec282-8595-41d1-a049-0b9e25dbf4f8%40googlegroups.com?utm_medium=email&utm_source=footer>.

> For more options, visit https://groups.google.com/d/optout.

--
Ionuț G. Stan | http://igstan.ro | http://bucharestfp.ro

[Zubair Quraishi]

I was thinking that:

 "Search", "Bind", "Commit"

: could be changed to :

"Find", "Link", "Save"

: so that gives two benefits:

1) Eve is easier to remember for the Excel and Word generation who already know what Find and Save means. Bind is a very programmer specific term so I would avoid it
2) When People describe Eve to other people they can describe it as a "FLS" language, much like people describe "MVC" as a pattern, a "Find, Link, Save" lanaguage

[Jeff Bone]

On Apr 29, 2017, at 9:11 AM, Zubair Quraishi <zub...@gmail.com> wrote:

I was thinking that:

 "Search", "Bind", "Commit"

: could be changed to :

"Find", "Link", “Save"

I like it.  It does rely on the understanding of “Link” as a verb rather than as a noun (as in,”I’ll send you a link to that page.")  But its verb-ness in this context can be inferred from the fact that the other two primitives are verbs.

~~~

Following up another thread here (sorry) — regarding the angle syntax, I suspect that the appearance of apparently markup-based syntax in the language will immediately narrow the audience;  it (Eve) will be regarded as a more incremental innovation than it actually is.  Folks who cannot already whip up a web page will immediately think this isn’t for them.

The motivation of using a different syntax to denote ordered vs. unordered is entirely reasonable, though.  Unsure how to reconcile anti-angle-ism vs. the need for that differentiation.

For all that we long-term programmers claim (sometimes) that “syntax doesn’t matter” — every weird character, every syntactic rule that has to be remembered and consistently applied, every different delimiter with different semantics, etc. is nonetheless a multiplicative obstacle for folks that don’t code.  

IMHO, Eve “wins” its major challenge if it gets to the point that your average spreadsheet user can write Flappy Bird on her own.

All just $0.02.  :-)

jb

[Zubair Quraishi]

Well, you said Find/Bind/Save in the first place. This would only be replacing Bind with Link, so I liked your idea actually :)

[co...@kodowa.com]

Jeff,

> For all that we long-term programmers claim (sometimes) that “syntax doesn’t matter” — every weird character, every syntactic rule that has to be remembered and consistently applied, every different delimiter with different semantics, etc. is nonetheless a multiplicative obstacle for folks that don’t code.  

This is something we've found to be very true, which is one of the reasons we've tried to keep the number of symbols in the syntax to a minimum. Having the round parens () in not for instance was a hard decision to make; we'd rather not have them at all!

> Find/Link/Save

I think these are reasonable alternatives to what we have, but I'm not sure it buys us too much with the programmer crowd. I think when Eve hopefully reaches a larger audience after v0.3 is released, we'll take a closer look at the syntax choices given wider feedback, but for now we'll stick with the current words. Keep in mind we could potentially have localized version of the syntax, so that these words are expressed in your native language, so these may be different depending on who uses Eve. Although, I don't know if that leads to more confusion than it solves, but we will definitely be looking at that angle.

Corey

[swthornton]

Hi all, my $2c.

With regard to removing databases from the concepts of Eve I like to go back to the Excel paradigm, Excel doesn't know the data that a user will create other than textual or numeric, if we force users to think in tables or view or combining tables to manipulate data then their minds will be set thus. Eve doesn't know what they want to manipulate (documents/blogs/text/numbers) so we shouldn't get them to solve problems with a structure of Eve's making. Eve should be a 'universe' or 'repository' to hold their creations. On the other hand Eve needs a way for the user to visualise their data, this needs to be in a non ordered way - where abstract data can be added to existing data. 

Steve

[co...@kodowa.com]

Thanks for the input Steve,

That was part of the reason for the move. Taking away databases makes the language in general much more uniform and regular. Another nice property of Excel is that the grid is flat; you can access the contents of any cell from any other cell without having to worry about *where* your target is located. They way you organize and lay out your data is arbitrary, and can change organically over time simply by moving cells around the grid. This is how I hope tags will be used in Eve. We'll have to see how this plays out when more people start using v0.3, but I'm optimistic.

Corey

[swthornton]

Exactly, it comes from some work I did with Document tracking systems, I needed to have documents with extensible meta data - used for searching or drill into the document contents itself, it shouldn't matter where the document is or if its been added with like documents/objects.

Steve

[Adrian Sampaleanu]

Calling scopes by a names other than "databases" doesn't really change much does it? Whether you call them (tuple)spaces, namespaces, sheets (as in Excel), etc., isn't it pretty much the same thing from the POV of the Eve developer, if underlying access differences are abstracted out (which seemed to be the case so far)? Is it specifically the word "database" and its connotation that you're trying to avoid here? 

[co...@kodowa.com]

Adrian,

The most immediate advantage is it reduces the cognitive load by simplifying the language. Before, to access a record you had to worry about its shape as well as its location. This lead to awkwardness, such as how would you programmatically choose in which database to search for records. Now you just have to worry about the shape of a record to find it. Databases aren't special, you use tags instead, and tags are just an attribute like any other.

Another benefit is it makes programs easier to read. Consider this block:

```

search @browser @event @session

  [#click element: [#div person: [#person name]]]

```

Which records reside in which database? The only way you know is through knowledge of the different libraries. Compare to:

```

search

  [#event/click element: [#ui/div person: [#person name]]]

``` 

Now it's much clearer to a reader of the program what's going on.

Corey

[swthornton]

Hi Corey, looks good but we've got to be careful of creating square bracket hell!

[Jeff Bone]

> On May 4, 2017, at 15:00, swthornton <thornto...@gmail.com> wrote:
>
> Hi Corey, looks good but we've got to be careful of creating square bracket hell!

I would second this with the following observation: while "syntax doesn't matter" (much) to us (experienced developers) the experience is very different for novices. Supported by recent experience in teaching my 7 year-old twins to program, I can postulate that every syntactic element has a multiplicative effect on the perceived complexity in learning and using a "language."

Further:

Lisps have long been derided for the abundance of parentheses (even though this actually lightens the syntax per se.) On the other hand Python's meaningful indentation has contributed to its readability and use as an "executable pseudocode" / lingua franca. Lesson there?

One cautionary thought: the equals symbol (=) is perilous; imho it shouldn't be used for assignment but rather only for math-like comparison and constant / constraint / formula definition. And e.g. contrived symbols like "==" and ":=" are bad news.

Finally, the #tag construct is very useful / powerful. However, I worry that it could lead to a "hash-itis" equivalent of the aforementioned "square bracket hell" --- only worse: are #tags set intersection or union or...? A method of pathing through hierarchical namespaces e.g. #friends/name/first=Joe would help immensely.

And finally finally: in some applications database sharing might well be necessary; if not, transferring records is probably necessary. Since Eve stores these (conceptually, at least) as a partial or total order of asserts and retracts, replication is possible (even easy.) But in such cases, provenance ("where did this datum come from?") is vital for many applications. I would advise providing a standard facility for that vs. leaving developers to roll-their-own. The latter would be easy but would lead to a proliferation of incompatible mechanisms.


$0.02,


jb

[swthornton]

Its a similar problem Microsoft faced with Word & Excel user interfaces, They found that if you create for the new user, once they've​ learnt they will find the interface annoying, if you create for the experienced user, new users find it hard to grasp, that's why they changed the menu/ribbon structures with almost every release. That is a catch 22 and applies to language take up in the same way. 2¢

[Chris Granger]

> "syntax doesn't matter"

FWIW, you'll never hear us say that - syntax matters quite a bit. We come at the language from the perspective that it's very difficult to separate what something actually is from how it's used, especially when we're talking about abstract tools. The interface defines the thing. We've been tested many syntaxes and interfaces to Eve over the years and tried to distill the good parts into something cohesive and as simple as humanly possible. There are very few syntactic constructs in Eve and we continue to try to cut them out so long as they don't sacrifice readability and intent.

> On the other hand Python's meaningful indentation has contributed to its readability and use as an "executable pseudocode" / lingua franca.  Lesson there?

Python still has many grouping characters, they just chose not to use them for control flow. That's actually the same approach we've taken with our only "control flow"-like operator being `if`.

> the equals symbol (=) is perilous;  imho it shouldn't be used for assignment but rather only for math-like comparison and constant / constraint / formula definition.

That is the only definition of equality in our language. The update operators (:=, +=, -=) are explicitly fenced off from searches in the bind/commit section of a block. We've tried to come up with other syntactic treatments for those, but they've ended up being verbose, hard to read, and often confusing. If you have thoughts on something better, we'd love to hear about it.

> are #tags set intersection or union or...?  A method of pathing through hierarchical namespaces e.g. #friends/name/first=Joe would help immensely.

I think there might be some confusion on what tags are. When everything is a uniform type, we want a way to put subsets of the universe into meaningful groupings. For example, I may have an Eve instance that has celestial bodies in it and I want to easily identify things that are planets or stars or comets. Instead of having people add an adhoc "type" property everywhere, we decided to formalize the idea into a "tag" on the record. There's nothing actually special about this property, it's merely a convention that indicates that a record is a member of some group and because that's so common, we made it syntactically simple to state. So I can have records that are [#star] or [#planet] and I can search for them specifically. Like other attributes, you can have as many values for tag as you want, meaning you could have something that is both a #star and #planet. The namespacing is only there to ensure that you don't collide with #movie/star when you're talking about #celestial/star. The friend example could look something like this:

```

search

  person = [#person friend]

  friend.name.first = "Joe"

bind

  [#ui/text text: "{{person.name}} has a friend named Joe."]

```

> in some applications database sharing might well be necessary;  if not, transferring records is probably necessary.

Instead of thinking about databases as silos, let's think of tags as potentially being physically located somewhere else, but still part of the same universe. So let's say I have some astronomical data from the lab at UCLA and I'm working on my little star charting app. I could provide some information to Eve to say that #ucla/star is located at some other Eve instance. When I then search for #ucla/star, my local instance will negotiate with UCLA's to determine how we want to share the records. In this way, the universe of your program is a constellation of many sources of data without the need to explicitly care about where it's located or how it's meant to be transported - those details are divorced from the code you write.

>  But in such cases, provenance ("where did this datum come from?") is vital for many applications.

We've discussed provenance a lot throughout our journey - when your whole world is data, provenance is an incredibly powerful tool for debugging and understanding what something means. The fact that we can show the provenance of any value in the system is one of Eve's biggest improvements to programming and while we haven't had the opportunity to focus on it yet, it'll have a big impact in the future.

Cheers,

Chris.

--
You received this message because you are subscribed to the Google Groups "Eve talk" group.

To unsubscribe from this group and stop receiving emails from it, send an email to eve-talk+u...@googlegroups.com.
To post to this group, send email to eve-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/eve-talk/85F0AD79-3BFE-4CF2-82AC-4F6CB3FBD3B3%40mgrep.com.

[Steven Thornton]

. I could provide some information to Eve to say that #ucla/star is located at some other Eve instance. When I then search for #ucla/star, my local instance will negotiate with UCLA's to determine how we want to share the records. In this way, the universe of your program is a constellation of many sources of data without the need to explicitly care about where it's located or how it's meant to be transported - those details are divorced from the code you write.

 

I think this is where data is heading, I’ve been playing with a ‘reactor’ function in ‘Red’ Unfortunately the react usage in Red is only local at present, I am imagining having code on my system that can react to changes in data on another system – or several other system, possibilities makes my head hurt 😊

 

Steven Thornton

[Jeff Bone]

On May 4, 2017, at 5:01 PM, Chris Granger <ibd...@gmail.com> wrote:

> "syntax doesn't matter"

FWIW, you'll never hear us say that - syntax matters quite a bit.

Agreed!  Also FWIW, that statement is a bit of a shibboleth, I don’t hear it as much anymore as (say) 10 years ago.  But to me it’s *always* been important — Sapir-Whorf, Iverson’s Notation as a Tool of Thought, and all that.

Python still has many grouping characters, they just chose not to use them for control flow. That's actually the same approach we've taken with our only "control flow"-like operator being `if`.

It does.  

> the equals symbol (=) is perilous;  imho it shouldn't be used for assignment but rather only for math-like comparison and constant / constraint / formula definition.

That is the only definition of equality in our language. The update operators (:=, +=, -=) are explicitly fenced off from searches in the bind/commit section of a block. We've tried to come up with other syntactic treatments for those, but they've ended up being verbose, hard to read, and often confusing. If you have thoughts on something better, we'd love to hear about it.

Hmm… not sure that I do but let me give that some thought. :-)

> are #tags set intersection or union or...?  A method of pathing through hierarchical namespaces e.g. #friends/name/first=Joe would help immensely.

I think there might be some confusion on what tags are. When everything is a uniform type, we want a way to put subsets of the universe into meaningful groupings. For example, I may have an Eve instance that has celestial bodies in it and I want to easily identify things that are planets or stars or comets. Instead of having people add an adhoc "type" property everywhere, we decided to formalize the idea into a "tag" on the record. There's nothing actually special about this property, it's merely a convention that indicates that a record is a member of some group and because that's so common, we made it syntactically simple to state. So I can have records that are [#star] or [#planet] and I can search for them specifically. Like other attributes, you can have as many values for tag as you want, meaning you could have something that is both a #star and #planet. The namespacing is only there to ensure that you don't collide with #movie/star when you're talking about #celestial/star.

Right, I got that (although I conflated concerns w/ the apparent assignment of a value to the tag.)  My thinking-out-loud was really about specifying unique subset targets:  right now if I search for records with both #foo and #bar, I get the set intersection of the set of all #foo and the set of all #bar — i.e., only those that belong to both.  But how might I compose a find to get me the union of all #foo and all #bar?

The separate concern is that code that works with different tags — as pseudo-types — might assume particular fields, and without coordination between developers and care in the crafting you might end up with collisions in the field namespace, mismatched value types or semantics for fields in different blocks of code, and so on?  I.e., might it make sense to namespace fields, too?

jb

[Chris Granger]

> But how might I compose a find to get me the union of all #foo and all #bar?

If can also be used without exclusion, which makes it a union:

```

search

  stuff = if a = [#foo] then a

             if b = [#bar] then b

bind

  [#ui/text text:"Found some cool stuff: {{stuff.name}}"]

```

> might it make sense to namespace fields, too?

Yeah, I suspect there are times where you might need/want that and there's nothing that prevents you from doing `[#foo/person foo/name]` right now other than it being very verbose. We're curious to see how that plays in practice.

Cheers,

Chris.

[Jeff Bone]

On May 5, 2017, at 1:57 PM, Chris Granger <ibd...@gmail.com> wrote:

> But how might I compose a find to get me the union of all #foo and all #bar?

If can also be used without exclusion, which makes it a union:

```

search

  stuff = if a = [#foo] then a

             if b = [#bar] then b

bind

  [#ui/text text:"Found some cool stuff: {{stuff.name}}”]

Ah!  That makes perfect sense. :-)

Thanks!

jb