<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Daniel Keep escribió:
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap="">
antonio wrote:
</pre>
<blockquote type="cite"><br>
<pre wrap="">Yes... I think explicit yntax is really more clean:: *you convinced to
me :-)*
</pre>
</blockquote>
<pre wrap=""><!---->
Huzzah :)
</pre>
<blockquote type="cite">
<pre wrap="">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)
</pre>
</blockquote>
<pre wrap=""><!---->
Just one point I'd like to make: AggregateExpression may not neccecarily
be an array. It's possible that it is, say, a very *very* large
iterable object. </pre>
</blockquote>
Of course... D specification is very clean in this point: structures,
clases or static/dynamic arrays:<br>
<blockquote>if the aggregate is a struct or a class object, that struct
or class must have an <i>opApply</i> function with the type:
<pre class="d_code"><span style="color: blue;">int</span> <b>opApply</b>(<span
style="color: blue;">int</span> <span style="color: blue;">delegate</span>(<span
style="color: blue;">inout</span> <i>Type</i> [, ...]) <i>dg</i>);
</pre>
where <i>Type</i> matches the <i>Type</i> used in the foreach
declaration of <i>Identifier<br>
</i></blockquote>
<br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap="">The syntax so far is fine, but I think user defined
classes should be given the option of changing what the result of this
is, or even specifying that the result should be an iterable object.
</pre>
</blockquote>
You makes me thing about: my conclusion is that I commited an error
supposing than ![ ] must "return" an aggregate object... I't more clean
to chante the point of view to a "compiler" stament: the result is,
bassycally, a set of iterations over an stament... I explay this
clearly in this new fools proposal :-) :<br>
<br>
<blockquote><b>compiler way</b>:<br>
</blockquote>
<ul>
<li>AgregateExpression![condition] is "equivalent to" foreach( )
with( ) if ( ) structure. This structure must act as a single
stament. The problem is how "sub ![] expressions must be expanded".</li>
<ul>
<li>Example: people![ children![isAGirl].length!=0 ].doSomething</li>
</ul>
</ul>
<blockquote>
<blockquote>children![isAGirl] must act as a single stament that
returns something with the length property :-(.<br>
<br>
In fact, I'm thinking in a most "closed" D programming languaje syntax
like: <b>foreach stament enrichment</b>:<br>
1: include the condition on foreach stament:<br>
<blockquote> foreach(Type obj; Aggregate; obj_scoped_condition) {<br>
<br>
}<br>
</blockquote>
<blockquote> Equivalent to:<br>
</blockquote>
<blockquote> foreach(Type obj; Aggretate) with(obj)
if(obj_scoped_condition) {<br>
obj_scoped_staments;<br>
}<br>
</blockquote>
<blockquote> On "D XPath way" it could be expressed as:<br>
</blockquote>
<blockquote> aggregate![obj_scoped_condition]{ <br>
obj_scoped_staments;<br>
}<br>
</blockquote>
2: (risky): foreach must include some agregate "properties" (closed
to "array" properties):<br>
foreach(....) { }.length (Number of iterations executed )<br>
I think other properties are not necessary.<br>
<br>
With this new syntax, the example could be expressed in this alternaive
way:<br>
foreach(Person p; people; foreach(Person child; childs;
isAGirl).length!=0 ) { <br>
doSomething(); <br>
)<br>
<br>
Of course, I prefer to write <br>
<br>
people![ childs![isAGril].length!=0 ]{<br>
doSomething( );<br>
}<br>
</blockquote>
</blockquote>
observe the new derived syntax implications: the
right side of the aggregate![ condition] is an Stament, not a property:<br>
<blockquote> people![ childs![isAGril].length!=0 ]
doSomething( ); // without the dot "."<br>
<br>
and, of course, the "Subject" of this discussion must be
changed to:<br>
<br>
people![ name=="Andrew" ] friends ~= peter; // really
nice :-)<br>
<br>
of course... this introduce some "problems"... foreach does
not returns data:<br>
<br>
Person[] youngGrandmothers = new Person[]; // We have to
separate the declaration<br>
people![ childs.length != 0 ] mother![age<36]
youngGrandMothers~= this; // and the "~=" assignation.<br>
<br>
</blockquote>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<blockquote type="cite">
<pre wrap="">*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).
</pre>
</blockquote>
<pre wrap=""><!---->
What if you did this instead:
people![childs.length!=0].mother![age<36]
==> ((people![childs.length!=0]).mother)![age<36]
</pre>
</blockquote>
¿Standard D offers some way to build a dynamic array on the fly? (like
c#, java) <br>
<blockquote>Person someone = new Person();<br>
Person anotherone = new Person();<br>
<br>
int count = new Person[]{ someone, anotherone }; // Hoy do you do this
on D?<br>
</blockquote>
<br>
Anyway, with my last proposal, (pure native stament) you can express it
using a with( ) if ( ):<br>
<br>
people![ childs.length!=0 ] with(mother)if(age<36) .... // <br>
<br>
<br>
<br>
<br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">*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]
**
</pre>
</blockquote>
<pre wrap=""><!---->
If you take the above suggestion of not using "real" arrays for the
intermediates, then you don't need to specify ![] at each level.
</pre>
</blockquote>
In my last proposal, ![ ] is an standard D stament... it's necessary to
include it.<br>
<br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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();*
</pre>
</blockquote>
<pre wrap=""><!---->
Hmm... not sure if I'm comfortable with that. Selecting data is fine,
but then performing an operation on that... The problem is that
everywhere else in D, this would be a *single* function call. In this
one particular case, it's multiple function calls.
If you wanted to do this, I think it might be better to spell it out
explicitly:
foreach(person ; people![married])
person.doSomething()
>From the Zen of Python: "Explicit is better than implicit."
</pre>
</blockquote>
In my last proposal... you have to write people![ married]
doSomething(); because doSomething() is an stament, like
people![married]{ doSometing(); doSomethingElse(); }<br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">**
* 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.
</pre>
</blockquote>
<pre wrap=""><!---->
Looks handy :)
</pre>
</blockquote>
With the last propossal:<br>
people![married] name="Peter";<br>
people![married] childs~= new Person();<br>
people![birthday == today] age++;<br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">*STEP 4: *right side must be a member.
Expression![condition].*member*
</pre>
</blockquote>
<pre wrap=""><!---->
I think the "must be a member" is a bit strict. Currently, you can do
things like this:
char[] firstFive(char[] a)
{
return a[0..5];
}
auto firstFiveLetters = "ABCDEFGHIJKLMNOPQRSTUVWXYZ".firstFive;
I'd like to be able to still do that. Perhaps just saying "use whatever
lookup policy D currently uses on arrays" would be sufficient.
</pre>
</blockquote>
this limitation is deprecated with my new proposal. <br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">**
*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)
</pre>
</blockquote>
<pre wrap=""><!---->
I would say that in order would be best... provided it's implemented as
chained iterators. In other words, each of the intermediate "aggregate
results" should only generate elements as neccecary.
The reason for this is that then you can perform very complex filters on
large data sets. If you did it "preorder", then this would be
ludicrously expensive:
SomeHugeDataSet![size > 50*Megabytes]
.largeInternalObject![size > 75*Megabytes]
</pre>
</blockquote>
Yes.<br>
inorder is implicit in my last propossal... because each ![] is a
separate stament (without dot)<br>
A![] B![] C![]<br>
<br>
<blockquote cite="mide3jukg$252o$1@digitaldaemon.com" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">At any rate, nice proposal, and I look forward to seeing something come
of it :)
</pre>
</blockquote>
<pre wrap="">I agree... this is, basically, my dream: People writes constantly FOR +
IF structures that can be easily expressed with this propossal.
</pre>
<blockquote type="cite">
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap="">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).
</pre>
</blockquote>
<pre wrap=""><!---->
I've always thought it would be nice to have a few "standard" interfaces
attached to things like arrays. Only thing is that I imagine converting
between, say, char[] and IIterable!(char) would be very expensive.
Again, I like where this proposal is trying to go. One question,
though: have you looked at Linq in C#? I think it's slated for version
3.0, but it looks quite similar to what you're proposing, and allows you
to do selects and transforms. I'd give you an example, but I can't
remember any :P
-- Daniel
</pre>
</blockquote>
I will look for... not now... my bed is waiting for me.<br>
Good night<br>
</body>
</html>