EPL syntax wrong - complex-event-processing

I am very new to EPL queries.
Wrote this and it is throwing syntax error.
#Name('ExpressionTotalQuantitySoFar')
#Description('Gets the total quantity of a symbol so far')
create expression totalQuantitySoFar{ (TAX) =>
(Select sum(T.quantity) from TaxlotWindow as T where T.symbol = TAX.symbol and T.taxlotId < TAX.taxlotId)
};
create variable double totQty = 5.0 ;
#Name('ExpressionLongDebitBalanceTaxlotNoBox')
#Description('Check is if a trade side is invalid, returns rue for invalid statements')
create expression longDebitBalanceTaxlotNoBox{ (SECUR,TAX,ORD,AUE,FX) =>
totQty = totalQuantitySoFar(TAX)
case when (totQty > 0)
then cashImpactBase(SECUR,TAX,ORD,AUE,FX)*(-1)
else
0.0
end
};
It gives syntax error near case.
Any help?

Always include the syntax error text when posting. Else how is one supposed to be able to help.
My tip would be to simplify until the syntax is fine. Then add back stuff.
Most likely this strange declaration "totQty=.." is the cause as its wrong. EPL expressions are not a programming language and don't allow variable declarations like in Java or Scala. Perhaps just use a Java static method to compute instead of you need a programming language.

Related

Support of `do..while` Loop In scala

Hello everyone I am new to scala and after seeing the do..while syntax which is the following:
do{
<action>
}while(condition)
I have been asked to perform this exercise which consists in predicting the output of a program containing the do..while loop.
var set = Set(1)
do {
set = set + (set.max + 1)
} while (set.sum < 32)
println(set.size)
After execution I get the following error:
end of statement expected but 'do' found
do {
I know that it is possible to convert this loop to while (which is even ideal), however I would like to know if the do..while loop still works in scala if yes, is it a syntax error (Because I searched on the net but I found the same syntax and no mention of this error)? if no, is there a version from which the loop is no longer supported?
You can still use do-while in Scala 2.13.10
https://scastie.scala-lang.org/DmytroMitin/JcGnZS3DRle3jXIUiwkb0A
In Scala 3 you can write do-while in while-do manner using Scala being expression-oriented (i.e. the last expression is what is returned from a block)
while ({
set = set + (set.max + 1)
set.sum < 32
}) {}
https://scastie.scala-lang.org/DmytroMitin/JcGnZS3DRle3jXIUiwkb0A/2
https://docs.scala-lang.org/scala3/reference/dropped-features/do-while.html

error: "struct" expression not at top level

function check(str,arg;type=DataType,max=nothing,min=nothing,description="")
#argcheck typeof(arg)==type
#argcheck arg>min
#argcheck arg<max
#argcheck typeof(description)==String
return arg
end
function constr(name,arg,field)
return :(function $name($arg,$field)
new(check($name,$arg,$field))
end)
end
macro creatStruct(name,arg)
code = Base.remove_linenums!(quote
struct $name
end
end)
print(arg)
append!(code.args[1].args[3].args,[constr(name,arg.args[1].args[1],arg.args[1].args[2])])
code
end
macro myStruct(name,arg)
#creatStruct name arg
end
#myStruct test12 (
(arg1,(max=10))
)
In my code above I'm trying to build a macro that Creates a struct, and within the struct, you can define an argument with boundaries (max, min) and description, etc.
I'm getting this error:
syntax: "#141#max = 10" is not a valid function argument name
and every time I'm trying to solve it, I get another error like:
LoadError: syntax: "struct" expression not at top level
So, I think my Code/Approach is not that cohesive. Anybody can suggest tips and/or another Approche.
You're attempting to make an argument name max with a default value of 10. The error is about max=10 not being a valid name (Symbol), while max is. The bigger issue is you're trying to put this in the struct expression instead of a constructor method:
struct Foo
bar::Float64
max::Int64
end
# constructor
Foo(bar, max=10) = Foo(bar, max)
So you have to figure out how to make an expression for a method with default values, too.
Your second error means that structs must be defined in the top-level. "Top-level" is like global scope but stricter in some contexts; I don't know the exact difference, but it definitely excludes local scopes (macro, function, etc). It looks like the issue is the expression returned by creatStruct being evaluated as code in myStruct, but the LoadError I'm getting has a different message. In any case, the error goes away if I make sure things stay as expressions:
macro myStruct(name,arg)
:(#creatStruct $name $arg)
end

MVEL Expression with multiple conditions

I am trying to get an MVEL expression to work but am having probelms. I am tyring to determine if date defined as a property falls between two other dates.
props['ExistingStartDate'] >= props['current_period_start_date'] && props['ExistingStartDate'] <= props['current_period_end_date']
So in this case, my ExistingStartDate = 3/6/14, current_period_start_date = 3/3/14 and current_period_end_date = 3/16/14
I am expecting this to be true. I feel like there must be something wrong with my syntax. Any help would be appreciated!
Use parentheses for each term for multiple conditions:
(props['ExistingStartDate'] >= props['current_period_start_date']) && (props['ExistingStartDate'] <= props['current_period_end_date'])
Also, the props references may not have the correct syntax depending on what type of Java object it is.

validate a where clause query in c#

I was asked this question in an interview.
Write a c# program which will print out all the errors in a statement.
(a + b == 3 and x == y or b / c == d)
Allowed keywords are and/or, braces are allowed and have to match. The statement has to be logically correct. Print out all the errors.
Something like a compiler or sql analyzer.
Any idea how to go about syntax checking?
You're being asked to build a parser.
The computer science theory behind compilers is extensive and complex. To keep it simple, I recommend reading Jack Crenshaw's compiler tutorial. It will show you in the first few chapters how to do exactly this by building a top-down recursive descent parser. His example is almost exactly what you're trying to do. It's in Pascal, but it's still easy enough to follow and the concept still applies.
Google for "jack crenshaw let's build a compiler", or browse to:
http://compilers.iecc.com/crenshaw/
That's actually pretty complicated if you want to get it 100% right. The direction to research would have to do with the keywords "finite state automata", "regular expressions" (not to be confused with Regex) and "context-free grammars". Also there's an approach called "recursive descent parser" but you'll need to understand the above concepts first.
Matching brackets and parenthesis is easy.
string expression = "(a + b + (c + d) )";
int brackets = 0;
int parenthesis = 0;
foreach(char c in expression)
{
if(c == '(') ) parenthesis++;
if(c == ')') ) parenthesis--;
if(parenthesis < 0) { // ERROR!!! }
// Same logic with brackets
}
if (parenthesis != 0) { ERROR!!! }
Also, I would use a similar approach with "statements mergers" ( +, -, *, / ) and "statements comparators" ( ==, !=, <, <=, ... )
For each word in your expression, only a few valid keywords can follow.
As it was mentionned before, writing parsers is a difficult task, planning every exception case right away is hardly possible. This should be the general idea instead of a definitive solution.
On a final note, it is perfectly ok to have multiple passes to scan for different things. First pass is brackts/parenthesis only, then check for something else in another loop.

