Syntax

[cmontella]

RFC Link - https://github.com/witheve/rfcs/blob/master/proposed/syntax.md

[Eucalyptus2013]

In the chat app, you use freeze all.

What does it mean?

Thanks

[cmontella]

https://github.com/witheve/rfcs/blob/master/proposed/syntax.md#freeze-all

Good catch, I forgot to include a section on that. Right now, all is used to specify that the subsequent objects are available globally. By default, facts you add to Eve are visible only to your session. In the chat app, we need those messages to be available to other users, so we use the all keyword.

Honestly, we're not too thrilled with the keyword all (maybe global makes more sense?), so suggestions here are appreciated.

[RubenSandwich]

Considering the call for a new name for Eve's Objects:

(object is a pretty generic and overloaded term, so let us know if you have ideas for what to call these guys)

The name Object is problematic for a variety of reasons. You mention the obvious one of Objects in Software is usually referring to a unit in a OOP model. This is problematic not only for the person who is familiar with OOP but also for the person who has heard of OOP, and also for the learner of Eve who after Eve might want to dip their toes into other forms of programming. Furthermore the term Object is a vague and crude term in that anything can be an object.

So I suggest the name Records. You describe objects as:

key-value pairs attached to a unique ID

This falls in line with the concept of Records in Elm and Databases, and somewhat close to other functional programming languages concept of Records. But more importantly Records is a term already known well to mean a collection of data about a specific thing to the general public.

[bertrandrustle]

Given that "Eve" is a homophone of "EAV" (Entity-Attribute-Value) and that EAVs are Eve's core abstraction under the hood, it seems more appropriate to refer to Eve's objects as entities. entity.attribute = value is more conventional than object.attribute = value.

Record is also a sensible alternative.

[shamrin]

 guest = if p = [#friend busy-dates: not(party.date)] then p
         if [#friend spouse busy-dates: not(party.date)] then spouse

And later:

In the above example, we add guests to the list if they are a friend and not busy, or if they are a spouse of a friend and not busy.

It seems to be an inconsistency here. If I'm not mistaken, "if they are a spouse of a friend and not busy" should be written as if [#friend spouse: [busy-dates: not(party.date)]] then spouse. Currently you've implemented "if they are a spouse of a non busy friend".

[cmontella]

Pascal pointed out some deficiencies in the example on the mailing list. We wrote it a couple weeks ago when the runtime still couldn't run the code. I'm currently rewriting the program to make it correct.

[Eucalyptus2013]

How long does a session last?

After the session is closed, is the data stored in the Eve DB deleted?

[cmontella]

@Eucalyptus2013: The Eve DB is a distributed database, so it's a little nuanced, since there are actually multiple DBs (we call them "bags", a better word is appreciated here too).

When you start an Eve server, it starts with an empty global bag. When I start a session on the server (which lasts as long as I am connected to it i.e. the websocket is open), then I'm given my own instance bag, which is empty. But the facts available to me are the union of my instance bag and the global bag.

So every time I say freeze or maintain, the subsequent facts are added to my instance bag. When I leave, I take all my facts with me.

When I say freeze all, then I'm no longer talking about my instance bag, I'm talking about the global Eve bag. In that case, when I leave, my facts are still there.

In the context of a chat app, it uses freeze all to put the messages in a global bag. Thus if I'm in a conversation and my session disconnects, my messages don't suddenly disappear from the terminal. Similarly, if my friend is messaging me while I'm not disconnected, I will see the messages as soon as I connect, because those messages will be in the global bag, and the global bag is unioned with my instance bag.

Does that make sense?

[Eucalyptus2013]

If I want to store a fact in the global bag (by using freeze all), because I want to access this fact after the session is closed, but I don't want the other users to access this fact, how can I do this?

[cmontella]

Right now, our permissions story is incomplete. Eventually, we will have a notion of a user, and be able to stick facts into bags with restricted access.

Until then, you can create your own users, and parameterize the facts with a user attribute. The you can join the restricted facts against the current user. The chat example does this in a way.

[cmontella]

Okay, I've updated the RFC with a better example program. Right now, there are still some execution issues with it, so the result if you run it isn't correct. But we'll work on those more today.

I also removed a section on reusable code. We had a discussion about user defined functions yesterday, and that whole area will be going through a redesign. I'll add that new design to the proposal here as a pull request when I've gotten it together.

[bertrandrustle]

After further consideration, being as objects are employed not only as literal representations of Eve DB facts but also as patterns for matching against such facts, I don't believe records is a suitable replacement term for objects; and while entities still seems applicable, I now prefer the term forms.

[rainhead]

First off, how stable are you trying to get your syntax? You mention under "Risks" that you don't want to turn people off, which is reasonable, but Eve is not at risk of becoming hoon. I'd worry less about turning people on or off and more about gently introducing them to the semantics. Let's allow ourselves to learn how to write Eve programs before we get confident about syntax.

That said, the biggest thing I'd expect to cause people to "not get it" and be turned off is the fact that although a block looks like a procedure, you're actually building a single query. let … in … and similar constructs frame this well in e.g. Haskell, but I'm not sure how to give an imperative programmer the right expectations.

The second-biggest thing are the set semantics. This still throws me off sometimes after writing SQL for 10-15 years. I really don't know what to recommend, but I feel like the syntax has to communicate a programmer's expectations around cardinality. Perl's @ sigil is the only real thing that comes to mind.

On objects: I agree, records or entities would be fine. "Record" is maybe more friendly.

On phases: I think of "prepare" and "commit" phases, if we are talking about them. Consider "do" and "commit", but I'm not confident I understand my intention when using freeze and freeze all. I think there's a sense of making a commitment to others, of making a statement that is hard to retract, so: "publish"? Manipulating the state of bags is surely not what I'm thinking about.

if guest = [@Arthur] What's going on here? Is = testing for set membership? For set intersection?

guest = [#invited name]: The [#invited] syntax seems to reinforce the idea that you're dealing with a set, but then you're assigning that set to a singular guest. Again, how does the programmer express expectations around cardinality?

sum(burgers given burgers, guest) I read , as having lower precedence than given, and didn't understand what was going on here until I read the explanation.

What is [#session-connect] for? Does it mark the beginning of a serializable transaction? Is it necessary? Why does it share tags' syntax?

People who are 50 year old
  [tag: "person" age]
  age = 50

Regarding age: this auto-binding feels much too subtle. You're also discouraging people from using identifiers that communicate something about the intention of the block, or tie together multiple queries. This feels more confusing than destructuring does in ES6, but maybe my feelings would change with practice.

How do you fit predicates other than equality into that record query syntax?

Sorry, I'm at a disadvantage here: you've spent a couple years programming in this paradigm, and I haven't. I can tell you what's confusing to me, but without that experience of solving actual problems in Eve, it's hard for me to suggest concrete improvements.

[cmontella]

Peter,

Sorry, I'm at a disadvantage here: you've spent a couple years programming in this paradigm, and I haven't. I can tell you what's confusing to me, but without that experience of solving actual problems in Eve, it's hard for me to suggest concrete improvements.

Actually, you're exactly the kind of person we want commenting on this; we need the perspective of an outsider because ultimately we want more people using Eve than just us :)

First off, how stable are you trying to get your syntax?

I think we're happy with the overall direction of the syntax, so we wouldn't want to switch to s-expressions or a c-style curly brace syntax. That said, we still see this syntax evolving as we discover more about how to write good programs this way. Since we posted the RFC, we already have new ideas for how to do user defined functions.

That said, the biggest thing I'd expect to cause people to "not get it" and be turned off is the fact that although a block looks like a procedure, you're actually building a single query.

One of our decisions we hope will mitigate this perception is that the blocks are not really named, and there's no real concept of "calling" a block, so without those a procedure really can't exist. Once upon a time, we thought about wrapping the blocks in a query {} just to delineate them, but it seemed redundant and unnecessary.

Another way we hope that our code doesn't "look" procedural is that we're trying push the idea that eve files are actually prose with code interspersed, rather than code with comments interspersed. Thus, visually, eve code will look more like a document than code.

Finally, I think that while the statements could look procedural, the overall feel of the syntax stresses that there’s something different going on. If we had a c-style curly brace syntax, I think that it would be a much bigger concern.

The second-biggest thing are the set semantics.

Yes, we see this as a source of confusion too, but we hope to mitigate it in several ways. For the most part, you can actually code without thinking about cardinality, because our evaluation is row by row. Just consider everything as a scalar, and most of the time things just work when they’re not. You really only have to pay attention to cardinality when you’re using an aggregate, or mutating.

With a little tooling though, we can actually provide the cardinalities of your variables as you code, so this is one way we can help here. Another might be to try and enforce a convention, that plural variables should be used for sets and singular ones should be used for scalars. But that would be purely convention. Regardless, we'll see if this is an issue or not.

if guest = [@Arthur] What's going on here? Is = testing for set membership? For set intersection?

guest = [@arthur] is saying that guest is equivalent to an object that has a name @Arthur.

Again, how does the programmer express expectations around cardinality?

Any time the programmer uses a tag selector, then there's the potential for cardinality greater than one. Regarding the plurality of the variable, maybe this is something we try to encourage through convention. If the variable can be plural, write it as a plural.

sum(burgers given burgers, guest) I read , as having lower precedence than given , and didn't understand what was going on here until I read the explanation.

Commas for us are whitespace. They have no syntactic meaning. The use of the comma here was in the english sense to delineate a list. It should be read "sum the burgers given burgers, guest". However, we’re thinking about new ways to express this to avoid any confusion.

What is [#session-connect] for? Does it mark the beginning of a serializable transaction? Is it necessary? Why does it share tags' syntax?

It has a tag because it’s a normal object, like any other. When I connect to the server, Eve puts a #session-connect in the DB that exists for one tick of the executor. For that one tick, the object [#session-connect] exists, and I have the opportunity to do something to the DB. So this is a good place to initialize any data with a freeze. Using a maintain here would destroy the data on the next tick, because [#session-connect] no longer exists.

This is something we might sugar over in the future though.

Regarding age : this auto-binding feels much too subtle. You're also discouraging people from using identifiers that communicate something about the intention of the block

You can bind any variable to create an alias. For example: [#person age: age-of-a-person]

How do you fit predicates other than equality into that record query syntax?

The same way you do equality. For instance: [#person age > 50]

Thanks again for your comments; you've raised some important points that I need to think about some more. Let me know if you have more ideas/opinions

[bertrandrustle]

When an Eve program is run, are the blocks evaluated in top-down sequence as they appear in the source file?

When a block is evaluated, is the collect phase evaluated eagerly, or is it evaluated when its objects are first referenced in the mutate phase?

Blocks with a maintain clause appear to keep the queries in the collect phase alive. Is there syntax for terminating these open queries programmatically?

Can a single block contain a maintain clause and a freeze clause?