Thank you Stan!
On Aug 4, 2015, at 3:07 PM, Stan Lagun <sla...@mirantis.com> wrote:
> 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
>
>
> 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
__________________________________________________________________________
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