Why does Scala's semicolon inference fail here?

On compiling the following code with Scala 2.7.3,
package spoj
object Prime1 {
def main(args: Array[String]) {
def isPrime(n: Int) = (n != 1) && (2 to n/2 forall (n % _ != 0))
val read = new java.util.Scanner(System.in)
var nTests = read nextInt // [*]
while(nTests > 0) {
val (start, end) = (read nextInt, read nextInt)
start to end filter(isPrime(_)) foreach println
println
nTests -= 1
}
}
}
I get the following compile time error :
PRIME1.scala:8: error: illegal start of simple expression
while(nTests > 0) {
^
PRIME1.scala:14: error: block must end in result expression, not in definition
}
^
two errors found
When I add a semicolon at the end of the line commented as [*], the program compiles fine. Can anyone please explain why does Scala's semicolon inference fail to work on that particular line?
Is it because scala is assuming that you are using the syntax a foo b (equivalent to a.foo(b)) in your call to readInt. That is, it assumes that the while loop is the argument to readInt (recall that every expression has a type) and hence the last statement is a declaration:
var ntests = read nextInt x
wherex is your while block.
I must say that, as a point of preference, I've now returned to using the usual a.foo(b) syntax over a foo b unless specifically working with a DSL which was designed with that use in mind (like actors' a ! b). It makes things much clearer in general and you don't get bitten by weird stuff like this!
Additional comment to the answer by oxbow_lakes...
var ntests = read nextInt()
Should fix things for you as an alternative to the semicolon
To add a little more about the semicolon inference, Scala actually does this in two stages. First it infers a special token called nl by the language spec. The parser allows nl to be used as a statement separator, as well as semicolons. However, nl is also permitted in a few other places by the grammar. In particular, a single nl is allowed after infix operators when the first token on the next line can start an expression -- and while can start an expression, which is why it interprets it that way. Unfortunately, although while can start a expression, a while statement cannot be used in an infix expression, hence the error. Personally, it seems a rather quirky way for the parser to work, but there's quite plausibly a sane rationale behind it for all I know!
As yet another option to the others suggested, putting a blank newline between your [*] line and the while line will also fix the problem, because only a single nl is permitted after infix operators, so multiple nls forces a different interpretation by the parser.