c[:]()

[Warren Stringer]

Roland Puntaier [mailto:Roland.Puntaier at br-automation.com]
> Warren, can you please restate your point.

Hey Roland, where were you a few days ago ;-) I think most suggestions were
valid, in their own context. Only yesterday, was I finally able to get it in
perspective, so here goes:

There are two idioms: a domain specific language, called Tr3
http://muse.com/tr3/Tr3%20Overview.pdf , and Python. The idioms both
complement each other and conflict. Most of this thread has explored that
conflict.

Tr3 has three main components: a namespace tree, a directed graph of inputs
and a directed graph of outputs. By analogy: the namespace functions like
XML, inputs function like callbacks, and outputs function like standard
procedures. 

The precursor to Tr3 was written C++. The inputs were script while the
outputs were in C++. So, any changes in procedure required a recompile. The
new version still allows C++ plugins, but the procedures can be written in
Python.

Inputs to Tr3 are queries to other parts of the namespace. By analogy,
inputs behave like an Xpath query. So `a//z` searches for all descendants of
`a` named `z`. The results of a query yields a list that can change state
for the node on the tree which made the query. Another example, more in line
with the title of this thread, is the query  `a[:4]b`, which returns a list
`[a[0].b, a[1].b, a[2].b, a[3].b]`

Outputs are Python. This thread was my way of exploring to what degree that
the `a[:4]b` of inputs could be applied to outputs as `a[:4]b()`. It would
be idiomatic to Tr3 but not as idiomatic to Python. Here's why:

What should this mean?
    if a[:4]b():  .

Should it mean:
    if a[0].b() and a[1].b() and a[2].b() and a[3].b(): .
or
    if a[0].b() or a[1].b() or a[2].b() or a[3].b(): .
or    
    if a[0].b(): .
    if a[1].b(): .
    if a[2].b(): .
    if a[3].b(): .

Each interpretation could be justified. Thus, the implicit iteration is
ambiguous. 

I am porting code that only uses this form
    a[:4]b()

Which translates to:

for i in range(4):  
    a[i].b()

There is only one interpretation and thus unambiguous.

I have also explored writing client code that interprets  `a[:4]b` as:
     if a[0].b() and a[1].b() and a[2].b() and a[3].b(): .
A few algorithms, like Huffman codes, wind up looking much simpler, with
implicit iterators. Be that as it may, making such algorithms easier to read
may not be worth the cost of adding ambiguity to a general purpose
procedural language. 

So, you're all right. Relax. Get outdoors. Fall in love. Make someone happy.

And thanks again,

\~/