Save multiple databases

[alexispurslane]

This is a discussion of why multiple databases should or shouldn't be kept in Eve.

[alexispurslane]

Okay, so the opening comment...

In response to @cmontella,

The problem solved by multiple databases was that of scoping/namespacing. It also allowed a degree of organization. We'd like to still preserve these properties of the language. But it introduced a problem of having to think about the location of records, in addition to their shape.

How is namespacing different from this? For example, when you say namespacing I see something like this:

search
  [#users::premium-user username plan]

bind
  [#browser::div text: "User {{username}} subscribes to the {{plan}} plan."]

That could be done right now, I think, replacing :: with a dash. I realize this is kind of a straw man considering I don't know how you plan to implement namespacing. However, I'll forge ahead. Compare this to the current equivalent:

search @users
  [#premium-user username plan]

bind @browser
  [#div text: "User {{username}} subscribes to the {{plan}} plan."]

There are two problems with the namespaced option. First: It's verbose. Second: Instead of being able to see what databases/namespaces the block is using at a glance, a programmer would have to dig through the rest of the block to figure out what namespaces it is using. In addition, if the name of a namespace was changed, the programmer would have to change it in many more places.

The solution to this, of course, is having a statement similar to a "from import all", but isn't that what the current semantics are for multiple databases?

In conclusion, as I see it, the most intuitive implementation of namespaces only add verbosity and confusion, and remove some maintainability and readability.

So let me ask you this: what specifically draws you to the idea of multiple databases? What do you think it will help you accomplish or make easier? I'm definitely interested in hearing your thoughts

As far as the specific draw to multiple databases for me, it's twofold: first, they help me think about and focus the overall purpose of a block by stating at the outset what database is it'll use, and thus what it will do. For example, if it says search @session @users .... bind @browser I can tell immediately that it's most likely displaying session and user data. The second reason is that it seems like an elegant solution to avoid name clashes and accidental modification of data.

I guess it all comes down to how you plan to implement namespaces, though. Also, since code blocks aren't supposed to be that long, the namespace solution above wouldn't hurt too bad. I'm interested to know, though, what benefits do namespaces bring, and how do you plan to implement them?

[cmontella]

@christopherdumas

Thanks for adding your thoughts about databases. A lot of what you say here addresses the syntactic issue of databases, but there is a semantic dimension as well, which is probably more important. If we want to retain the syntax, we could still support this:

search @event
  [#click]

commit @browser
  [#div text: "Hello"]

and transform it into this (in terms of what the compiler sees):

search
  [#event/click]

commit
  [#dom/div text: "Hello"]

That's probably not the direction we want to go, but I'm trying to highlight the distinction between the semantics and syntax of the issue.

I think the biggest win moving away from databases from a semantic standpoint is that it removes a special case in the language, and brings back the idea that everything is data, and there are no special rules, and everything is uniform.

As for as what this will look like in the editor, I'm not too sure yet. But your points about verbosity and being quick indicators as to the purpose of a block are well taken, and I would like to maintain those properties as well.

[alexispurslane]

Okay, I was slightly confused (I hope I made this clear in my post) about what you were intending to do, but now I see what you mean about the namespaces: they're more of just regular tags with prefixes, and that gives the same functionality as multiple databases, but without the sugar and under the hood, making Eve more consistent. I totally appreciate consistency as long as it doesn't get in the way of practicality, (Scheme being my favorite language to date).