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

Syntax #4

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions