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:

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
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)
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]
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).
 Most of type-specific functions are declared as a methods. So you no
longer can say toUpper(str) but only str.toUpper()
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
6. $collection[$ > 0] doesn't work anymore. Use $collection.select($ > 0)
for that



Sincerely yours,
Stan Lagun
Principal Software Engineer @ Mirantis

<sla...@mirantis.com>

On Tue, Aug 4, 2015 at 9:57 PM, Dmitri Zimine <dzim...@stackstorm.com>
wrote:

> This is great news Alex, was looking forward to it, will be happy to
> migrate Mistral.
>
> Some heads-up on what syntactically changed would be much appreciated to
> pass on to our users;
> we likely will catch much of them with Mistral tests, but some may bubble
> up.
>
> DZ.
>
> On Jul 27, 2015, at 2:04 AM, Alexander Tivelkov <ativel...@mirantis.com>
> wrote:
>
> > Hi folks,
> >
> > We are finally ready to release the 1.0.0 version of YAQL. It is a
> > huge milestone: the language finally looks the way we initially wanted
> > it to look. The engine got completely rewritten, tons of new
> > capabilities have been added. Here is a brief (and incomplete) list of
> > new features and improvements:
> >
> > * Support for kwargs and keyword-only args (Py3)
> > * Optional function arguments
> > * Smart algorithm to find matching function overload without side effects
> > * Ability to organize functions into layers
> > * Configurable list of operators (left/right associative binary,
> > prefix/suffix unary with precedence)
> > * No global variables. There can be  more than one parser with
> > different set of operators simultaneously
> > * List literals ([a, b])
> > * Dictionary literals ({ a => b})
> > * Handling of escape characters in string literals
> > * Verbatim strings (`...`) and double-quotes ("...")
> > * =~ and !~ operators in default configuration (similar to Perl)
> > * -> operator to pass context
> > * Alternate operator names (for example '*equal' instead of
> '#operator_=')
> >  so that it will be possible to have different symbol for particular
> operator
> >  without breaking standard library that expects operator to have well
> > known names
> > * Set operations
> > * Support for lists and dictionaries as a dictionary keys and set
> elements
> > * New framework to decorate functions
> > * Ability to distinguish between functions and methods
> > * Switchable naming conventions
> > * Unicode support
> > * Execution options available to all invoked functions
> > * Iterators limitation
> > * Ability to limit memory consumption
> > * Can work with custom context classes
> > * It is possible to extend both parser and set of expression classes
> > on user-side
> > * It is possible to create user-defined types (also can be used for
> > dependency injection)
> > * Legacy yaql 0.2.x backward compatibility mode
> > * Comprehensive standard library of functions
> > * High unit test coverage
> > * Delegate and lambda support, including higher order lambdas
> >
> > etc, etc.
> >
> > So, this is a big change.
> >
> > And as it always happens when moving from 0.something to 1.x the
> > breaking changes are inevitable. We have included the "backwards
> > compatibility mode", but it may not address all the possible concerns.
> >
> > So.
> > We have released a release candidate 1 of yaql 1.0.0 on pypi: [1]
> > It includes all the new functionality and is likely to be identical to
> > final release (that's why it is RC after all) and we strongly
> > encourage all the yaql users (Murano and Mistral first of all) to try
> > it and prepare "migration patches" to use it. When the final release
> > is out, we'll update the global requirements to yaql >= 1.0.0, which
> > is likely to break all your gate checks unless you quickly land a
> > migrating patch.
> >
> > Please email us any concerns or contact me (ativelkov) or Stan Lagun
> > (slagun) directly in IRC (#murano) if you need some quick help on yaql
> > 1.0 or migrating from 0.2.x
> >
> > Happy yaqling!
> >
> >
> > [1] https://pypi.python.org/pypi/yaql/1.0.0.0rc1
> >
> >
> > --
> > Regards,
> > Alexander Tivelkov
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to