Quantitative engineer working as Data Specialist at Facebook (Ireland) with 3+ years of experience.
Focused on growing as a data scientist. Very independent but great team mate, problem solving lover, research addict and passionate about predictive models and AI. Achievements include creating credit risk models, natural language processing and text classification projects, scraping, some web development and multiple end-to-end projects. Experienced in ETL, data science and web and software development. Passionate about programming, travelling and surfing.
Strategy and Risk Management consulting projects for top-tier European financial institutions.
Co-worked with researchers at the Coastal Dynamics lab within an international research program aimed at developing and calibrating a wave-current model to predict coastal phenomena.
Exploring some optimization techniques from Google's OR-Tools with real JUST EAT data
ViewMy aspirations are centered in growing as a data scientist / full stack engineer with a multidisciplinary knowledge, not only programatically but businesslike. I love solving problems and pushing myself to research and explore new ways of tackling challenges in an ever-changing environment.
I have taken lots of online courses to widen my knowledge (machine learning, deep learning, data visualization, web development, ...).
Apart from this, I enjoy most of my time being outdoors. In the winter, I don't think about it twice if there are waves and I can spend the day surfing. During the warmer months, I enjoy traveling and exploring the world.
When forced indoors, I am an aspiring chef, and I spend a large amount of my free time exploring the latest technolgy advancements in data science and artificial intelligence.


Guesses: 5
I'm thinking of a number between 1 and 30
Give it a go...
This is a guessing game in which the smug bug has thought of a number between 1 and 30, and your job is to guess it! You have only five guesses, so make them count! When you think of a guess, type it in the text box and hit submit. If you would like to start a new game, hit the New Game button below.
This is a simple guessing game, as many people have played before. This was the first game created for Smug Bug Arcade. It certainly helped get the format of the pages down right, as well as the systems for keeping track of statistics and such. The logic of the game is fairly simple, relying only on a random number generator and not much else. The code for manipulating the HTML and CSS far outnumbers the actual lines of game logic.
Wins: 0
Losses: 0
Win Percentage: 0%
Average Number of Guesses: 0


User Manual
Contents:
Creating a new entry
Altering the database
Searching the database
Importing and exporting
Miscellaneous operations


