Re: About grammar and syntax on a possible relational language

On 13 mar, 19:30, JOG <j..._at_cs.nott.ac.uk> wrote: [Snipped]
> Few comments for you. Looks sound enough, but do you even need the
> word "MAKE"
It is an arbitrary choice. In initial version, I thought about using nothing then I thought about using SET and I finally settled on MAKE. The idea is to create awareness that we are working with a construct with potential users.
(and why the capitals?).
The MAKE verb is in fact case insensitive. I posted it this way only to make it more readable in this thread.

> I also fear that the square
> brackets around statements will make code look more confusing than
> need be - are they really necessary (I understand they inidicate a
> "relation expression").
Well, it's a tough choice but this is what make the expressive power of the language. When using brackets, one should think relation. When one uses {} then we are shifting to attribute based thinking. That back and forth shifting is what makes easier to shift from relation level operation to tuple/attribute level operation. On a broader context, I had to establish some kind of coherence in the convention used to jump back and forth from regular thinking to set oriented.

> You also mentioned that for constraints you use |constraint| - I'd
> personally avoid that, given the use of the bar symbol in logical
> disjunction. Whats wrong with good old parentheses used when
> necessary?
I like the idea. I may reconsider that. I thought about reserving parenthesis to the media layer but that is an arbitrary choice.

>
>
> > does the same thing as
>
> > PRESENT2D [{ATTRIBUTE0_1, ATTRIBUTE0_2} UNION {ATTRIBUTE1_1,
> > ATTRIBUTE1_2}]
>
> As with TroyK, I found "present2d" to be a bit offputting. In your
> initial examples I'd recommend just calling it "present"
I can see that PRESENT2D seems confusing. My initial choice for presenting the tabular format was simply TABLE but then I was afraid to create an endless source of confusion for programmers priorly exposed to SQL.
I was also thinking about possible non bidimensional presentations such OLAP and the opportunity to create OLAP cubes such as

PRESENT3D(A1, A2, A5)[relation] which would be a cube with 3 dimensions.

PRESENT-N-D(A1.......AN)[relation]

Based on your comment I might simply make PRESENT2D a synonym for PRESENT.
> ? Capitals

Just in this thread. The verbs used in the language are totally case insensitive for the compiler.
> also give me flashbacks of Cobol PIC's, so I'd personally go lowercase
> too ;)
I will leave it open to programmers choice.

> Just my 2p worth.
Thank you very much. That was helpful/ Received on Thu Mar 13 2008 - 21:06:17 CET