Daniel Keep escribió: 
antonio wrote:
  
As I introduced in http://www.dsource.org/forums/viewtopic.php?t=967
object relations could be seen as hierarchycal structures.

¿Why not to introduce native syntax to "navigate into"/"Selec from" this
kind of hierarchies?


ex 1: Add Peter to the friends of people named Andrew and older than 18.

Person peter = ...;
Person[] people = ...;

people[name=="Andrew" && age>18].friends ~= peter;
...
---

The main discussion about this idea was focused in 2 points:
1. "dot" or "not dot":
    people[.married && .age>18]
    vs
    people[married && age>18]

   "not dot" is more "D" syntax compliat (thanks to csaul).

2.Array syntax vs "Template" syntax:
    people[married && age>18]
    vs
    people![married && age>18]

  Personally, I prefer "Array syntax":
    Person p = people[5];
    Person[] p = people[3..5]; // 3..5 is a "condition"
    Person[] p = people[5]; // ¿why not?
    Person[] p = people[married];
    Person[] p = people[age>18 && married];
...
As I said, I agree with the idea: it's a very nice piece of syntactic
sugar.  The problem is with the syntax you've chosen.  One of D's
strengths is that the grammar is context-free, making it easy to implement.

But, without knowing anything about context, what does this mean:

	people[i]

Well, if "i" is an integer, then it's indexing the array.  If "i" is a
member of the elements of the people array, then it would be a
conditional expression.  But what if it's a member, and "i" is an
integer?  Is it a conditional or an index then?
integer expresion refers always to the index.  a char[] expresion refers to a key (associative array), etc...
And what if both are defined?
class Person {
    public in i;  
}
void main( ) {
    int i;
    Person p = new Person();

    with( p ) {
       i = 5; // property of p
       .i = 3; // dot signifies: one level out of this scope... the int i declared one.
    }
}

then

people[i] for member
people[.i] for out of scope declared integer

Even if the compiler can work out a way to distinguish this, the syntax
in its current form looks very hard for humans to parse in certain
fringe cases.

As you said, an alternative is "templateish" syntax:

	people![i]

I like this more, since it's *explicit* about what's going on.  That "!"
means "Hey, don't actually index the array; select elements of it only".
Yes... I think explicit yntax is really more clean:: you convinced to me :-)

Let's go with the new proposed syntax:

STEP 0:  drinking from oter sources... XPATH syntax...

xmlNode.SelectNodes("tagNameA[conditionA]/tagNameB[conditionB]")...
then  xmlNode.SelectNodes("tagNameA/tagNameB[conditionB]") is equivalent to xmlNode.SelectNodes("tagNameA[true]/tagNameB[conditionB]")...


STEP 1:  lets propose something:

The syntax used by the XPath D expression must be "autodefined", becuse whe dont want to use the "xmlNode.SelectNodes( ... )" method :-p.  One solution is using specific ![Condition] that defines "this is an XPath condition"...
.

AggregateExpression![condition] signifies: evaluate the condition on left side aggregated elements and build an aggregated result with elements that passed condition (the result could be a dynamic array)

STEP 2 : what to do with not aggregate expressions :-(

ex:
Person[] youngGrandmothers =  people![childs.length!=0].mother![age<36]

NotAggregateExpression![condition] signifies: evaluate the condition on left side Element and build a dynamic result array with 0 or 1 elements (depending on the condition evaluation result).

STEP 3: whe have to use ![] in all hierarchy node:
ex:
// whe can asume than ![] is equivalent to ![true]
countries![population>10000000].people![age<3].mother![].mainHome![].rooms![windows>2] 
some exceptions: the last hierarchy node doesn't need to be followed by the ![] in some cases:
ex:
    people![married].doSomething();
ex:
    people![married].name = "Peter";
    people![married].childs ~= new Person();
    people![birdtha=today].age++; // This introduce an implicit right side assignment property evaluation... I suppouse this is an "exception" because compiler can solve this easily.

STEP 4: right side must be a member.

Expression![condition].member

STEP 5: How compiler expands this expression.

I suppouse Walter must decide between a preorder or inorder evaluation
             A![].B![].C![]
             could be evaluated like this:
             foreach(a in A)
                tmpA~=a;
             foreach(a in tmpA) foreach(b in a.B)
                tmpB~=b;
             foreach(b in tmpB) foreach(c in b.C)
                tmpC~=c

             A![].B![].C![]
            could be evaluated like this
             foreach(a in A)
                foreach(b in a.B)
                   foreach (c in b.C)

Well... I'm not an expert, but how hierarchy is evaluated is a compiler work and programmer must be isolated about the compiler solution.

We can assume than result elements order can't be predicted (like realtional model).  Results needs to be postprocessed (distinct, sort, ...) if needed.

At any rate, nice proposal, and I look forward to seeing something come
of it :)
I agree... this is, basically, my dream:  People writes constantly FOR + IF structures  that can be easily expressed with this propossal.
Oh, one other thing that suddenly occured to me: what if "people" isn't
an array?  You use 'foreach' in your expansions, but what if "people"
CAN be iterated over, but isn't an array in of itself?  Then the syntax
becomes downright misleading!
D propose an standard implementation for "aggregate" classes... the main goal now is to propose something D compatible:
I_Iterable is not part of D programming Language.... and this is another discussion :-):
P.S.  Your English is better than many people I've seen who don't know
any other languages.  Also, that upside-down "?" is nifty :)
Spanish sintax :-).  thanks a lot
Antonio