[ 
https://issues.apache.org/jira/browse/METRON-1277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16223797#comment-16223797
 ] 

ASF GitHub Bot commented on METRON-1277:
----------------------------------------

Github user ottobackwards commented on a diff in the pull request:

    https://github.com/apache/metron/pull/814#discussion_r147567984
  
    --- Diff: metron-stellar/stellar-common/README.md ---
    @@ -100,6 +102,28 @@ In the core language functions, we support basic 
functional programming primitiv
     * `FILTER` - Filters a list by a predicate in the form of a lambda 
expression.  For instance `FILTER([ 'foo', 'bar'], (x ) -> x == 'foo' )` 
returns `[ 'foo' ]`
     * `REDUCE` - Applies a function over a list of input.  For instance 
`REDUCE([ 1, 2, 3], (sum, x) -> sum + x, 0 )` returns `6`
     
    +### Stellar Language Match Expression
    +
    +Stellar provides the capability to write match expressions, which are 
similar to switch statements commonly found in c like languages, but more like
    +Scala's match.
    +
    +The syntax is:
    +* `match{ logical_expression1 : evaluation expression1, 
logical_expression2 : evaluation_expression2` : A match expression with no 
default
    +* `match{ logical_expression1 : evaluation expression1, 
logical_expression2 : evaluation_expression2, default : default_expression}` : 
A match expression with a default expression
    +
    +Where:
    +
    +* `logical_expression` is a Stellar expression that evaluates to true or 
false.  For instance `var > 0` or `var > 0 AND var2 == 'foo'`
    --- End diff --
    
    ```bash
    Please note that functions are loading lazily in the background and will be 
unavailable until loaded fully.
    [Stellar]>>> Functions loaded, you may refer to functions now...
    
    [Stellar]>>> foo := 500
    [Stellar]>>> match{ foo < 100 : THROW('oops'), foo > 200 : 'ok', default : 
THROW('exception thrown') }
    ok
    [Stellar]>>>
    ```
    
    I don't see that.
    
    Also, if you check the last test in TestMatch you will see I have a test 
for this kind of thing.



> STELLAR Add Match functionality to language
> -------------------------------------------
>
>                 Key: METRON-1277
>                 URL: https://issues.apache.org/jira/browse/METRON-1277
>             Project: Metron
>          Issue Type: New Feature
>            Reporter: Otto Fowler
>            Assignee: Otto Fowler
>
> From dev list:
> ------------
> Hi All, 
> It's high time that Stellar supports some form of conditional that is 
> beyond if/then/else. Right now, the way to do fall-through conditionals is: 
> if x < 10 then 'info' else if x >= 10 && x <= 20 then 'warn' else 'critical' 
> That becomes non-scalable very quickly. I wanted to facilitate a 
> discussion with the community on the syntax. I'll give a few options and 
> you guys/gals can come up with your own suggestions too, but I wanted to 
> frame teh conversation. 
> *MAP-BASED SWITCH* 
> With the advent of METRON-1254 (https://github.com/apache/metron/pull/801), 
> we could enable (from a language perspective in Stellar) multi-part 
> conditionals or switch/case style statements. To wit: 
> MAP_GET(true, { x < 10 : 'info', x >= 10 && x <= 20 : 'warn', x > 20 : 
> 'critical' }) 
> Or, with a convenience function: 
> CASE( { x < 10 : 'info', x >= 10 && x <= 20 : 'warn', x > 20 : 'critical' } 
> ) 
> The issue with this is that the last true condition wins because we're 
> using a map. 
> *LIST-BASED SWITCH* 
> We could correct this by adding a list of pairs construction to stellar: 
> CASE( [ x < 10 : 'info', x <= 20 : 'warn'], 'critical') 
> This would enable us to allow the first true condition to win, so the 
> second condition can be simpler and we could pass a default return value as 
> the final argument. 
> The downside to this, is that it requires a language enhancement (the list 
> of pairs construction you see there). 
> *LAMBDA FUNCTION-BASED SWITCH* 
> Some of the problems with the previous statements are that every 
> conditional has to be evaluated and there is no opportunity to short 
> circuit. They're all evaluated at parse-time rather than execution time. 
> We could, instead, construct a lambda function approach to this and support 
> short-circuiting in even complex conditionals: 
> CASE( real_variable_name, [ x -> x < 10 ? 'info', x -> x <= 20 ? 'warn' ], 
> 'critical') 
> or 
> CASE( real_variable_name, [ x -> if x < 10 then 'info', x -> if x <= 20 
> then 'warn' ], 'critical') 
> This would require lessening ?: (if/then/else) syntax to support to enable 
> just if without else conditions. This also has the benefit of allowing 
> simplifying the expression due to lambda function variable renaming 
> (real_variable_name can be much more complex (or even an expression) than 
> 'x'. 
> Creative other approaches to this are appreciated! 
> Thanks, 
> Casey 
> ----------------
> and ->
>  
> How about this:
> match(VAR_TO_VAL_ASSIGNMENT+) { BOOLEAN_STATEMENT(VALS) : LAMBDA(VALS), 
> BOOLEAN_STATEMENT(VALS) : LAMBDA(VALS) , LAMBDA(VALS)}
> * match = new keyword
> * match takes variable number of assignments, where the val assigned to is 
> available in the evaluation and the lambdas
> * match {} contains comma separated list of a statement that evaluates to a 
> boolean and a lambda
> * LAMBDA is executed on match, and it’s value is returned
> * no matches returns null or return of optional final statement, which is a 
> LAMBDA without a BOOLEAN_STATEMENT



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to