Re: Onto a potential relational manipulation language
Date: Tue, 09 Dec 2008 19:12:52 GMT
> Cimode wrote:
>> A some know and might be interested into, I am currently building a db >> core and currently trying to move forward onto giving it a compiler to >> allow programmers a practical access to relation operations and >> separating relation presentation... >> >> As I am not a language designer, I would be glad if someone would >> provide a feedback as to their perception about the below syntax...
> Just a general suggestion: I'd seriously consider picking a syntax
> that is highly compatible with an existing one (e.g. a subset of SQL),
> even if the semantics vary in places.
Cimode, from your past posts, I seriously would not consider it likely that you would consider most subsets of SQL. And I wouldn't blame you! (UNLESS the subset of SQL were so small as to include merely an SQL keyword written as 'KEY'!)
I can't comment on the syntax because i) I don't think one can get very far with a syntax without seeing quite a few examples and ii) I don't know the scope of your db's features. By 'scope' I mean how far it goes toward capturing the usual physical suspects - concurrency, recovery and so forth. I mention this because I saw the word 'PERSISTENT' in the example. If I were making up a syntax, I'd start by naming shortcuts for expressions based on some formal logic. The one closest to my thinking would be D&D Algebra but there are others, don't ask me how many, such as Vadim's RL.
Personally, I even separate persistence from my preferred (admittedly very narrow version) of the essential RM is and think of it as a physical phenomenon and quite orthogonal to the minimum scope of a db. I know lots of people who think it's crazy to have a db that's here today and gone tomorrow, but it doesn't bother me. In fact, I remember many db's that I wished would just go away.
I even view types or domains as orthogonal in the sense that I don't see why a minimal implementation of an algebra needs to know how to construct them. All it really needs is some other implementation to tell it when two values are equal (the 'other' implementation could even change its answers from day to day in my view). I don't think this denies the chance to have user-defined types, it just means that I would start with the most minimal features and syntax possible and build from there, that way after adding another 'suspect', I could revisit all my previous jumping-off points to see if their answers remained what I intended. Received on Tue Dec 09 2008 - 20:12:52 CET