06: Expression Support for Operating on Types

[dschwartznyc]

Feature Request

Description of Problem:

There are gaps in the support for expressions when operating on types.

1. Closures in Aggregations (CDM/DRR Gap): Operations like sort, max, and min frequently use closure blocks (e.g., sort [ item -> unit -> currency ]) in CDM and DRR (digital-regulatory-reporting). The generator currently ignores these blocks and produces standard Python sorted()/max() calls.

   // Exposes gap in SortOperation/MaxOperation
   func SortItems:
       inputs: items Item (0..*)
       output: sortedItems Item (0..*)
       set sortedItems:
           items sort [ item -> price -> amount ] // Generator ignores the [ ... ] block
   

2. Implicit Closure Parameters: Rosetta allows extract [ item -> attr ] or reduce [ a + b ] without naming parameters. The current generator expects parameters to be explicitly declared in the InlineFunction and fails with an error if they are missing.

   // Exposes gap in MapOperation/ReduceOperation
   func ImplicitClosure:
       inputs: items int (0..*)
       output: result int (0..1)
       set result:
           items 
               extract [ item * 2 ] // Fails: expects explicit 'item' parameter declaration
               reduce [ a + b ]     // Fails: expects explicit 'a, b' parameters
   

3. General one-of Expressions: In CDM, one-of is used as a stand-alone expression in functions and shortcuts. The generator only implements this behavior within type conditions.

   // Exposes gap in OneOfOperation (Expression)
   func CheckOneOf:
       inputs: msg Message (1..1)
       output: isValid boolean (1..1)
       set isValid:
           msg -> fieldA or msg -> fieldB one-of // Fails: Unsupported general expression
   

Potential Solutions:

There needs to be changes to the expression generation.