<div dir="ltr">Dmitry, this depends on how you're going to use yaql. yaql 1.0 has so called legacy mode that is a layer on top of yaql that brings nearly full backward compatibility including some of the things that were wrong in yaql 0.2. Use this mode when backward compatibility is a must. Without it the following changes may affect queries written for 0.2:<div><br></div><div>1. There are no more tuples. foo(a => b) will mean now f(a='b') instead of foo(tuple('a', 'b')) as it was in yaql 0.2. However dict(key1 => value1, key2 => value2)  and several other functions with the same syntax work exactly how they used to work in 0.2</div><div>2. Contradictory to the first point there are no more lists. Yaql works on immutable structures (tuple, frozenset and yaql1 own FrozenDict). All operations that seem to modify data in fact return modified copies. All input data will be automatically converted to their immutable versions and converted back upon completion. This has 2 side effects: a) if you have custom yaql functions they should follow the same pattern b) even if your input data were build from tuples etc output will still use lists (e.g. JSON format)</div><div>3. $dict.key will raise KeyError for missing keys instead of returning None. Also key must be a valid keyword and cannot start with 2 underscores. There are many other ways to retrieve dictionary value: $dict.get(value), $dict.get(value, default), $dict[value], $dict[value, default]</div><div>4. In yaql 0.2 every function could be called as a method. So $x.foo() was the same as foo($x). In yaql 1.0 it is up to function to decide if it wants to be a function (foo($x), method ($x.foo()) or extension method (both syntax).    Considering that yaql handles different function overloads $x.foo() may be a valid expression and execute something completely different from foo($x).</div><div> Most of type-specific functions are declared as a methods. So you no longer can say toUpper(str) but only str.toUpper()</div><div>5. yaql 0.2 had very few functions. yaql 1.0 has huge (~260 functions/operators etc) standard library. However several of the 0.2 functions now have different signature or name, replaced with better alternative or just accept additional (optional) parameters</div><div>6. $collection[$ > 0] doesn't work anymore. Use $collection.select($ > 0) for that</div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small">Sincerely yours,<br>Stan Lagun<br>Principal Software Engineer @ Mirantis</span></span><br><span style="border-collapse:separate;color:rgb(0,0,0);font-family:'Times New Roman';font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;font-size:medium"><span style="font-family:arial;font-size:small"><br><a href="mailto:slagun@mirantis.com" target="_blank"></a></span></span></div></div></div>
<br><div class="gmail_quote">On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine <span dir="ltr"><<a href="mailto:dzimine@stackstorm.com" target="_blank">dzimine@stackstorm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This is great news Alex, was looking forward to it, will be happy to migrate Mistral.<br>
<br>
Some heads-up on what syntactically changed would be much appreciated to pass on to our users;<br>
we likely will catch much of them with Mistral tests, but some may bubble up.<br>
<span class="HOEnZb"><font color="#888888"><br>
DZ.<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Jul 27, 2015, at 2:04 AM, Alexander Tivelkov <<a href="mailto:ativelkov@mirantis.com">ativelkov@mirantis.com</a>> wrote:<br>
<br>
> Hi folks,<br>
><br>
> We are finally ready to release the 1.0.0 version of YAQL. It is a<br>
> huge milestone: the language finally looks the way we initially wanted<br>
> it to look. The engine got completely rewritten, tons of new<br>
> capabilities have been added. Here is a brief (and incomplete) list of<br>
> new features and improvements:<br>
><br>
> * Support for kwargs and keyword-only args (Py3)<br>
> * Optional function arguments<br>
> * Smart algorithm to find matching function overload without side effects<br>
> * Ability to organize functions into layers<br>
> * Configurable list of operators (left/right associative binary,<br>
> prefix/suffix unary with precedence)<br>
> * No global variables. There can be  more than one parser with<br>
> different set of operators simultaneously<br>
> * List literals ([a, b])<br>
> * Dictionary literals ({ a => b})<br>
> * Handling of escape characters in string literals<br>
> * Verbatim strings (`...`) and double-quotes ("...")<br>
> * =~ and !~ operators in default configuration (similar to Perl)<br>
> * -> operator to pass context<br>
> * Alternate operator names (for example '*equal' instead of '#operator_=')<br>
>  so that it will be possible to have different symbol for particular operator<br>
>  without breaking standard library that expects operator to have well<br>
> known names<br>
> * Set operations<br>
> * Support for lists and dictionaries as a dictionary keys and set elements<br>
> * New framework to decorate functions<br>
> * Ability to distinguish between functions and methods<br>
> * Switchable naming conventions<br>
> * Unicode support<br>
> * Execution options available to all invoked functions<br>
> * Iterators limitation<br>
> * Ability to limit memory consumption<br>
> * Can work with custom context classes<br>
> * It is possible to extend both parser and set of expression classes<br>
> on user-side<br>
> * It is possible to create user-defined types (also can be used for<br>
> dependency injection)<br>
> * Legacy yaql 0.2.x backward compatibility mode<br>
> * Comprehensive standard library of functions<br>
> * High unit test coverage<br>
> * Delegate and lambda support, including higher order lambdas<br>
><br>
> etc, etc.<br>
><br>
> So, this is a big change.<br>
><br>
> And as it always happens when moving from 0.something to 1.x the<br>
> breaking changes are inevitable. We have included the "backwards<br>
> compatibility mode", but it may not address all the possible concerns.<br>
><br>
> So.<br>
> We have released a release candidate 1 of yaql 1.0.0 on pypi: [1]<br>
> It includes all the new functionality and is likely to be identical to<br>
> final release (that's why it is RC after all) and we strongly<br>
> encourage all the yaql users (Murano and Mistral first of all) to try<br>
> it and prepare "migration patches" to use it. When the final release<br>
> is out, we'll update the global requirements to yaql >= 1.0.0, which<br>
> is likely to break all your gate checks unless you quickly land a<br>
> migrating patch.<br>
><br>
> Please email us any concerns or contact me (ativelkov) or Stan Lagun<br>
> (slagun) directly in IRC (#murano) if you need some quick help on yaql<br>
> 1.0 or migrating from 0.2.x<br>
><br>
> Happy yaqling!<br>
><br>
><br>
> [1] <a href="https://pypi.python.org/pypi/yaql/1.0.0.0rc1" rel="noreferrer" target="_blank">https://pypi.python.org/pypi/yaql/1.0.0.0rc1</a><br>
><br>
><br>
> --<br>
> Regards,<br>
> Alexander Tivelkov<br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>