Re: Flash to JOG

On 13 mar, 19:31, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Mar 13, 6:10 pm, Cimode <cim..._at_hotmail.com> wrote:
>
>
>
> > On Mar 13, 3:51 pm, paul c <toledoby..._at_ac.ooyah> wrote:
>
> > > JOG wrote:
> > > > ...
> > > > Rel also looked interesting, and I liked some of the syntax -
> > > > especially the fact that for relvar datatypes, A + B is the union of A
> > > > and B, and hence A += B is an insert, etc.
>
> > > I think it's more than syntax, TTM defines it that way.
>
> > I used a similar syntax on the current complier I am building...I
> > allowed the possibility to switch operator "+" with "UNION".
>
> > Considering relation A, B...
>
> > What is between [] is a relation
> > What is between {} are is an attribute set or subset
> > What is between || is a constraint (either expressed litteraly or as a
> > the constraint for an existing relation)
>
> > [INT_RANGE = | INT BETWEEN 10 AND 50 | ] --> INT_RANGE un-ary
> > relation (new type) is defined from INT data type --> IN_RANGE is
> > derived from INT.
>
> > [MAKE A={A1 INT_RANGE, A2 INT, A3 INT}] --> A header and constraint
> > set is constituted. It is benefiting from INT_RANGE constraint set
> > through simple typing.
>
> > [MAKE A={A1 INT_RANGE, A2 INT, A3 INT}] --> The traditional way
> > OR
> > [MAKE HEADER[A]=HEADER[B]] --> On this, I thought about openning the
> > possibility to create headers independently from relations at
> > definition time. The system keeps in the repository headers and
> > associates constraints to them. That way relation header B is
> > constituted and the constraints are implicitely implemented through
> > this mechanism...
>
> > The logic is
>
> > --> When a relation A is constituted a header[A] is necessarily
> > constituted and stored in the repository.
> > --> The above header can be assigned to another *unexisting* relation
> > and automatically defines a typing/constraining for all attributes at
> > once.
>
> > [MAKE C = [A + B]] --> Adds relation A to relation B and constitutes
> > new relation C body --> UNION (at relation level) /INSERT (at tuple
> > level)
> > [MAKE C = [A - B]] --> Substracts relation B from relation A and
> > constitutes new relation C body --> MINUS (at relation level) /DELETE
> > (at tuple level)
> > [MAKE C = [A * B]] --> multiples A per B (full cartesian product) and
> > assigns body to relation C body --> FULL JOIN (relation level)/
> > [MAKE C = [A/B{A1, .....AN}]] --> divides A per B and assigns result
> > to relation C body. --> GROUP BY
>
> > The rest is just presenting
>
> > PRESENT2D [C] --> Tabular format
>
> > Let me know what you think...
>
> Promise me you're not going to do a neo and post this stuff on every
> thread....
LOL...
All right, all right....Sorry I have hacked this thread. Here is a token of my repentance...

I shall not mention how my compiler handles relational operations I shall not mention how my compiler handles relational operations I shall not mention how my compiler handles relational operations I shall not mention how my compiler handles relational operations I shall not mention how my compiler handles relational operations

I am trying to gain some feedback on the compiler I am currently building before release in open source. Received on Thu Mar 13 2008 - 20:47:39 CET