How tagging works
Tycho's IncrCanvas class manipulates canvas item tags in order to give the illusion of hierarchically-grouped items, and without the cost of implementing a truly recursive implementation. Although the idea is simple enough, the implementation -- especially when it comes to dealing with bindings and maintaining backwards compatibility with the Tk canvas -- is a little tricky. This section describes IncrCanvas' tagging mechanism.
Each complex item is assigned a unique ID by the IncrCanvas when it is created. The ID starts with an underscore to distinguish it from Tk canvas IDs (which are integers). Every simple item that is part of that complex item is tagged with that ID:
IncrCanvas rule 1: Every simple item contained in a complex item is tagged with the complex item's ID.Complex items can in general contain other complex items. Thus, the extension of the above rule is:
IncrCanvas corollary 1: Every simple item is tagged with the IDs of all complex items in the hierarchy above it.If we need to find the complex item containing a particular simple item, we usually want the root complex item of the tree in which that simple item lives. To make finding the root efficient, we give each item contained in a complex item a special tag:IncrCanvas rule 2 (simple): Every simple item contained in a complex item is tagged with the ID of its root prefixed by "!".A corollary of these rules identifies root simple items -- that is, simple items that are not contained in a complex item:
IncrCanvas corollary 2: A simple item that has no tag beginning with "!" is a root simple item.These rules are all that we need to move, find, and manipulate complex items. For example, to move a complex item, all we need to do is ask the canvas to move all items tagged with the complex item's ID -- a single call to the canvas; to find a complex item overlapping a given region of the canvas, we call the canvas' find method and then take the set of roots of the simple items returned, and the root simple items.
Some additional rules are needed to effectively deal with bindings. The issue of bindings to hierarchical items is not straightforward for two reasons: firstly, either item tagging or processing bindings is more complex, and secondly, the semantics of bindings on hierarchical items must be clearly defined first!
(As an example of the latter, suppose that A contains B, and both have a script bound to them.  But what about A's script? Should I execute that too? At first, the answer seems like yes: do whatever both items have asked for. But suppose the scripts move the items a certain amount: B will get moved twice! So then A has to somehow know that B will be moved and account for it -- but then we have to guarantee something about the order in which the scripts are executed. And so on...)
The approach we have taken is a reasonably efficient and reasonably straightforward compromise. We extend the notion of the root item to distinguish between actual and logical roots: a logical root is an item that is treated as a root even though it is not (necessarily). Only logical roots can be tagged or have scripts bound to them. There is a special method (
createroot
) for creating new logical roots. Rule 2 thus applies to logical roots as well as actual roots.This strategy enables finding and binding to items to be implemented with good efficiency using the Tk canvas' tag manipulation commands. Note that if the IncrCanvas is used in the same manner as the Tk canvas -- that is, creating only simple items and non-hierarchical complex items -- binding and tagging works exactly as on the Tk canvas and with little extra cost.
Now, a simple item can have only one root:
IncrCanvas rule 3: A simple item has at most one root, and therefore at most one tag beginning with "!".When we make a binding to a complex root item, we want only the simple items that have that complex item as root to respond to the binding. Therefore:IncrCanvas rule 4: To bind an event to a complex item, bind to the tag constructed by prefixing its ID with "!".Suppose, for example, that item A contains item B, and that A is a root and B is a logical root. Simple items in B are tagged with !B, and simple items in A but not in B are tagged with !A. If we bind event E to A, the event is in fact bound to the tag !A; if we bind event F to B, the event is in fact bound to the tag !B. Now, events on items in B will trigger only F; events on items in A which are not in B will trigger only E.Note that it is possible for tags to be attached to non-root -- this is because tags are often used to identify individual items, even if no events are bound to them. This will cause inconsistent behavior if events are bound to tags which are attached to non-root items.
Now, because bindings may be made to tags, we make the assignment of tags mirror the assignment of the root tag (!A for item A) to simple items. For example, suppose that A is tagged with "foo." If a binding is made to foo, we want only items tagged with !A to respond. Thus:
IncrCanvas rule 5: If a root item A is tagged with T, then all simple items with tag !A are tagged with T.Thus, binding event X to foo will cause items in A but not in B to respond to X. There are some minor consequences of rule 5:
- Because not all items under A are tagged with foo, it is not possible to move all items tagged foo with a single call to the canvas; instead, we must find the complex items and move them individually.
- Finding the bounding box of all items with a given tag may be incorrect if an item contains complex items that are (a) logical roots and (b) outside the bounding box of the other items so tagged. Since components should be inside the bounds of their container item, this shouldn't happen.
The implementation of most IncrCanvas methods based on these rules is reasonably straight-forward. Most of the methods test for three types of argument -- a simple item ID, a complex item ID, or a tag -- and act accordingly. This does makes the code rather verbose, but it's fairly simple to follow once you become familiar with the structural pattern of the methods. For example, a typical method has the pattern:
if { [string match {[0-9]*} $tag] } { # Process a canvas item ... } elseif { [string match {_*} $tag] } { # Process a complex item ... } else { # Process a tag: find matching items set items [find withtag $tag] ... }


Issue: WITH-ADDED-METHODS
References: 88-002R p.2-90
Category: CHANGE
Edit history: 29-Apr-90, Version 1 by Moon
4-May-90, Version 2 by Moon (update discussion)
Problem description:
WITH-ADDED-METHODS has a strange definition that is hard to understand
and apparently is not what was intended by the person who originally
proposed the feature. No CLOS implementation is known that supports it.
This is Symbolics issue #17.
Proposal (WITH-ADDED-METHODS:DELETE):
Remove WITH-ADDED-METHODS from the language and remove that symbol from
the COMMON-LISP package.
Rationale:
Why add something new that no one uses or wants?
Current practice:
No CLOS implementation is known to support WITH-ADDED-METHODS.
Cost to Implementors:
Trivial.
Cost to Users:
None.
Cost of non-adoption:
We would either have to get the implementors to implement it or explain
why we put this thing in the language that everyone refuses to implement.
Performance impact:
None.
Benefits:
Smaller language.
Esthetics:
Smaller language.
Discussion:
Gregor Kiczales says he supports WITH-ADDED-METHODS:DELETE.


{{ question.text }}
Raised by
{{ question.author_name }}
{{ question.created_at_pretty }}
{% if question.last_reply_pretty %}
|
Last reply:
{{ question.last_reply_pretty }}
{% endif %}


The priority of execution of the Behavior.
Called by the Emitter that the Behavior is attached to when it is added.
The Emitter that the Behavior is being attached to.
Called by the Emitter that the Behavior is attached to when it is removed.
The Emitter that the Behavior is being removed from.
Generated using TypeDoc
An Action is used to continously modify an aspect of a particle.


Upcoming Popup Meals
Noodles Party
Chicken and Mushroom Sauced Noodles With Thai Basil. Chewy noodles, umami-packed mushrooms, and garlicky chicken, all coated in a spicy, sweet, and savory sauce.
Waterloo, ON
21/08/2021
FAT night packup
Fajita Chicken Burrito Bowl is packed with juicy golden chicken, cilantro lime rice, avocado and a delicious dressing! Perfect for Meal Prep!
Kitchener, ON
22/08/2021


|
libjobs
|
Holds all overrided functions used for managing memory. More...
#include <jobs_memory.h>
Data Fields | |
| memory_alloc_function | user_alloc = nullptr |
| memory_free_function | user_free = nullptr |
Holds all overrided functions used for managing memory.
Definition at line 63 of file jobs_memory.h.
| memory_alloc_function jobs::memory_functions::user_alloc = nullptr |
Function to use for allocation of memory.
Definition at line 66 of file jobs_memory.h.
Referenced by jobs::internal::fiber::init(), jobs::internal::callback_scheduler::init(), jobs::scheduler::init(), jobs::internal::atomic_queue< size_t >::init(), and jobs::scheduler::scheduler().
| memory_free_function jobs::memory_functions::user_free = nullptr |
Function to use for deallocation of memory.
Definition at line 69 of file jobs_memory.h.
Referenced by jobs::internal::fiber::destroy(), jobs::scheduler::init(), jobs::scheduler::scheduler(), jobs::internal::callback_scheduler::~callback_scheduler(), and jobs::scheduler::~scheduler().


| Copyright: | 2008 Apple Inc. All rights reserved. |
|---|
AutoZone is a scanning, conservative, generational, multi-threaded garbage collector. Specifically, it is the garbage collector used by the Cocoa frameworks within Mac OS X Leopard and Xcode, the premiere development environment for Mac OS X and iPhone application development, is one of several garbage collected applications that shipped with Leopard.
Note
The implementation of the AutoZone (Mac OS X Objective-C Garbage Collector) will change significantly in Snow Leopard.
While AutoZone was tested and deployed with a focus on supporting Cocoa application development, the implementation is language agnostic. For example, the MacRuby project uses the AutoZone collector to provide fully automatic garbage collection of object graphs that span between Ruby and Objective-C!
The AutoZone collector is implemented in C++ and is designed to work in a runtime where some or most of the application's memory may be managed by mechanisms other than the collector. Object graphs may span between scanned and unscanned zones of memory. Facilities are included for maintaining a reference count of any given memory object.
AutoZone also offers support for weak references that are automatically nullified when the memory referred to by the weak reference no longer has strong references. For compiled languages, support for memory barriers can be integrated into the compiler such that normal assignments will update internal collector state.
The collector also includes statistics gathering and the ability to monitor the collector state from external processes. Thus, the collector can dump information about the object graph within an application at any time.
The collector specifically does not support resurrection and will warn when resurrection is detected.
Some high level details of the implementation follow. For specific details, see the source code.
The AutoZone collector actively scans memory, looking for references between objects in memory. The collector builds a graph of these objects and any objects that are not rooted -- not connected directly or indirectly to globals, the stack, or have been manually retained -- are automatically finalized and deallocated.
Unlike some garbage collectors, AutoZone does not move memory. As it is designed to work well within the C language and within runtimes that may be partially unscanned, the collector assumes that the address of a memory object may be meaningful.
In general, most objects within an application are short lived. Thus, the AutoZone collector uses a generational algorithm such that short-lived objects are scanned more frequently than older objects. By focusing on scanning the newer generation of objets more proactively, the collector can efficiently reap garbage -- no longer needed memory objects -- without incurring the cost of a full scan.
The AutoZone collector typically runs on its own background thread and will not block other threads of execution within an application. The collector will rarely block the execution of other threads and, when it does so, minimizes the amount of time that execution is stopped.


| Total net profit | -11.44 | Gross profit | 4.45 | Gross loss | -15.89 |
| Profit factor | 0.28 | Expected payoff | -0.29 | ||
| Absolute drawdown | -11.44 | Maximal drawdown (%) | 11.4 (-28500.0%) | ||
| Total trades | 40 | Profit trades (% of total) | 6 (15.0%) | Loss trades (% of total) | 34 (85.0%) |
| Long positions (won %) | 21 (14.29%) | Short positions (won %) | 19 (15.79%) | ||
| Largest | profit trade | 2.0 | loss trade | -0.8 | |
| Average | profit trade | 0.74 | loss trade | -0.47 | |
| Minimum | profit trade | 0.07 | loss trade | -0.04 | |
| Maximum | take profit in pips | 254.0 | stop loss in pips | -65.1 | |
| Average | take profit in pips | 73.2 | stop loss in pips | -39.8 | |
| Minimum | take profit in pips | -20.5 | stop loss in pips | -18.6 | |
| Maximum | Reward-Risk | 7.9 | Duration in minutes | 171 | |
| Average | Reward-Risk | 2.2 | Duration in minutes | 22.2 | |
| Minimum | Reward-Risk | 0.0 | Duration in minutes | 0 | |
| Maximum | consecutive wins (profit in money) | 2.0 (1.82) | consecutive losses (loss in money) | 11.0 (-4.61) | |
| Average | consecutive wins | 1.0 | consecutive losses | 6.0 |
| Total net profit | -9.34 | Gross profit | 0.63 | Gross loss | -9.97 |
| Profit factor | 0.06 | Expected payoff | -0.44 | ||
| Absolute drawdown | -9.34 | Maximal drawdown (%) | 8.68 (-1315.15%) | ||
| Total trades | 21 | Profit trades (% of total) | 3 (14.29%) | Loss trades (% of total) | 18 (85.71%) |
| Largest | profit trade | 0.38 | loss trade | -0.8 | |
| Average | profit trade | 0.21 | loss trade | -0.55 | |
| Minimum | profit trade | 0.07 | loss trade | -0.07 | |
| Maximum | take profit in pips | 254.0 | stop loss in pips | -64.9 | |
| Average | take profit in pips | 78.0 | stop loss in pips | -47.2 | |
| Minimum | take profit in pips | -20.5 | stop loss in pips | -32.0 | |
| Maximum | Reward-Risk | 5.3 | Duration in minutes | 171.0 | |
| Average | Reward-Risk | 1.8 | Duration in minutes | 29.5 | |
| Minimum | Reward-Risk | 0.0 | Duration in minutes | 4.0 | |
| Maximum | consecutive wins (profit in money) | 2.0 (0.56) | consecutive losses (loss in money) | 11.0 (-5.48) | |
| Average | consecutive wins | 1.0 | consecutive losses | 8.0 |
| Total net profit | -2.1 | Gross profit | 3.82 | Gross loss | -5.92 |
| Profit factor | 0.65 | Expected payoff | -0.11 | ||
| Absolute drawdown | -2.1 | Maximal drawdown (%) | 3.31 (273.55%) | ||
| Total trades | 19 | Profit trades (% of total) | 3 (15.79%) | Loss trades (% of total) | 16 (84.21%) |
| Largest | profit trade | 2.0 | loss trade | -0.63 | |
| Average | profit trade | 1.27 | loss trade | -0.37 | |
| Minimum | profit trade | 0.31 | loss trade | -0.04 | |
| Maximum | take profit in pips | 159.5 | stop loss in pips | -65.1 | |
| Average | take profit in pips | 67.9 | stop loss in pips | -31.7 | |
| Minimum | take profit in pips | -5.3 | stop loss in pips | -18.6 | |
| Maximum | Reward-Risk | 7.9 | Duration in minutes | 150.0 | |
| Average | Reward-Risk | 2.6 | Duration in minutes | 14.2 | |
| Minimum | Reward-Risk | Duration in minutes | 0.0 | ||
| Maximum | consecutive wins (profit in money) | 2.0 (1.82) | consecutive losses (loss in money) | 7.0 (-2.05) | |
| Average | consecutive wins | 1.0 | consecutive losses | 4.0 |


Components as managed by PicoContainer can have behaviors added to them by the container during instantiation.
Behaviors are deleivered by passing a BehaviorFactory reference into the PicoContainer instance on construction. For the most part BehaviorFactories are completely stateless.
This is where a component has a single instance in the container rather that a new one created each time the container is asked for that type. Guice calls this a Singleton. After guice came out we debated this, and decided that we should not call this a Singleton. Another PicoContainer instance could be manging another single instance of the same component, so it does not fit the definition of Singleton as defined in the Design Patterns book.
Choose your style for caching behavior:
pico = new DefaultPicoContainer(new Caching()); pico.addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
pico = new DefaultPicoContainer(); pico.as(CACHE).addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
pico = new PicoBuilder().withCaching().build(); pico.addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
pico = new PicoBuilder().withBehaviors(caching()).build(); pico.addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
This is where the implementation of the component is hidden from other components using it. The instance cannot be cast back to the implementation. It only works if the type has an interface that it implements.
pico = new DefaultPicoContainer(new ImplementationHiding()); pico.addComponent(Apple.class, AppleImpl.class); Apple a1 = pico.getComponent(Apple.class); // cannot cast back to AppleImpl
pico = new DefaultPicoContainer(); pico.as(HIDE).addComponent(Apple.class, AppleImpl.class); Apple a1 = pico.getComponent(Apple.class); // cannot cast back to AppleImpl
pico = new PicoBuilder().withImplementationHiding().build(); pico.addComponent(Apple.class, AppleImpl.class); Apple a1 = pico.getComponent(Apple.class); // cannot cast back to AppleImpl
pico = new PicoBuilder().withBehaviors(Behaviours.implementationHiding()).build(); pico.addComponent(Apple.class, AppleImpl.class); Apple a1 = pico.getComponent(Apple.class); // cannot cast back to AppleImpl
This Behavior leverages Reflection's dynamic proxy capability. There's another implementation hiding behavior in Pico Gems that leverages ASM to make 'more concrete' hidden implementations. AsmImplemenationHiding is the BehaviorFactory class.
When components are created by two threads concurrently, with the intention of the instance being cached, it is possible in a small percentage of cases for the first instance into the cache to be replaced with a second instance. To prevent this, you may want to try one of two behaviors to make the operation thread safe:
pico = new DefaultPicoContainer(new Synchronizing().wrap(new Caching())); pico.addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
pico = new DefaultPicoContainer(); pico.as(SYNCHRONIZE, CACHE).addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
pico = new PicoBuilder().withSynchronizing().withCaching().build(); pico.addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
pico = new PicoBuilder().withBehaviors(synchronizing(), caching()).build(); pico.addComponent(Apple.class); Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); // both the same instance
The second behavior leverages JDK 1.5's ReentrantLock functionality. To use that, replace SYNCHRONIZE with LOCK, or Syncronizing() with Locking(), withSynchronizing() with withLocking() and synchronizing() with locking() for above code fragments as appicable.
This is where there are a number of setters for a component that will be could be set after instantiation. A way of handing in some configuration if you like.
class Foo { String message; public void setMessage(String message) { this.message = message; } public String toString() { return message; } } ... pico = new DefaultPicoContainer(new PropertyApplying()); pico.addComponent(Foo.class); PropertyApplicator pa = (PropertyApplicator) pico.getAdapter(Foo.class); pa.setProperty("message", "hello"); System.out.println(pico.getComponent(Foo.class)); // prints hello
pico = new DefaultPicoContainer(); pico.as(APPLY_PROPERTIES).addComponent(Foo.class); PropertyApplicator pa = (PropertyApplicator) pico.getAdapter(Foo.class); pa.setProperty("message", "hello"); System.out.println(pico.getComponent(Foo.class)); // prints hello
pico = new PicoBuilder().withProperties().build(); pico.addComponent(Foo.class); PropertyApplicator pa = (PropertyApplicator) pico.getAdapter(Foo.class); pa.setProperty("message", "hello"); System.out.println(pico.getComponent(Foo.class)); // prints hello
pico = new PicoBuilder().withBehaviors(propertyApplying()).build(); pico.addComponent(Foo.class); PropertyApplicator pa = (PropertyApplicator) pico.getAdapter(Foo.class); pa.setProperty("message", "hello"); System.out.println(pico.getComponent(Foo.class)); // prints hello
pico = new PicoBuilder().withBehaviors(caching(), propertyApplying()).build(); pico.addComponent(Foo.class); Cached cached = (Cached) pico.getAdapter(Foo.class); PropertyApplicator pa = (PropertyApplicator) getDelegate(PropertyApplicator.class); pa.setProperty("message", "hello"); System.out.println(pico.getComponent(Foo.class)); // prints hello
This is where a component is going to be instantiated regardless of whether:
It is most likely that you're doing this because the component in question is self contained and doing something once only. Alternatively, you're cutting a legacy codebase over from nest-of-singletons to dependency injection in stages.
class Foo { public Foo() { System.out.println("Foo was instantiated"); } } ... pico = new DefaultPicoContainer(new Automatic()); pico.addComponent(Foo.class); pico.addComponent("bar", String.class); pico.getComponent("bar"); // Foo instantiated too.
pico = new DefaultPicoContainer(); pico.as(AUTOMATIC).addComponent(Foo.class); pico.addComponent("bar", String.class); pico.getComponent("bar"); // Foo instantiated too.
pico = new PicoBuilder().withAutomatic().build(); pico.addComponent(Foo.class); pico.addComponent("bar", String.class); pico.getComponent("bar"); // Foo instantiated too.
pico = new PicoBuilder().withBehaviors(automatic()).build(); pico.addComponent(Foo.class); pico.addComponent("bar", String.class); pico.getComponent("bar"); // Foo instantiated too.
This is where a component has a single instance in the container rather that a new one created each time the container is asked for that type. The difference to 'Caching' is that there is one cache per thread using the container. For the most part you are not going to use this behavior unless you are 100% sure that the muti-threaded application you are writing maps threads to the notional session you are trying to model.
Choose your style for thread caching behavior:
pico = new DefaultPicoContainer(new ThreadCaching()); pico.addComponent(Apple.class); new Thread() { public void run() { Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); } }).start(); new Thread() { public void run() { Apple a3 = pico.getComponent(Apple.class); } }).start(); // a1 and a2 are the same instance // a1 and a3 are different instances
pico = new DefaultPicoContainer(); pico.as(THREAD_CACHE).addComponent(Apple.class);
pico = new PicoBuilder().withThreadCaching().build(); pico.addComponent(Apple.class);
pico = new PicoBuilder().withBehaviors(threadCaching()).build(); pico.addComponent(Apple.class);
This is where a component has a single instance in the container rather that a new one created each time the container is asked for that type. This is like 'ThreadCaching' as it has the one cache per thread behavior, but the whole store is can be extracted and set outside if you have a referene to the Storing instance. Again you are likely to use this behavior if you are trying to model 'session' behavior. With this one though you able to retrieve the cache from some place associated with the session and set it for the thread before use. After use, it can be extracted and stored back with the sesion.
Only one style is shown here as you will need to hang on to the reference to the BehaviorFactory to make use of it:
pico = new DefaultPicoContainer(new Storing()); pico.addComponent(Apple.class); new Thread() { public void run() { Apple a1 = pico.getComponent(Apple.class); Apple a2 = pico.getComponent(Apple.class); } }).start(); new Thread() { public void run() { Apple a3 = pico.getComponent(Apple.class); } }).start(); // a1 and a2 are the same instance // a1 and a3 are different instances
The BehaviorFactory for Storing behavior is not stateless. It allows the cache to be set for the thread as well as extracted. Here's a code snippet to illustrate that:
storing = new Storing(); pico = new DefaultPicoContainer(sc); .... storing.putCacheForThread(httpRequest.getSession().getAttribute("sessionComponentStore"); // do other methods that process request in session concept and may do getComponent(..) from the sesion container. httpRequest.getSession().setAttribute("sessionComponentStore", sc.getCacheForThread());
See scopes for another example for a web framework
This is a rudimentary Aspect Orientated Programing (AOP) capability. With respect to the methods of a component, both before and after invocation, control can be handed to an interceptor. You can intercept a method call:
There are some limitations:
public static class BiteReporter implements Apple { private Intercepted.Controller controller; public BiteReporter(Intercepted.Controller controller) { this.controller = controller; } public boolean takeBite(int grams) { System.out.println("Bite of " + grams + " grams of apple '" + controller.instance().getName() + "'"); return false; // ignored, but necessary. } } ... pico = new DefaultPicoContainer(new Interception()); pico.addComponent(Apple.class, BraeburnApple.class); Intercpeted intercepted = pico.getComponentAdapter(Apple.class).findAdapterOfType(Intercpeted.class); intercepted.pre(Apple.class, new BiteReporter(intercepted.getController())); // see also Intercpeted.post(...) method. Apple a1 = pico.getComponent(Apple.class); a1.takeBite(100); // prints Bite of 100 grams of apple 'Braeburn' // ... irrespective of what else Braeburn.takeBite(int) does.
pico = new DefaultPicoContainer(); pico.as(INTERCEPT).addComponent(Apple.class, BraeburnApple.class); // etc
pico = new PicoBuilder.withInterception().build(); pico.addComponent(Apple.class, BraeburnApple.class); // etc
pico = new PicoBuilder.withBehaviors(interception()).build(); pico.addComponent(Apple.class, BraeburnApple.class); // etc
Fine grained participation in interception
Assuming you're passing in the Interceptor to the classes you're using for interception of a component, you can
participate in the fate of the method call. For a 'pre' invocation, you can veto the calling of the 'real'
method.
public boolean takeBite(int grams) { if (grams > 50) { controller.veto(); } return false; // will be passed back to the caller. }
For a 'post' invocation, you can override the return value of the 'real' method.
public boolean takeBite(int grams) { if (grams > 50) { controller.override(); (Apple) realApple = (Apple) controller.instance(); realApple.takeBite(-1 * grams); // undo ! } return false; // will be passed back to the caller. }
Also for a 'post' invocation, you can access the return value of the 'real' method.
public boolean takeBite(int grams) { boolean rv = (boolean) controller.getOriginalRetVal(); if (rv == false) { // do something ! } return true; // ignored as no 'override' }


About me
“My name is Zhou Shuofeng. I am 24 years old and born in Beijing, China. Graduated from Changsha University of Science and Technology and now studying in Japan, I want to enrich my knowledge.”
My Country
Beijing is a beautiful city. There are many famous foods here, such as Peking duck, candied haws and so on. Beijing is also the capital of China, with 21.54 million people living here. At the same time, there are many people who come here to travel, to the Forbidden City, the Old Summer Palace and so on.
My School
My school is a very good school (Kyoto University of Information Science and Technology). It focuses on cultivating computer talents and has many excellent teachers. I have gained a lot from studying here.。
My Hobby
I like sports, playing games, and watching anime. My favorite game in the game is a game called DOTA2. If you also play, I would love to play with you. In terms of sports, I like to play badminton. It can help me exercise and make me enjoy the joy of sports. I like watching anime, which is one of the reasons why I came to Japan. My favorite anime is Naruto.


Do you confirm the complete UPDATE / RESET of your application cache ?
This may freeze access to the server for a while, and may cause errors if some processes are running during the update process.
Please do not confirm if you don't know what you are doing.


|
|
|
| If the Match Bans link is coloured red you must click on it to get an accurate picture. | |
| It is my understanding
that, as of season 2011-2012, all adult leagues have to be able to suspend
their players on a "number of matches" basis (as well as "number
of days").
I have added a new link, Match Bans, which will report on the status of all such player suspensions. This will display all the games that contribute to the number of matches for which a player is suspended. Only by clicking on the Match Bans link will the latest situation be displayed. When the correct number of games have been played to a result then the suspension will have been completed. The system automatically identifies all these games and automatically clears the suspension. A ban will not be reduced by a postponed, awarded, abandoned or void match. These games will be displayed but will not count. However, if a game was played but then later awarded because of, say, an ineligible player, then the game will count. |
Certain competitions
will not count towards the reduction, e.g. charity or testimonial matches.
These can be identified by using the Constitution link. If a club
enters several County Cup competitions then there may be "extra"
cups that don't count. Again, use the Constitution link to identify
these situations.
Match bans are normally applied a fixed number of days after the triggering event (e.g. red card or five yellow cards). It is possible that during this period there may be one or more additional triggering events. Match bans may therefore overlap. The system correctly identifies these situations so that concurrent or overlapping bans are made consecutive. Double-Headers count as two matches. A player may appear for the first team, reserve team and the 'A' team. If the suspension was triggered by an event while playing for the first team then it will be first team games that are counted, if the suspension was triggered by an event while playing for the reserve team then it will be reserve team games that are counted etc. When adding a suspension you must identify the team; first, reserve, 'A' etc. Regardless of team, the rules applying to concurrent or overlapping bans still apply. |
|
If you find any problems with the new Match Ban Suspensions or want to
discuss anything regarding this specification then please contact us. |


axis(3f) - [M_calcomp:basic] draw linear axis with numeric scale and axis label (LICENSE:PD)
Synopsis
Description
Options
Examples
License
subroutine axis(xpage,ypage,ibcd,+-nchar,axlen,angle,firstv,deltav)
Draws a linear axis with numeric scale and axis label.
Important: Axis labels can be 0.4 inches lower than or to the left of the axis origin (XPAGE,YPAGE). Since lines drawn whose value is negative relative to the frames ORIGINAL origin will be clipped, XPAGE and YPAGE must be greater than 0.4 or a new origin must be specified at least 0.4 units up and to the right from the original using PLOT(0.4,.4,-3) when (XPAGE,YPAGE) is (0.0,0.0).
Most graphs require axis lines and scales to indicate the orientation and values of the plotted data points. The most common type of scaled axis is produced by the AXIS subroutine which draws any length line at any angle, divides the line into one-inch segments, annotates the divisions with appropriate scale values and labels the axis with a centered title. When both the X and Y axes are needed, AXIS is called separately for each one.
XPAGE,YPAGE are the coordinates, in inches, of the axis lines starting point. The entire line should be at least one-half inch from any side to allow space for the scale annotation and axis title. Usually, both the X and Y axes are joined at the origin of the graph, where XPAGE and YPAGE equal zero, but other starting points can be used. When using the LINE subroutine to plot data on an axis, at least one of the coordinates must be 0, i.e., for an X axis, XPAGE=0, and for a Y axis, YPAGE=0 . IBCD is the title, which is centered and placed parallel to the axis line. This parameter may be a character array or single variable. (The data should be stored as TYPE CHARACTER.) The characters have a fixed height of 0.14 inch (about seven characters per inch). +-NCHAR The magnitude specifies the number of characters in the axis title, and the sign determines on which side of the line the scale (tick) marks and labeling information shall be placed. Since the axis line may be drawn at any angle, the line itself is used as a reference. If the sign is positive, all annotation appears on the positive (counterclockwise) side of the axis. This condition is normally desired for the Y axis.
If the sign is negative, all annotation appears on the negative (clockwise) side of the axis. This condition is normally desired for the X axis.
AXLEN is the length of the axis line, in inches. ANGLE is the angle in degrees (positive or negative), at which the axis is drawn. The value is 0 degrees for the X-axis and 90 degrees for the Y-axis. FIRSTV is the starting value (either minimum or maximum) which will appear at the first tick mark on the axis. This value may either be computed by the SCALE subroutine and stored at subscripted location ARRAY(NPTS*INC+1), or the value may be determined by the user and stored at any location. This number and scale value along the axis is drawn with two decimal places. Since the digit size is 0.105 inch (about 10 characters per inch), and since a scale value appears every inch, no more than six digits and a sign should appear to the left of the decimal point.
DELTAV represents the number of data units per inch of axis. This value (increment or decrement), which is added to FIRSTV for each succeeding one-inch division along the axis, may either be computed by SCALE and stored beyond FIRSTV at ARRAY(NPTS*INC+INC+1), or the value may be determined by the user and stored at any location. In order to use a standard format of two decimal places, the size of DELTAV is adjusted to less than 100, but not less than 0.01. As a result, the decimal point may be shifted left or right in the scale values as drawn, and the axis title is then followed by "*10**n", where n is the power-of-ten adjustment factor. (See X-axis example in Figure _____.)
 PLOT THREE GRAPHS ILLUSTRATING SCALE, AXIS, AND LINE deltax=0.04 i=2 ! AXIS DRAWS LABELS AS MUCH AS 0.4 INCHES TO THE NEGATIVE OF AXIS CENTER; ! EITHER USE AN ORIGIN OFFSET OF AT LEAST THIS VALUE OR DO NOT USE AN !


Before Change
filter_vals = utils.to_collection(filter_vals, vals_type, set)
if valid_vals is not None:
if not all(filter_val in valid_vals for filter_val in filter_vals):
raise ValueError(
"not all values in filter are valid: {}".format(
filter_vals.difference(valid_vals)
After Change
def validate_set_member_filter(filter_vals, vals_type, valid_vals=None):
utils.deprecated(
"This function has been moved to `textacy.utils.validate_set_members()` "
"and is aliased here only for backwards compatibility. "
"This alias will be removed in v0.10.0.",
action="once",
)
return utils.validate_set_members(filter_vals, vals_type, valid_vals=valid_vals)
def validate_and_clip_range_filter(filter_range, full_range, val_type=None):


--- layout: post title: Stamitz Viola Concerto in D major Op.1 Mo.1 subtitle: Stanford Application Supplement tags: [solo] ---


public class CharacteristicVector
extends java.lang.Object
| Constructor | Description |
|---|---|
CharacteristicVector(int tg,
int tm,
double D,
int label,
boolean status,
double dl,
double dm) |
| Modifier and Type | Method | Description |
|---|---|---|
void |
densityWithNew(int currTime,
double decayFactor) |
Implements the density update function given in
eq 5 (Proposition 3.1) of Chen and Tu 2007.
|
int |
getAttribute() |
|
double |
getCurrGridDensity(int currTime,
double decayFactor) |
|
int |
getDensityTimeStamp() |
|
double |
getGridDensity() |
|
int |
getLabel() |
|
int |
getRemoveTime() |
|
int |
getUpdateTime() |
|
boolean |
isAttChanged() |
|
boolean |
isDense(double dm) |
Implements the test for whether a density grid is dense given
in eq 8 of Chen and Tu 2007.
|
boolean |
isSparse(double dl) |
Implements the test for whether a density grid is sparse given
in eq 9 of Chen and Tu 2007.
|
boolean |
isSporadic() |
|
boolean |
isTransitional(double dm,
double dl) |
Implements the test for whether a density grid is transitional
given in eq 10 of Chen and Tu 2007.
|
void |
setDensityTimeStamp(int densityTimeStamp) |
|
void |
setGridDensity(double gridDensity,
int timeStamp) |
|
void |
setLabel(int newLabel) |
|
void |
setRemoveTime(int removeTime) |
|
void |
setSporadic(boolean isSporadic) |
|
void |
setUpdateTime(int updateTime) |
|
java.lang.String |
toString() |
Overrides Object's toString method.
|
void |
updateGridDensity(int currTime,
double decayFactor,
double dl,
double dm) |
Implements the update the density of all grids step given at line 2 of
both Fig 3 and Fig 4 of Chen and Tu 2007.
|
public CharacteristicVector(int tg, int tm, double D, int label, boolean status, double dl, double dm)
tg
- - the last time when g is updatedtm
- - the last time when g is removed from grid_listD
- - the grid density at the last updatelabel
- - the class label of the gridstatus
- - SPORADIC (true) or NORMAL (false)public int getUpdateTime()
public void setUpdateTime(int updateTime)
updateTime
- the time at which the grid was updatedpublic int getRemoveTime()
public void setRemoveTime(int removeTime)
removeTime
- the time at which the grid was removed from grid_listpublic double getGridDensity()
public double getCurrGridDensity(int currTime, double decayFactor)
currTime
- - the current time to calculate the density fordecayFactor
- - the decay factor, lambda, of the algorithmpublic void setGridDensity(double gridDensity, int timeStamp)
gridDensity
- the density of the gridtimeStamp
- the time at which the gridDensity is being updatedpublic int getLabel()
public void setLabel(int newLabel)
newLabel
- the label of the cluster to assign the grid topublic boolean isSporadic()
public void setSporadic(boolean isSporadic)
isSporadic
- TRUE if the characteristic vector is to be labelled as sporadic,
FALSE otherwisepublic int getDensityTimeStamp()
public void setDensityTimeStamp(int densityTimeStamp)
public void densityWithNew(int currTime, double decayFactor)
currTime
- the data stream's current internal timedecayFactor
- the value of lambdapublic void updateGridDensity(int currTime, double decayFactor, double dl, double dm)
currTime
- the data stream's current internal timedecayFactor
- the value of lambdadl
- the threshold for sparse gridsdm
- the threshold for dense gridspublic boolean isDense(double dm)
dm
- the threshold for dense gridspublic boolean isSparse(double dl)
dl
- the threshold for sparse gridspublic boolean isTransitional(double dm, double dl)
dm
- the threshold for dense gridsdl
- the threshold for sparse gridspublic int getAttribute()
public boolean isAttChanged()
public java.lang.String toString()
toString
in class java.lang.Object
Copyright © 2020 University of Waikato, Hamilton, NZ. All Rights Reserved.


from pyDiamonds import Model
import numpy as np
from numpy import ndarray
[docs]class BackgroundModel(Model):
"""
The Background model is an abstract class, that provides the necessary methods to compute a bayesian analysis with
PyDIAMONDS. It inherits multiple methods already from the Model class from PyDIAMONDS, naming the predict method and
it provides said Models class with the covariates, the frequential axis of the data.
"""
def __init__(self, covariates: ndarray, dimension: int, name: str, fileAppendix: str = ""):
"""
The constructor of the class sets up the class. It sets the names, dimensions, as well as the fileAppendix.
The Nyquist frequency must be set at a later point in using the code using the property for the Nyquist
frequency.
:param covariates: The frequential axis of the dataset.
:type covariates: ndarray
:param dimension: The dimension of the priors. Will be used for a check within Background to check the length of
the priors
:type dimension: int
:param name: The name of the model.
:type name: str
:param fileAppendix: The appendix for the filename, used for the priors (i.e. hyperparameters*fileAppendix*.txt
:type fileAppendix: str
"""
covariates = covariates.astype(float)
Model.__init__(self,covariates)
self._dimension = dimension
self._name = name
self._fileAppendix = fileAppendix
self._nyquistFrequency = None
self._responseFunction = None
pass
[docs] def getResponseFunction(self):
"""
:return: The response function. Multiplied with the prediction to create an initial sampling
:rtype: ndarray
"""
if self._responseFunction is None:
raise ValueError("Nyquist frequency must be set!")
return self._responseFunction
[docs] def getNyquistFrequency(self):
"""
:return: The Nyquist frequency. Must have been set previously using the setter property.
:rtype: float
"""
return self._nyquistFrequency
[docs] def readNyquistFrequencyFromFile(self, fileName: str):
"""
Reads the Nyquist frequency from a file and sets it as the used Nyquist frequency
:param: fileName: Name of the file containing the nyquist frequency. Must contain only one item!
:type: fileName: str
"""
self._nyquistFrequency = np.loadtxt(fileName).T
@property
def nyquistFrequency(self):
"""
Property of the Nyquist frequency. Raises a ValueError if the Nyquist frequency was not set previously.
:return: The Nyquist frequency
:rtype: float
"""
if self._nyquistFrequency is None:
raise ValueError("Nyquist frequency must be set before accessing it!")
return self._nyquistFrequency
@nyquistFrequency.setter
def nyquistFrequency(self, value: float):
"""
Setter property for the Nyquist frequency. Also triggers the calculation of the response Function
:param: value: Value for the Nyquist frequency.
:type: value: float
"""
self._nyquistFrequency = value
self._calculateResponseFunction()
[docs] def predict(self, predictions: ndarray, modelParameters: ndarray):
"""
Predict method, called by PyDIAMONDS to sample an initial value set. Must be implemented in the class
derived from this class. Here one can calculate the model using the modelParameters as an input from DIAMONDS.
Must return the predictions after finishing the calculation.
:param predictions: The predictions for the dataset
:type predictions: ndarray
:param modelParameters: The parameters for the model, representing the priors. Determined by PyDIAMONDS
:type modelParameters: ndarray
:return: The predictions for the dataset using the covariates.
:rtype: ndarray
"""
raise NotImplementedError("You need to implement predict if you derive from BackgroundModel")
@property
def dimension(self):
"""
Property for the dimensions of the priors
:return: Size of Priors
:rtype: int
"""
return self._dimension
@property
def name(self):
"""
Property for the name of the model
:return: Name of the model
:rtype: str
"""
return self._name
@property
def fileAppendix(self):
"""
Property for the fileAppendix. Used in Background.
:return: Text for the fileAppendix
:rtype: str
"""
return self._fileAppendix
def _calculateResponseFunction(self):
"""
This method calculates the response function, used for the first sampling of the dataset. Backgroundmodel
implements a default implementation, but this could be different for different applications.
:return: The response function using the covariates
:rtype: ndarray
"""
try:
sincFunctionArgument = np.pi * self._covariates / (2 * self._nyquistFrequency)
self._responseFunction = (np.sin(sincFunctionArgument) / sincFunctionArgument) ** 2
except:
raise ValueError("Nyquist frequency was not set before calculating response Function. Set the Nyquist "
"frequency before performing analysis")


All about me
Here are some basics about who I am so that you can better get to know me
General Information
Name - Max Wolff
Age - 23
Height - 6'0 on a good day, otherwise 5'11
Weight - No idea, maybe like 145lbs, don't quote me on that.
Interests
- Sports. I like baseball, football, hockey, and basketball
- Music. I listen to a lot of different stuff, but my favorite genere is probably heavy metal.
- Video games. I've been playing games as long as I can remeber, my favorite game is probably Skyrim.
Education Summary
- Graduated from Newport High School in 2012
- Attended Western Washington University from 2012 to 2015
- Took some time off ...
- Started attending Code Fellows in August of 2017 to learn programing
Work Experience
- Worked part time as a general laborer for WMS Construction and Mason and Mason Intereiors
- From 2015 to 2017 worked as deli clerk and then assitant deli manager for Safeway
- That's it so far, hopefully this next bullet point will be about my future job as a coder!
My top 10 favorite bands
- Iron Maiden
- Streetlight Manifesto
- Metallica
- The Beatles
- Slayer
- Rush
- Daft Punk
- Avenged Sevonfold
- System of a Down
- Thin Lizzy


Copyright � 2005 W3C� (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document describes possible strategies for tokenizing the [XML Path Language (XPath) 2.0] and [XQuery 1.0: An XML Query Language] languages, and is provided as a helpful guide to those who are designing an implementation for these languages, and as background material for the normative EBNF found in the language specifications. In the future this document may be expanded to cover more general parsing strategies.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a public W3C Working Draft for review by W3C Members and other interested parties. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
Building a Tokenizer for XPath or XQuery has been defined through the efforts of a joint task force of the XML Query Working Group and the XSL Working Group (both part of the XML Activity). It is designed to be read in conjunction with the following documents: [XML Path Language (XPath) 2.0] and [XQuery 1.0: An XML Query Language].
This is the first public Working Draft of these guidelines. Public comments on this document are invited. Comments should be entered into the last-call issue tracking system for this specification (instructions can be found at http://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is not feasible, you may send your comments to the W3C XPath/XQuery mailing list<EMAIL_ADDRESS>(archived at http://lists.w3.org/Archives/Public/public-qt-comments/), with “[Parsing]” at the beginning of the subject field.
As of this publication, the Working Group expects to eventually publish this document as a Working Group Note. It is not expected to become a W3C Recommendation, and therefore it has no associated W3C Patent Policy licensing obligations. If this expectation changes, the Working Group will have an opportunity to fulfill the associated patent policy requirements with respect to a future draft.
1 Introduction
1.1 Structure of Parsers
1.2 Lexical Scanning Strategies
1.2.1 Token Granularity
1.3 Parser Strategies
2 Lexical Processing
2.1 Lexical States
2.1.1 XQuery Lexical States
2.1.2 XPath Lexical States
A XPath/XQuery Grammar
A.1 EBNF
A.1.1 XPath EBNF
A.1.2 XQuery EBNF
B References
B.1 Main References
C Glossary (Non-Normative)
The XQuery language is, for the most part, a super-set of the smaller XPath language [1]. XPath is designed to be a simple addressing and expression language, while XQuery includes prologue declarations, function, variable, and extension declarations, XML element construction, and advanced iteration constructs. These languages do not contain reserved keywords, which is to say data references in the form of QNames are designed to
never overlap with keywords in the language. In order to achieve the combination of expression language, directory-style addressing, prologue declarations, type matching, and XML element construction, the meaning of the tokens are extremely context dependent. For instance, the string div
may be an element reference, or may be a division operator. Likewise, the *
might be a wildcard element reference, may be a multiplication operator, or may be a kleene operator.
As illustration, the following is a very unlikely, but legal, XQuery example:
declare namespace namespace = "http://example.com"; declare union <union>for gibberish { for $for in for return <for>***div div</for> }</union>, if(if) then then else else- +-++-**-* instance of element(*)* * * **---++div- div -div
XPath and XQuery parsers may be either top-down or bottom-up. Traditionally, the parsing process is decomposed into subcomponents:
[Definition: Lexical scanner, which assigns symbols known as tokens to units in the input, in essence recognizing the basic words and punctuation of the language. Typically, the lexer uses regular expressions as a specification for how to do this tokenization. The rules that govern the lexical structure of the language, sometimes known as microsyntax, should be simple, regular, and as context-free as possible.]
[Definition: Parser, which arranges the tokens into a hierarchical structure. Typically, the parser uses a BNF or variant description (EBNF in the case of XPath/XQuery) as a specification for this parsing.]
Since the tokenization of XPath/XQuery is so context dependent, this breakdown may not be as simple as with other programming languages. Furthermore, the granularity of tokenization is an issue.
We can speculate on an enumeration of some strategies for implementing a lexical scanner as follows:
[Definition: Scan-while-parse scanner. Using this strategy, the parser would evaluate the character stream into tokens, while at the same time branching to the respective hierarchical context. Thus the words can be discovered in context. Complex parsers are typically not built in this fashion, but, given the issue of context sensitivity, this may be a reasonable approach. This would probably be implemented as a hand-constructed recursive-descent parser. ]
[Definition: Fuzzy token scanner. Using this strategy, a typical simple lexical scanner is implemented, but the meaning of the tokens are often left somewhat ambiguous. Thus, the word div
might be assigned the symbol QNameOrKeyword. The words can be disambiguated during the context sensitive parse process. This approach would probably be a hand-constructed, Top-down parser.]
[Definition: Two-pass scanner. This is the same as the Fuzzy token scanner, but the ambiguous words can be disambiguated by a second scan, using some rules (probably expressed as a context-free grammar) that reflect the basic structure of the EBNF (call this the three-pass approach). The three-pass approach could conceivably be implemented via a parser constructor program, with the addition of a custom disambiguator in between the lexer and parser. This method could be used for either Top-down or Bottom-up techniques.]
[Definition: State-driven scanner. This approach recognizes sets of words only in certain states, each word or punctuation possibly transitioning to a next state. In other words, it implements lexical recognition as transition tables for a push-down automata.]
In XPath/XQuery, the meaning of a word may often be determined by the words and punctuation ahead of it. Thus, the word if
is only the "if" keyword if it is followed by a left-parenthesis (ignoring whitespace). Likewise, the word declare
may be a QName, or may be part of a NamespaceDecl in the prolog, if followed by a namespace
word. Inversely, namespace
is determined to be a keyword verses a QName by it's appearance after declare
. In the
XQuery and XPath specifications, in the EBNF appendix, the notation "< ... >" is used to indicate a grouping of terminals that together may help disambiguate the individual symbols.
A scanner might take one of two approaches for assigning token units to the character stream:
[Definition: Short tokens. Using this approach, declare namespace
would be considered two tokens, the exact symbols assigned based on lexical look-ahead (and look-behind).] In this case, a parser that has at least a look-ahead of two tokens is required (in particular, a two-token look-ahead should be sufficient for a LALR parser).
[Definition: Long tokens. Using this approach, declare namespace
would be considered a single token.] In this case, a parser that has a look-ahead of only one token can be implemented.
The general strategies for implementing the parser are as follows:
Recursive-descent parser. For our purposes, this term means a hand-constructed, recursive descent parser.
[Definition: LL Parser (Left to right, Leftmost derivation, hence LL). ] The XPath/XQuery EBNF is expressed as an LL(1) grammar, so an LL parser can use the EBNF from the specifications fairly directly.
[Definition: LALR Parser (Look Ahead Left to right, Rightmost derivation, hence LALR). ] The XPath/XQuery EBNF is expressed as an LL(1) grammar, so an LALR parser must use what is essentially an inverted form of the original EBNF.
Many lexical scanner generators will allow specifications of tokens that are recognized based on some condition. It is possible to condition the XQuery and XPath token recognition in a lexical scanner in terms of a series of states and transitions between those states.
[Definition: A lexical state is a condition where a defined set of patterns are recognized.] The tables below define the complete lexical rules for [XPath/XQuery]. Each two column table corresponds to a lexical state and lists in the first column the tokens that are recognized when in that state. Any token not listed should result in a syntax error when in that state. When a given token is recognized in the given state, the transition to the next state and/or a lexical action is given in the right column. [Definition: A lexical action is an action that occurs as an side-effect of a pattern recognition.] Following are a list of lexical actions used in the tables:
The current state, before the transition, is pushed onto an abstract stack.
A STATE parameter is pushed onto an abstract stack.
The most recently pushed state is removed from the top of the stack, and becomes the current state.
This is a special action that backs up the character stream by n characters. See the description of the OCCURRENCEINDICATOR state for more information.
This simply means that the current state is maintained with no modification.
The lexical states have, in many cases, close connection to the parser productions. However, just because a token is recognized in a certain lexical state, does not mean it will be legal in the current EBNF production.
The XQuery EBNF has some places where whitespace has explicit specification, which is to say, whitespace is not ignored in these states: START_TAG, END_TAG, ELEMENT_CONTENT, XML_COMMENT, PROCESSING_INSTRUCTION, PROCESSING_INSTRUCTION_CONTENT, CDATA_SECTION, QUOT_ATTRIBUTE_CONTENT, and APOS_ATTRIBUTE_CONTENT.
| Editorial note | |
| The following tables were hand-constructed and have not, at the time of this writing, been exhaustively verified against all possible paths that may be legal in the XQuery and XPath EBNFs, which is to say, it is possible they contain bugs. |
This state is for patterns that occur at the beginning of an expression or subexpression.
| Pattern | Transition To State | ||
|---|---|---|---|
| DecimalLiteral, "..", ".", DoubleLiteral, IntegerLiteral, NotNumber, <NCName ":" "*">, QName, ")", <"*" ":" NCName>, "*", StringLiteral, <"declare" "construction">, <"declare" "default" "order"> |
|
||
| <"declare" "default" "collation">, <"declare" "namespace">, <"module" "namespace">, <"declare" "base-uri"> |
|
||
| <"declare" "default" "element">, <"declare" "default" "function">, <"import" "schema">, <"import" "module">, <"declare" "copy-namespaces"> |
|
||
| "$", <"for" "$">, <"let" "$">, <"some" "$">, <"every" "$"> |
|
||
| <"declare" "variable" "$"> |
|
||
| <")" "as"> |
|
||
| <"element" "(">, <"attribute" "(">, <"schema-element" "(">, <"schema-attribute" "(">, <"comment" "(">, <"text" "(">, <"node" "(">, <"document-node" "("> |
|
||
| <"processing-instruction" "("> |
|
||
| "<!--" |
|
||
| "<?" |
|
||
| "<![CDATA[" |
|
||
| "<" |
|
||
| <"declare" "boundary-space"> |
|
||
| "}" |
|
||
| <"validate" "{">, <"validate" ValidationMode> |
|
||
| <"typeswitch" "("> |
|
||
| <"element" "{">, <"attribute" "{"> |
|
||
| <"attribute" QName "{">, <"element" QName "{">, <"document" "{">, <"text" "{">, <"processing-instruction" "{">, <"processing-instruction" NCName "{">, <"comment" "{"> |
|
||
| <"declare" "function"> |
|
||
| "(:" |
|
||
| "{", <"ordered" "{">, <"unordered" "{"> |
|
||
| <"declare" "ordering"> |
|
||
| <"xquery" "version"> |
|
||
| "(#" |
|
||
| <"declare" "option"> |
|
||
| <"at" URILiteral> |
|
||
| ";", ",", "(", <QName "(">, <"if" "(">, "-", "+", "//", "/", <"ancestor-or-self" "::">, <"ancestor" "::">, <"attribute" "::">, <"child" "::">, <"descendant-or-self" "::">, <"descendant" "::">, <"following-sibling" "::">, <"following" "::">, <"parent" "::">, <"preceding-sibling" "::">, <"preceding" "::">, <"self" "::">, "@" |
|
Special state to recognize declare ordering specific keywords.
| Pattern | Transition To State | |
|---|---|---|
| "ordered", "unordered" |
|
This state is for patterns that are defined for operators.
| Pattern | Transition To State | ||
|---|---|---|---|
| "{" |
|
||
| ";", "then", "else", "external", "and", "at", ":=", ",", "div", "=", "except", "eq", "ge", "gt", "le", "lt", "ne", ">=", ">>", ">", "idiv", "intersect", "in", "is", "[", "<=", "<<", "<", "-", "mod", "*", "!=", <"order" "by">, <"stable" "order" "by">, "or", "+", "return", "satisfies", "//", "/", "to", "union", "|", "where", ("preserve" | "strip") |
|
||
| <"castable" "as">, <"cast" "as"> |
|
||
| <"instance" "of">, <"treat" "as">, "case", "as", <")" "as"> |
|
||
| "}" |
|
||
| "$", <"for" "$">, <"let" "$"> |
|
||
| "(:" |
|
||
| ")", "?", <"empty" "greatest">, <"empty" "least">, "ascending", "descending", "default", "]" |
|
||
| "collation" |
|
||
| StringLiteral, NotOperatorKeyword |
|
This state is for recognition of XQuery version specific keywords.
| Pattern | Transition To State | |
|---|---|---|
| ";" |
|
|
| StringLiteral, "encoding" |
|
This state occurs inside of a namespace declaration, and is needed to recognize a NCName that is to be used as the prefix, as opposed to allowing a QName to occur. (Otherwise, the difference between NCName and QName are ambiguous.)
| Pattern | Transition To State | ||
|---|---|---|---|
| URILiteral, ",", <"at" URILiteral> |
|
||
| "(:" |
|
||
| "=", NCName |
|
||
| ";" |
|
This state is to recognize a URILiteral that transits to the OPERATOR state.
| Pattern | Transition To State | |
|---|---|---|
| URILiteral |
|
This state occurs at places where the keyword "namespace" is expected, which would otherwise be ambiguous compared to a QName. QNames can not occur in this state.
| Pattern | Transition To State | ||
|---|---|---|---|
| URILiteral |
|
||
| "inherit", "no-inherit" |
|
||
| "namespace" |
|
||
| "(:" |
|
||
| <"default" "element">, "preserve", "no-preserve", "," |
|
This state occurs at places where the keywords "preserve" and "strip" is expected to support "declare xmlspace". QNames can not occur in this state.
| Pattern | Transition To State | ||
|---|---|---|---|
| "preserve", "strip" |
|
||
| "(:" |
|
This state distinguishes tokens that can occur only inside the SingleType production.
| Pattern | Transition To State | ||
|---|---|---|---|
| QName |
|
||
| "(:" |
|
This state distinguishes tokens that can occur only inside the ItemType production.
| Pattern | Transition To State | ||
|---|---|---|---|
| "$" |
|
||
| <"void" "(" ")">, QName |
|
||
| "(:" |
|
||
| <"element" "(">, <"attribute" "(">, <"schema-element" "(">, <"schema-attribute" "(">, <"comment" "(">, <"text" "(">, <"node" "(">, <"document-node" "("> |
|
||
| <"processing-instruction" "("> |
|
||
| QName, <"item" "(" ")"> |
|
||
| "(#" |
|
||
| ";", "then", "else" |
|
||
| <"at" URILiteral> |
|
||
| "external", "and", "at", ":=", ",", "div", "=", "except", "eq", "ge", "gt", "le", "lt", "ne", ">=", ">>", ">", "idiv", "intersect", "in", "is", "[", "(", "<=", "<<", "<", "-", "mod", "!=", <"order" "by">, <"stable" "order" "by">, "or", "return", "satisfies", "to", "union", "|", "where" |
|
||
| <"castable" "as">, <"cast" "as"> |
|
||
| <"instance" "of">, <"treat" "as">, "case", "as", <")" "as"> |
|
This state is for the psuedo-parameters for the KindTest productions.
| Pattern | Transition To State | ||
|---|---|---|---|
| "{" |
|
||
| ")" |
|
||
| "*", QName |
|
||
| <"element" "(">, <"schema-element" "("> |
|
||
| "(:" |
|
This state is similar to KINDTEST, but recognizes NCNames instead of QNames.
| Pattern | Transition To State | ||
|---|---|---|---|
| ")" |
|
||
| "(:" |
|
||
| NCName, StringLiteral |
|
This state is expecting to close a KINDTEST sequence.
| Pattern | Transition To State | ||
|---|---|---|---|
| ")" |
|
||
| "," |
|
||
| "{" |
|
||
| "?" |
|
||
| "(:" |
|
This special state is needed to distinguish occurrence indicators that appear in the SequenceType production. For instance, compare "foo instance of baz*" to "baz*foo". In the first case, the "*" is interpreted as an occurrence indicator, and in the second case, it must be interpreted as a multiplication operator. But, when in the OCCURRENCEINDICATOR state, if anything else other than "?", "*", and "+", those symbols must be interpreted in the OPERATOR state. For instance, this would occur with the expression "foo instance of baz and $x", with the operator "and". This backing up of the lexical characters in order to reset the state, is symbolized by the notation "input_stream.backup(1)". NotOccurrenceIndicator is a special symbol for any character that is not an occurrence indicator.
| Pattern | Transition To State | ||
|---|---|---|---|
| [NotOccurrenceIndicator] |
|
||
| "?", "*", "+" |
|
||
| "(:" |
|
This state is entered in the prolog for an option declaration, and recognizes a QName that transits to a DEFAULT state rather than a OPERATOR state.
| Pattern | Transition To State | |
|---|---|---|
| QName |
|
This state is entered in a a pragma expression, and recognizes a QName that transits to a PRAGMACONTENTS state rather than a OPERATOR state.
| Pattern | Transition To State | |
|---|---|---|
| QName |
|
This state recognizes characters in pragma content, and transits out of this state when a '#)' pattern is recognized.
| Pattern | Transition To State | |
|---|---|---|
| "#)" |
|
|
| S, Char |
|
This state differentiates variable names from qualified names. This allows only the pattern of a QName to be recognized when otherwise ambiguities could occur.
| Pattern | Transition To State | ||
|---|---|---|---|
| VarName |
|
||
| "(:" |
|
This state allows attributes in the native XML syntax, and marks the beginning of an element construction. Element constructors also push the current state, popping it at the conclusion of an end tag. In the START_TAG state, the string ">" is recognized as a token which is associated with the transition to the original state.
| Pattern | Transition To State | |
|---|---|---|
| "/>" |
|
|
| ">" |
|
|
| '"' |
|
|
| "'" |
|
|
| "=" |
|
|
| S, QName |
|
This state allows XML-like content, without these characters being misinterpreted as expressions. The character "{" marks a transition to the DEFAULT state, i.e. the start of an embedded expression, and the "}" character pops back to the ELEMENT_CONTENT state. To allow curly braces to be used as character content, a double left or right curly brace is interpreted as a single curly brace character. The string "</" is interpreted as the beginning of an end tag, which is associated with a transition to the END_TAG state.
| Pattern | Transition To State | ||
|---|---|---|---|
| "</" |
|
||
| "{" |
|
||
| "<!--" |
|
||
| "<?" |
|
||
| "<![CDATA[" |
|
||
| "<" |
|
||
| ElementContentChar |
|
||
| PredefinedEntityRef, CharRef, "{{", "}}" |
|
When the end tag is terminated, the state is popped to the state that was pushed at the start of the corresponding start tag.
| Pattern | Transition To State | |
|---|---|---|
| ">" |
|
|
| S, QName |
|
The "<--" token marks the beginning of an XML Comment, and the "-->" token marks the end. This allows no special interpretation of other characters in this state.
| Pattern | Transition To State | |
|---|---|---|
| "-->" |
|
|
| (Char - '-'), <'-' (Char - '-')> |
|
The "(:" token marks the beginning of an expression Comment, and the ":)" token marks the end. This allows no special interpretation of other characters in this state.
| Pattern | Transition To State | ||
|---|---|---|---|
| ":)" |
|
||
| "(:" |
|
||
| Char |
|
In this state, only patterns that are legal in a processing instruction name are recognized.
| Pattern | Transition To State | |
|---|---|---|
| S |
|
|
| "?>" |
|
|
| PITarget |
|
In this state, only characters are that are legal in processing instruction content are recognized.
| Pattern | Transition To State | |
|---|---|---|
| "?>" |
|
|
| Char |
|
In this state, only lexemes that are legal in a CDATA section are recognized.
| Pattern | Transition To State | |
|---|---|---|
| "]]>" |
|
|
| Char |
|
This state allows content legal for attributes. The character "{" marks a transition to the DEFAULT state, i.e. the start of an embedded expression, and the "}" character pops back to the original state. To allow curly braces to be used as character content, a double left or right curly brace is interpreted as a single curly brace character. This state is the same as APOS_ATTRIBUTE_CONTENT, except that apostrophes are allowed without escaping, and an unescaped quote marks the end of the state.
| Pattern | Transition To State | ||
|---|---|---|---|
| '"' |
|
||
| "{" |
|
||
| EscapeQuot, QuotAttrContentChar |
|
||
| PredefinedEntityRef, CharRef, "{{", "}}" |
|
This state is the same as QUOT_ATTRIBUTE_CONTENT, except that quotes are allowed, and an unescaped apostrophe marks the end of the state.
| Pattern | Transition To State | ||
|---|---|---|---|
| "'" |
|
||
| "{" |
|
||
| EscapeApos, AposAttrContentChar |
|
||
| PredefinedEntityRef, CharRef, "{{", "}}" |
|
This state is for patterns that occur at the beginning of an expression or subexpression.
| Pattern | Transition To State | ||
|---|---|---|---|
| DecimalLiteral, "..", ".", DoubleLiteral, IntegerLiteral, NotNumber, <NCName ":" "*">, QName, ")", <"*" ":" NCName>, "*", StringLiteral |
|
||
| "$", <"for" "$">, <"some" "$">, <"every" "$"> |
|
||
| <"element" "(">, <"attribute" "(">, <"schema-element" "(">, <"schema-attribute" "(">, <"comment" "(">, <"text" "(">, <"node" "(">, <"document-node" "("> |
|
||
| <"processing-instruction" "("> |
|
||
| "(:" |
|
||
| ",", "(", <QName "(">, <"if" "(">, "-", "+", "//", "/", <"ancestor-or-self" "::">, <"ancestor" "::">, <"attribute" "::">, <"child" "::">, <"descendant-or-self" "::">, <"descendant" "::">, <"following-sibling" "::">, <"following" "::">, <"namespace" "::">, <"parent" "::">, <"preceding-sibling" "::">, <"preceding" "::">, <"self" "::">, "@" |
|
This state is for patterns that are defined for operators.
| Pattern | Transition To State | ||
|---|---|---|---|
| "then", "else", "and", ",", "div", "=", "except", "eq", "ge", "gt", "le", "lt", "ne", ">=", ">>", ">", "idiv", "intersect", "in", "is", "[", "<=", "<<", "<", "-", "mod", "*", "!=", "or", "+", "return", "satisfies", "//", "/", "to", "union", "|" |
|
||
| <"castable" "as">, <"cast" "as"> |
|
||
| <"instance" "of">, <"treat" "as"> |
|
||
| "$", <"for" "$"> |
|
||
| "(:" |
|
||
| ")", "?", "]" |
|
||
| StringLiteral, NotOperatorKeyword |
|
This state distinguishes tokens that can occur only inside the SingleType production.
| Pattern | Transition To State | ||
|---|---|---|---|
| QName |
|
||
| "(:" |
|
This state distinguishes tokens that can occur only inside the ItemType production.
| Pattern | Transition To State | ||
|---|---|---|---|
| <"void" "(" ")">, QName |
|
||
| "(:" |
|
||
| <"element" "(">, <"attribute" "(">, <"schema-element" "(">, <"schema-attribute" "(">, <"comment" "(">, <"text" "(">, <"node" "(">, <"document-node" "("> |
|
||
| <"processing-instruction" "("> |
|
||
| QName, <"item" "(" ")"> |
|
||
| "then", "else" |
|
||
| "and", ",", "div", "=", "except", "eq", "ge", "gt", "le", "lt", "ne", ">=", ">>", ">", "idiv", "intersect", "in", "is", "[", "(", "<=", "<<", "<", "-", "mod", "!=", "or", "return", "satisfies", "to", "union", "|" |
|
||
| <"castable" "as">, <"cast" "as"> |
|
||
| <"instance" "of">, <"treat" "as"> |
|
This state is for the psuedo-parameters for the KindTest productions.
| Pattern | Transition To State | ||
|---|---|---|---|
| ")" |
|
||
| "*", QName |
|
||
| <"element" "(">, <"schema-element" "("> |
|
||
| "(:" |
|
This state is similar to KINDTEST, but recognizes NCNames instead of QNames.
| Pattern | Transition To State | ||
|---|---|---|---|
| ")" |
|
||
| "(:" |
|
||
| NCName, StringLiteral |
|
This state is expecting to close a KINDTEST sequence.
| Pattern | Transition To State | ||
|---|---|---|---|
| ")" |
|
||
| "," |
|
||
| "?" |
|
||
| "(:" |
|
This special state is needed to distinguish occurrence indicators that appear in the SequenceType production. For instance, compare "foo instance of baz*" to "baz*foo". In the first case, the "*" is interpreted as an occurrence indicator, and in the second case, it must be interpreted as a multiplication operator. But, when in the OCCURRENCEINDICATOR state, if anything else other than "?", "*", and "+", those symbols must be interpreted in the OPERATOR state. For instance, this would occur with the expression "foo instance of baz and $x", with the operator "and". This backing up of the lexical characters in order to reset the state, is symbolized by the notation "input_stream.backup(1)". NotOccurrenceIndicator is a special symbol for any character that is not an occurrence indicator.
| Pattern | Transition To State | ||
|---|---|---|---|
| [NotOccurrenceIndicator] |
|
||
| "?", "*", "+" |
|
||
| "(:" |
|
This state differentiates variable names from qualified names. This allows only the pattern of a QName to be recognized when otherwise ambiguities could occur.
| Pattern | Transition To State | ||
|---|---|---|---|
| VarName |
|
||
| "(:" |
|
The "(:" token marks the beginning of an expression Comment, and the ":)" token marks the end. This allows no special interpretation of other characters in this state.
| Pattern | Transition To State | ||
|---|---|---|---|
| ":)" |
|
||
| "(:" |
|
||
| Char |
|
For convenience, the basic EBNF of the XPath and XQuery grammars are reproduced here. For further details please consult the respective specifications.
The following grammars use the same simple Extended Backus-Naur Form (EBNF) notation as [XML 1.0] with the following minor differences. The notation "< ... >" is used to indicate a grouping of terminals that together may help disambiguate the individual symbols. To help readability, this "< ... >" notation is absent in the EBNF in the main body of this document. For further details concerning the EBNF notation used, see Section A.1 EBNFXQ in [XQuery 1.0: An XML Query Language] or Section A.1 EBNFXP in [XML Path Language (XPath) 2.0].
Comments on grammar productions are between '/*' and '*/' symbols. A 'gn:' prefix means a 'Grammar Note', and is meant as a clarification for parsing rules, and are explained in Section A.1.1 Grammar NotesXQ in [XQuery 1.0: An XML Query Language] or Section A.1.1 Grammar NotesXP in [XML Path Language (XPath) 2.0]. A 'ws:' prefix explains the whitespace rules for the production, the details of which are explained in Section A.2.2 Whitespace RulesXQ in [XQuery 1.0: An XML Query Language] or Section A.2.2 Whitespace RulesXP in [XML Path Language (XPath) 2.0].
| [1] | XPath |
::= | Expr |
|
| [2] | Expr |
::= | ExprSingle ("," ExprSingle)* |
|
| [3] | ExprSingle |
::= | ForExpr |
|
| [4] | ForExpr |
::= | SimpleForClause "return" ExprSingle |
|
| [5] | SimpleForClause |
::= | <"for" "$"> VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)* |
|
| [6] | QuantifiedExpr |
::= | (<"some" "$"> | <"every" "$">) VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)* "satisfies" ExprSingle |
|
| [7] | IfExpr |
::= | <"if" "("> Expr ")" "then" ExprSingle "else" ExprSingle |
|
| [8] | OrExpr |
::= | AndExpr ( "or" AndExpr )* |
|
| [9] | AndExpr |
::= | ComparisonExpr ( "and" ComparisonExpr )* |
|
| [10] | ComparisonExpr |
::= | RangeExpr ( (ValueComp |
|
| [11] | RangeExpr |
::= | AdditiveExpr ( "to" AdditiveExpr )? |
|
| [12] | AdditiveExpr |
::= | MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )* |
|
| [13] | MultiplicativeExpr |
::= | UnionExpr ( ("*" | "div" | "idiv" | "mod") UnionExpr )* |
|
| [14] | UnionExpr |
::= | IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )* |
|
| [15] | IntersectExceptExpr |
::= | InstanceofExpr ( ("intersect" | "except") InstanceofExpr )* |
|
| [16] | InstanceofExpr |
::= | TreatExpr ( <"instance" "of"> SequenceType )? |
|
| [17] | TreatExpr |
::= | CastableExpr ( <"treat" "as"> SequenceType )? |
|
| [18] | CastableExpr |
::= | CastExpr ( <"castable" "as"> SingleType )? |
|
| [19] | CastExpr |
::= | UnaryExpr ( <"cast" "as"> SingleType )? |
|
| [20] | UnaryExpr |
::= | ("-" | "+")* ValueExpr |
|
| [21] | ValueExpr |
::= | PathExpr |
|
| [22] | GeneralComp |
::= | "=" | "!=" | "<" | "<=" | ">" | ">=" |
/* gn: ltXP */ |
| [23] | ValueComp |
::= | "eq" | "ne" | "lt" | "le" | "gt" | "ge" |
|
| [24] | NodeComp |
::= | "is" | "<<" | ">>" |
|
| [25] | PathExpr |
::= | ("/" RelativePathExpr?) |
/* gn: leading-lone-slashXP */ |
| [26] | RelativePathExpr |
::= | StepExpr (("/" | "//") StepExpr)* |
|
| [27] | StepExpr |
::= | AxisStep | FilterExpr |
|
| [28] | AxisStep |
::= | (ForwardStep | ReverseStep) PredicateList |
|
| [29] | ForwardStep |
::= | (ForwardAxis NodeTest) | AbbrevForwardStep |
|
| [30] | ForwardAxis |
::= | <"child" "::"> |
|
| [31] | AbbrevForwardStep |
::= | "@"? NodeTest |
|
| [32] | ReverseStep |
::= | (ReverseAxis NodeTest) | AbbrevReverseStep |
|
| [33] | ReverseAxis |
::= | <"parent" "::"> |
|
| [34] | AbbrevReverseStep |
::= | ".." |
|
| [35] | NodeTest |
::= | KindTest | NameTest |
|
| [36] | NameTest |
::= | QName | Wildcard |
|
| [37] | Wildcard |
::= | "*" |
/* ws: explicitXP */ |
| [38] | FilterExpr |
::= | PrimaryExpr PredicateList |
|
| [39] | PredicateList |
::= | Predicate* |
|
| [40] | Predicate |
::= | "[" Expr "]" |
|
| [41] | PrimaryExpr |
::= | Literal | VarRef | ParenthesizedExpr | ContextItemExpr | FunctionCall |
|
| [42] | Literal |
::= | NumericLiteral | StringLiteral |
|
| [43] | NumericLiteral |
::= | IntegerLiteral | DecimalLiteral | DoubleLiteral |
|
| [44] | VarRef |
::= | "$" VarName |
|
| [45] | ParenthesizedExpr |
::= | "(" Expr? ")" |
|
| [46] | ContextItemExpr |
::= | "." |
|
| [47] | FunctionCall |
::= | <QName "("> (ExprSingle ("," ExprSingle)*)? ")" |
/* gn: parensXP */ |
| /* gn: reserved-function-namesXP */ | ||||
| [48] | SingleType |
::= | AtomicType "?"? |
|
| [49] | SequenceType |
::= | (ItemType OccurrenceIndicator?) |
|
| [50] | OccurrenceIndicator |
::= | "?" | "*" | "+" |
/* gn: occurrence-indicatorsXP */ |
| [51] | ItemType |
::= | AtomicType | KindTest | <"item" "(" ")"> |
|
| [52] | AtomicType |
::= | QName |
|
| [53] | KindTest |
::= | DocumentTest |
|
| [54] | AnyKindTest |
::= | <"node" "("> ")" |
|
| [55] | DocumentTest |
::= | <"document-node" "("> (ElementTest | SchemaElementTest)? ")" |
|
| [56] | TextTest |
::= | <"text" "("> ")" |
|
| [57] | CommentTest |
::= | <"comment" "("> ")" |
|
| [58] | PITest |
::= | <"processing-instruction" "("> (NCName | StringLiteral)? ")" |
|
| [59] | AttributeTest |
::= | <"attribute" "("> (AttribNameOrWildcard ("," TypeName)?)? ")" |
|
| [60] | AttribNameOrWildcard |
::= | AttributeName | "*" |
|
| [61] | SchemaAttributeTest |
::= | <"schema-attribute" "("> AttributeDeclaration ")" |
|
| [62] | AttributeDeclaration |
::= | AttributeName |
|
| [63] | ElementTest |
::= | <"element" "("> (ElementNameOrWildcard ("," TypeName "?"?)?)? ")" |
|
| [64] | ElementNameOrWildcard |
::= | ElementName | "*" |
|
| [65] | SchemaElementTest |
::= | <"schema-element" "("> ElementDeclaration ")" |
|
| [66] | ElementDeclaration |
::= | ElementName |
|
| [67] | AttributeName |
::= | QName |
|
| [68] | ElementName |
::= | QName |
|
| [69] | TypeName |
::= | QName |
| [70] | IntegerLiteral |
::= | Digits |
|
| [71] | DecimalLiteral |
::= | ("." Digits) | (Digits "." [0-9]*) |
/* ws: explicitXP */ |
| [72] | DoubleLiteral |
::= | (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits |
/* ws: explicitXP */ |
| [73] | StringLiteral |
::= | ('"' (('"' '"') | [^"])* '"') | ("'" (("'" "'") | [^'])* "'") |
/* ws: explicitXP */ |
| [74] | VarName |
::= | QName |
|
| [75] | Digits |
::= | [0-9]+ |
|
| [76] | Comment |
::= | "(:" (CommentContents | Comment)* ":)" |
/* ws: explicitXP */ |
| /* gn: commentsXP */ | ||||
| [77] | CommentContents |
::= | (Char+ - (Char* ':)' Char*)) |
|
| [78] | QName |
::= | [http://www.w3.org/TR/REC-xml-names/#NT-QName]Names |
/* gn: xml-versionXP */ |
| [79] | NCName |
::= | [http://www.w3.org/TR/REC-xml-names/#NT-NCName]Names |
/* gn: xml-versionXP */ |
| [80] | Char |
::= | [http://www.w3.org/TR/REC-xml#NT-Char]XML |
/* gn: xml-versionXP */ |
| [1] | Module |
::= | VersionDecl? (MainModule | LibraryModule) |
|
| [2] | VersionDecl |
::= | <"xquery" "version"> StringLiteral ("encoding" StringLiteral)? Separator |
|
| [3] | MainModule |
::= | Prolog QueryBody |
|
| [4] | LibraryModule |
::= | ModuleDecl Prolog |
|
| [5] | ModuleDecl |
::= | <"module" "namespace"> NCName "=" URILiteral Separator |
|
| [6] | Prolog |
::= | ((Setter | Import | NamespaceDecl | DefaultNamespaceDecl) Separator)* ((VarDecl | FunctionDecl | OptionDecl) Separator)* |
|
| [7] | Setter |
::= | BoundarySpaceDecl | DefaultCollationDecl | BaseURIDecl | ConstructionDecl | OrderingModeDecl | EmptyOrderDecl | CopyNamespacesDecl |
|
| [8] | Import |
::= | SchemaImport | ModuleImport |
|
| [9] | Separator |
::= | ";" |
|
| [10] | NamespaceDecl |
::= | <"declare" "namespace"> NCName "=" URILiteral |
|
| [11] | BoundarySpaceDecl |
::= | <"declare" "boundary-space"> ("preserve" | "strip") |
|
| [12] | DefaultNamespaceDecl |
::= | (<"declare" "default" "element"> | <"declare" "default" "function">) "namespace" URILiteral |
|
| [13] | OptionDecl |
::= | <"declare" "option"> QName StringLiteral |
|
| [14] | OrderingModeDecl |
::= | <"declare" "ordering"> ("ordered" | "unordered") |
|
| [15] | EmptyOrderDecl |
::= | <"declare" "default" "order"> (<"empty" "greatest"> | <"empty" "least">) |
|
| [16] | CopyNamespacesDecl |
::= | <"declare" "copy-namespaces"> PreserveMode "," InheritMode |
|
| [17] | PreserveMode |
::= | "preserve" | "no-preserve" |
|
| [18] | InheritMode |
::= | "inherit" | "no-inherit" |
|
| [19] | DefaultCollationDecl |
::= | <"declare" "default" "collation"> URILiteral |
|
| [20] | BaseURIDecl |
::= | <"declare" "base-uri"> URILiteral |
|
| [21] | SchemaImport |
::= | <"import" "schema"> SchemaPrefix? URILiteral (<"at" URILiteral> ("," URILiteral)*)? |
|
| [22] | SchemaPrefix |
::= | ("namespace" NCName "=") | (<"default" "element"> "namespace") |
|
| [23] | ModuleImport |
::= | <"import" "module"> ("namespace" NCName "=")? URILiteral (<"at" URILiteral> ("," URILiteral)*)? |
|
| [24] | VarDecl |
::= | <"declare" "variable" "$"> VarName TypeDeclaration? ((":=" ExprSingle) | "external") |
|
| [25] | ConstructionDecl |
::= | <"declare" "construction"> ("preserve" | "strip") |
|
| [26] | FunctionDecl |
::= | <"declare" "function"> <QName "("> ParamList? (")" | (<")" "as"> SequenceType)) (EnclosedExpr | "external") |
|
| [27] | ParamList |
::= | Param ("," Param)* |
|
| [28] | Param |
::= | "$" VarName TypeDeclaration? |
|
| [29] | EnclosedExpr |
::= | "{" Expr "}" |
|
| [30] | QueryBody |
::= | Expr |
|
| [31] | Expr |
::= | ExprSingle ("," ExprSingle)* |
|
| [32] | ExprSingle |
::= | FLWORExpr |
|
| [33] | FLWORExpr |
::= | (ForClause | LetClause)+ WhereClause? OrderByClause? "return" ExprSingle |
|
| [34] | ForClause |
::= | <"for" "$"> VarName TypeDeclaration? PositionalVar? "in" ExprSingle ("," "$" VarName TypeDeclaration? PositionalVar? "in" ExprSingle)* |
|
| [35] | PositionalVar |
::= | "at" "$" VarName |
|
| [36] | LetClause |
::= | <"let" "$"> VarName TypeDeclaration? ":=" ExprSingle ("," "$" VarName TypeDeclaration? ":=" ExprSingle)* |
|
| [37] | WhereClause |
::= | "where" ExprSingle |
|
| [38] | OrderByClause |
::= | (<"order" "by"> | <"stable" "order" "by">) OrderSpecList |
|
| [39] | OrderSpecList |
::= | OrderSpec ("," OrderSpec)* |
|
| [40] | OrderSpec |
::= | ExprSingle OrderModifier |
|
| [41] | OrderModifier |
::= | ("ascending" | "descending")? (<"empty" "greatest"> | <"empty" "least">)? ("collation" URILiteral)? |
|
| [42] | QuantifiedExpr |
::= | (<"some" "$"> | <"every" "$">) VarName TypeDeclaration? "in" ExprSingle ("," "$" VarName TypeDeclaration? "in" ExprSingle)* "satisfies" ExprSingle |
|
| [43] | TypeswitchExpr |
::= | <"typeswitch" "("> Expr ")" CaseClause+ "default" ("$" VarName)? "return" ExprSingle |
|
| [44] | CaseClause |
::= | "case" ("$" VarName "as")? SequenceType "return" ExprSingle |
|
| [45] | IfExpr |
::= | <"if" "("> Expr ")" "then" ExprSingle "else" ExprSingle |
|
| [46] | OrExpr |
::= | AndExpr ( "or" AndExpr )* |
|
| [47] | AndExpr |
::= | ComparisonExpr ( "and" ComparisonExpr )* |
|
| [48] | ComparisonExpr |
::= | RangeExpr ( (ValueComp |
|
| [49] | RangeExpr |
::= | AdditiveExpr ( "to" AdditiveExpr )? |
|
| [50] | AdditiveExpr |
::= | MultiplicativeExpr ( ("+" | "-") MultiplicativeExpr )* |
|
| [51] | MultiplicativeExpr |
::= | UnionExpr ( ("*" | "div" | "idiv" | "mod") UnionExpr )* |
|
| [52] | UnionExpr |
::= | IntersectExceptExpr ( ("union" | "|") IntersectExceptExpr )* |
|
| [53] | IntersectExceptExpr |
::= | InstanceofExpr ( ("intersect" | "except") InstanceofExpr )* |
|
| [54] | InstanceofExpr |
::= | TreatExpr ( <"instance" "of"> SequenceType )? |
|
| [55] | TreatExpr |
::= | CastableExpr ( <"treat" "as"> SequenceType )? |
|
| [56] | CastableExpr |
::= | CastExpr ( <"castable" "as"> SingleType )? |
|
| [57] | CastExpr |
::= | UnaryExpr ( <"cast" "as"> SingleType )? |
|
| [58] | UnaryExpr |
::= | ("-" | "+")* ValueExpr |
|
| [59] | ValueExpr |
::= | ValidateExpr | PathExpr | ExtensionExpr |
|
| [60] | GeneralComp |
::= | "=" | "!=" | "<" | "<=" | ">" | ">=" |
/* gn: ltXQ */ |
| [61] | ValueComp |
::= | "eq" | "ne" | "lt" | "le" | "gt" | "ge" |
|
| [62] | NodeComp |
::= | "is" | "<<" | ">>" |
|
| [63] | ValidateExpr |
::= | (<"validate" "{"> | (<"validate" ValidationMode> "{")) Expr "}" |
|
| [64] | ExtensionExpr |
::= | Pragma+ "{" Expr? "}" |
|
| [65] | Pragma |
::= | "(#" S? QName PragmaContents "#)" |
/* ws: explicitXQ */ |
| [66] | PragmaContents |
::= | (Char* - (Char* '#)' Char*)) |
|
| [67] | PathExpr |
::= | ("/" RelativePathExpr?) |
/* gn: leading-lone-slashXQ */ |
| [68] | RelativePathExpr |
::= | StepExpr (("/" | "//") StepExpr)* |
|
| [69] | StepExpr |
::= | AxisStep | FilterExpr |
|
| [70] | AxisStep |
::= | (ForwardStep | ReverseStep) PredicateList |
|
| [71] | ForwardStep |
::= | (ForwardAxis NodeTest) | AbbrevForwardStep |
|
| [72] | ForwardAxis |
::= | <"child" "::"> |
|
| [73] | AbbrevForwardStep |
::= | "@"? NodeTest |
|
| [74] | ReverseStep |
::= | (ReverseAxis NodeTest) | AbbrevReverseStep |
|
| [75] | ReverseAxis |
::= | <"parent" "::"> |
|
| [76] | AbbrevReverseStep |
::= | ".." |
|
| [77] | NodeTest |
::= | KindTest | NameTest |
|
| [78] | NameTest |
::= | QName | Wildcard |
|
| [79] | Wildcard |
::= | "*" |
/* ws: explicitXQ */ |
| [80] | FilterExpr |
::= | PrimaryExpr PredicateList |
|
| [81] | PredicateList |
::= | Predicate* |
|
| [82] | Predicate |
::= | "[" Expr "]" |
|
| [83] | PrimaryExpr |
::= | Literal | VarRef | ParenthesizedExpr | ContextItemExpr | FunctionCall | Constructor | OrderedExpr | UnorderedExpr |
|
| [84] | Literal |
::= | NumericLiteral | StringLiteral |
|
| [85] | NumericLiteral |
::= | IntegerLiteral | DecimalLiteral | DoubleLiteral |
|
| [86] | VarRef |
::= | "$" VarName |
|
| [87] | ParenthesizedExpr |
::= | "(" Expr? ")" |
|
| [88] | ContextItemExpr |
::= | "." |
|
| [89] | OrderedExpr |
::= | <"ordered" "{"> Expr "}" |
|
| [90] | UnorderedExpr |
::= | <"unordered" "{"> Expr "}" |
|
| [91] | FunctionCall |
::= | <QName "("> (ExprSingle ("," ExprSingle)*)? ")" |
/* gn: parensXQ */ |
| /* gn: reserved-function-namesXQ */ | ||||
| [92] | Constructor |
::= | DirectConstructor |
|
| [93] | DirectConstructor |
::= | DirElemConstructor |
|
| [94] | DirElemConstructor |
::= | "<" QName DirAttributeList ("/>" | (">" DirElemContent* "</" QName S? ">")) |
/* ws: explicitXQ */ |
| /* gn: ltXQ */ | ||||
| [95] | DirAttributeList |
::= | (S (QName S? "=" S? DirAttributeValue)?)* |
/* ws: explicitXQ */ |
| [96] | DirAttributeValue |
::= | ('"' (EscapeQuot | QuotAttrValueContent)* '"') |
/* ws: explicitXQ */ |
| [97] | QuotAttrValueContent |
::= | QuotAttrContentChar |
|
| [98] | AposAttrValueContent |
::= | AposAttrContentChar |
|
| [99] | DirElemContent |
::= | DirectConstructor |
|
| [100] | CommonContent |
::= | PredefinedEntityRef | CharRef | "{{" | "}}" | EnclosedExpr |
|
| [101] | DirCommentConstructor |
::= | "<!--" DirCommentContents "-->" |
/* ws: explicitXQ */ |
| [102] | DirCommentContents |
::= | ((Char - '-') | <'-' (Char - '-')>)* |
/* ws: explicitXQ */ |
| [103] | DirPIConstructor |
::= | "<?" PITarget (S DirPIContents)? "?>" |
/* ws: explicitXQ */ |
| [104] | DirPIContents |
::= | (Char* - (Char* '?>' Char*)) |
/* ws: explicitXQ */ |
| [105] | CDataSection |
::= | "<![CDATA[" CDataSectionContents "]]>" |
/* ws: explicitXQ */ |
| [106] | CDataSectionContents |
::= | (Char* - (Char* ']]>' Char*)) |
/* ws: explicitXQ */ |
| [107] | ComputedConstructor |
::= | CompDocConstructor |
|
| [108] | CompDocConstructor |
::= | <"document" "{"> Expr "}" |
|
| [109] | CompElemConstructor |
::= | (<"element" QName "{"> | (<"element" "{"> Expr "}" "{")) ContentExpr? "}" |
|
| [110] | ContentExpr |
::= | Expr |
|
| [111] | CompAttrConstructor |
::= | (<"attribute" QName "{"> | (<"attribute" "{"> Expr "}" "{")) Expr? "}" |
|
| [112] | CompTextConstructor |
::= | <"text" "{"> Expr "}" |
|
| [113] | CompCommentConstructor |
::= | <"comment" "{"> Expr "}" |
|
| [114] | CompPIConstructor |
::= | (<"processing-instruction" NCName "{"> | (<"processing-instruction" "{"> Expr "}" "{")) Expr? "}" |
|
| [115] | SingleType |
::= | AtomicType "?"? |
|
| [116] | TypeDeclaration |
::= | "as" SequenceType |
|
| [117] | SequenceType |
::= | (ItemType OccurrenceIndicator?) |
|
| [118] | OccurrenceIndicator |
::= | "?" | "*" | "+" |
/* gn: occurrence-indicatorsXQ */ |
| [119] | ItemType |
::= | AtomicType | KindTest | <"item" "(" ")"> |
|
| [120] | AtomicType |
::= | QName |
|
| [121] | KindTest |
::= | DocumentTest |
|
| [122] | AnyKindTest |
::= | <"node" "("> ")" |
|
| [123] | DocumentTest |
::= | <"document-node" "("> (ElementTest | SchemaElementTest)? ")" |
|
| [124] | TextTest |
::= | <"text" "("> ")" |
|
| [125] | CommentTest |
::= | <"comment" "("> ")" |
|
| [126] | PITest |
::= | <"processing-instruction" "("> (NCName | StringLiteral)? ")" |
|
| [127] | AttributeTest |
::= | <"attribute" "("> (AttribNameOrWildcard ("," TypeName)?)? ")" |
|
| [128] | AttribNameOrWildcard |
::= | AttributeName | "*" |
|
| [129] | SchemaAttributeTest |
::= | <"schema-attribute" "("> AttributeDeclaration ")" |
|
| [130] | AttributeDeclaration |
::= | AttributeName |
|
| [131] | ElementTest |
::= | <"element" "("> (ElementNameOrWildcard ("," TypeName "?"?)?)? ")" |
|
| [132] | ElementNameOrWildcard |
::= | ElementName | "*" |
|
| [133] | SchemaElementTest |
::= | <"schema-element" "("> ElementDeclaration ")" |
|
| [134] | ElementDeclaration |
::= | ElementName |
|
| [135] | AttributeName |
::= | QName |
|
| [136] | ElementName |
::= | QName |
|
| [137] | TypeName |
::= | QName |
| [138] | IntegerLiteral |
::= | Digits |
|
| [139] | DecimalLiteral |
::= | ("." Digits) | (Digits "." [0-9]*) |
/* ws: explicitXQ */ |
| [140] | DoubleLiteral |
::= | (("." Digits) | (Digits ("." [0-9]*)?)) [eE] [+-]? Digits |
/* ws: explicitXQ */ |
| [141] | URILiteral |
::= | StringLiteral |
|
| [142] | StringLiteral |
::= | ('"' (PredefinedEntityRef | CharRef | ('"' '"') | [^"&])* '"') | ("'" (PredefinedEntityRef | CharRef | ("'" "'") | [^'&])* "'") |
/* ws: explicitXQ */ |
| [143] | PITarget |
::= | [http://www.w3.org/TR/REC-xml#NT-PITarget]XML |
/* gn: xml-versionXQ */ |
| [144] | VarName |
::= | QName |
|
| [145] | ValidationMode |
::= | "lax" | "strict" |
|
| [146] | Digits |
::= | [0-9]+ |
|
| [147] | PredefinedEntityRef |
::= | "&" ("lt" | "gt" | "amp" | "quot" | "apos") ";" |
/* ws: explicitXQ */ |
| [148] | CharRef |
::= | [http://www.w3.org/TR/REC-xml#NT-CharRef]XML |
/* gn: xml-versionXQ */ |
| [149] | EscapeQuot |
::= | '""' |
|
| [150] | EscapeApos |
::= | "''" |
|
| [151] | ElementContentChar |
::= | Char - [{}<&] |
|
| [152] | QuotAttrContentChar |
::= | Char - ["{}<&] |
|
| [153] | AposAttrContentChar |
::= | Char - ['{}<&] |
|
| [154] | Comment |
::= | "(:" (CommentContents | Comment)* ":)" |
/* ws: explicitXQ */ |
| /* gn: commentsXQ */ | ||||
| [155] | CommentContents |
::= | (Char+ - (Char* ':)' Char*)) |
|
| [156] | QName |
::= | [http://www.w3.org/TR/REC-xml-names/#NT-QName]Names |
/* gn: xml-versionXQ */ |
| [157] | NCName |
::= | [http://www.w3.org/TR/REC-xml-names/#NT-NCName]Names |
/* gn: xml-versionXQ */ |
| [158] | S |
::= | [http://www.w3.org/TR/REC-xml#NT-S]XML |
/* gn: xml-versionXQ */ |
| [159] | Char |
::= | [http://www.w3.org/TR/REC-xml#NT-Char]XML |
/* gn: xml-versionXQ */ |
Fuzzy token scanner. Using this strategy, a typical simple lexical scanner is implemented, but the meaning of the tokens are often left somewhat ambiguous. Thus, the word div
might be assigned the symbol QNameOrKeyword. The words can be disambiguated during the context sensitive parse process. This approach would probably be a hand-constructed, Top-down parser.
LALR Parser (Look Ahead Left to right, Rightmost derivation, hence LALR).
A lexical action is an action that occurs as an side-effect of a pattern recognition.
Lexical scanner, which assigns symbols known as tokens to units in the input, in essence recognizing the basic words and punctuation of the language. Typically, the lexer uses regular expressions as a specification for how to do this tokenization. The rules that govern the lexical structure of the language, sometimes known as microsyntax, should be simple, regular, and as context-free as possible.
A lexical state is a condition where a defined set of patterns are recognized.
LL Parser (Left to right, Leftmost derivation, hence LL).
Long tokens. Using this approach, declare namespace
would be considered a single token.
Parser, which arranges the tokens into a hierarchical structure. Typically, the parser uses a BNF or variant description (EBNF in the case of XPath/XQuery) as a specification for this parsing.
Scan-while-parse scanner. Using this strategy, the parser would evaluate the character stream into tokens, while at the same time branching to the respective hierarchical context. Thus the words can be discovered in context. Complex parsers are typically not built in this fashion, but, given the issue of context sensitivity, this may be a reasonable approach. This would probably be implemented as a hand-constructed recursive-descent parser.
Short tokens. Using this approach, declare namespace
would be considered two tokens, the exact symbols assigned based on lexical look-ahead (and look-behind).
State-driven scanner. This approach recognizes sets of words only in certain states, each word or punctuation possibly transitioning to a next state. In other words, it implements lexical recognition as transition tables for a push-down automata.
Two-pass scanner. This is the same as the Fuzzy token scanner, but the ambiguous words can be disambiguated by a second scan, using some rules (probably expressed as a context-free grammar) that reflect the basic structure of the EBNF (call this the three-pass approach). The three-pass approach could conceivably be implemented via a parser constructor program, with the addition of a custom disambiguator in between the lexer and parser. This method could be used for either Top-down or Bottom-up techniques.
XQuery does not include the ForExpr production and <"namespace" "::"> axis.