people[name=="Andrew"].friends ~= peter

[antonio]

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]")...

    * "[condition]" signifies: evaluate this condition on left side
      tagNode contents.

    * When no condition is imposed XPath assumes "[true]";

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:

    * When the node is a Method:

        ex:
            people![married].*doSomething();*

**

    * When the node is a property and it's on the left side of an
      assignment

        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

    * preorder:  first all parents, then their childs :

             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

    * inorder: first parent, then their chids... when childs evaluated
      next parent... and so on

             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:

    * Is there a standard I_Iterable interface?
    * foreach( ) recognizes this I_Iterable interface?
    * Array acomplish with the I_Iterable interface?

I_Iterable is not part of D programming Language.... and this is another 
discussion :-):

    * It could be perfect some standard Interfaces recognized by the
      compiler, like c# foreach or using staments (IIterable and
      IDisposable interfaces).

> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20060506/6aad675d/attachment.html>