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...

Assuming the following relations :SUPPLIER = {NAME, STATE, FTP_IP} and
PARTS = {PART_NUMBER, SUPPLIER, QTY}

I can now run...

START [SCHEMA1] --> Mandatory defined

PERSISTENT --> Optional: Instruct the subsystem to persists
information as a part of the schema

(
SUPPLIER = [{NAME NATURAL_KEY, STATE, IP}] --> Defines the SUPPLIER
relation
PARTS = [{NAME CHAR, PART_SUPPLIER SUPPLIER, QTY NUMBER}] --> Defines
the PARTS relation
)

NONPERSISTENT --> Optional: Instructs the system of non persistent
relations creation
(
--Defines new derived relations
PARTS_OF_TEXAS =[PARTS WITH SUPPLIER = 'TEXAS']
PART_IN_LOW_SUPPLY = [PARTS WITH QTY <= 1]

--Defines new derived relations
PARTS_SENT = [PARTS_OF_TEXAS AND PART_IN_LOW_SUPPLY]
)
END


START [SEND_TO_IN_LOW_SUPPLY_TO TEXAN_SUPPLIERS]
PRESENT --> Optional: Instructs the subsystem to send the output to an
FTP site as a comma delimited TXT file
(
FTP(PART_SENT.IP, TXT, ',').PART_SENT
)
END


Thanks...

[Snipped]

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier

Cimode wrote:

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.

This will make it easier for any tool that already supports that language
to be extended to support yours. Besides, you mimimize the risk of
leaving all kinds of unknown ambiguities and other problems, since many
of them will have been avoided there or are at least well known.

--
Reinier