Problem with list of lists

a!localVariables(
  local!a: {
    a!map(input: { 1, 3 }),
    a!map(input: { 2, 3 }),
    a!map(input: { 4, 5 }),
    a!map(input: { 5, 6 })
  },
  local!output: a!forEach(
    local!a.input,
    reduce(fn!product, 1, fv!item, 1)
  ),
  local!output
)

your input will convert into one single array instead of being separated into 4 different array if you declare using curly brackets. You have to declare using map to maintain the structure

Is there any way to convert the list of list(i.e {{1,3},{2,3},{4,5},{5,6}})  to a

list of map (i.e

{

a!map(input: { 1, 3 }),
a!map(input: { 2, 3 }),
a!map(input: { 4, 5 }),
a!map(input: { 5, 6 })
},) 

Appian does not handle list-of-lists well at all (and never has).  You can attempt to call a!forEach() over your list-of-lists, but there's no guarantee it won't just iterate over each item individaully.  It also largely depends on where you're getting your input data, which you haven't specified.

It's just an expression problem for practice

the problem is, in almost all contexts, a plain list-of-lists is handled by the Appian parsers as a flattened array (and it's hard or impossible to predict when it will or won't be, other than trial-and-error).  It's always safer to assume it will be.

Hi vickyr0501 ,

i tried solving the above problem with a foreach(). here is my code.

a!localVariables(
  local!input: { { 1, 3 }, { 2, 3 }, { 4, 5 }, { 5, 6 } },
  local!even: a!forEach(
    items: local!input,
    expression: if(mod(fv!index, 2) = 0, fv!item, {})
  ),
  local!odd: a!forEach(
    items: local!input,
    expression: if(mod(fv!index, 2) = 0, {}, fv!item)
  ),
  a!forEach(
    items: local!odd,
    expression: fv!item * (index(local!even, fv!index, 0))
  )
)

Really, everything we need to know about how appian (fails to) handle list-of-lists can be seen with how it resolves the value stored in local!input:

The only exception I've ever really seen to the above is how the result of merge() is treated - because for whatever reason, list-of-list data seems to be honored (to a certain extent) in this context (and perhaps this context alone).  It's very frustrating since merge() is pretty unintuitive to understand and to use for real-world cases.