> The Named Node "Debacle"
> ---------------------------
> 
> I wanted to be able to attach a "node name" attribute to each node,
> and then be able to replace:
> 
> STORE LISTEN ( ORIGIN = 1, RECEIVER = 2, PROVIDER = 3 );
> 
>  with, let's say:
> 
> STORE LISTEN ( ORIGIN NODE = 'org master', RECEIVER NODE = 'data warehouse', PROVIDER NODE = 'whois server' );
> 
> I'm sure you'll agree that the latter is much more mnemonic than
> something involving perhaps-cryptic numbers :-).
> 
> I got started on it, and, at first, it was looking promising.  It
> involved adding a number of tokens to the tokenizer, and affected the
> parsing of quite a lot of Slonik options, but, with a bit of
> struggling with Yacc, it wasn't particularly difficult to get the
> syntax working.
> 
> THEN I ran into the _REAL_ problem, namely that the change led to a
> need for remarkably massive changes in the semantics of the Slonik
> statements.  If I referenced a node name, then I'd have to look up in
> a database what node that refers to.


You've mixed together 2 different problems into the same solution.  

Symbolic names are good (no disagreement there), but adding support for
symbolic names does not necessarily imply that you have to store the
names in a database.   When I write a C program, I don't have to store
my identifiers in a separate database - the symbolic names are defined
in-line.

In other words, you could have come up with a solution like:

DEFINE NAME ( NAME = 'org master', VALUE = '1' );
DEFINE NAME ( NAME = 'data warehouse', VALUE = '2' );
DEFINE NAME ( NAME = 'whois server', VALUE = '3' );

STORE LISTEN ( ORIGIN NODE = 'org master', RECEIVER NODE = 'data
warehouse', PROVIDER NODE = 'whois server' );

You don't have to make a multi-pass script processor as long as you
require that symbolic names be defined before they are used.
You get the benefit of symbolic names without worrying about the other
(real-world) issues that you've mentioned.

But please understand, I'm not trying to add symbolic names when I
suggest an include mechanism.


> Onwards to discussing inclusions
> --------------------------------------
> 
> Note that I haven't yet said anything direct about why I'd object to
> your 1, 2, or 3 items.  Let me get direct now :-).  I certainly don't
> mean to rake you over the coals for having a "horrible, terrible, dumb
> bad idea;" your idea is, at root, a good one. 

I have my asbestos underwear on today :-)


> The fundamental problem is that 'inclusions' would turn Slonik into a
> 2 pass language (like C) rather than 1 (like Pascal), which would
> substantially complicate the processor.  


File inclusion does not imply a two-pass algorithm.   You can add
nested-include support to slonik with minor adjustments to scan.l,
include files are a feature that you would add to the lexer, not the
parser.


> Slonik is a very simple
> language, a <http://c2.com/cgi/wiki?LittleLanguage>, and adding
> features that aren't _directly_ about configuring Slony-I instances
> breaks that.


Excellent point that I agree with completely.  

However, the real problem that I am trying to solve is that every script
requires the same n-lines at the beginning of the script.  That's a
really good way to introduce errors.  

  ++ Murphy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://gborg.postgresql.org/pipermail/slony1-general/attachments/20050303/64d31be8/attachment.html