List comprehensions

[rolyp]

The simplest list comprehension notation we can get away with to support #276. Ranges of the form [e_1..e_2] are covered by #278.

• list comprehension prototype syntax in fluid/example/list-comprehension.fld
• replace unicode right arrow by -> in grammar and fix examples accordingly
• formalise comprehensions (syntax, semantics, fwd slicing, bwd slicing)
• implement fwd and bwd slicing rules for comprehensions – see Forward and backward slicing for desugaring #391
• extend surface language parser
  • guards
  • generators
  • declarations
  • qualifier sequences
  • list comprehension
• ListComp should have non-empty list of qualifiers
• promote current list comprehension tests to “normal” tests

[jamescheney]

This paper:

https://arxiv.org/abs/1408.1675

talks about forward / backward slicing for set/bag comprehensions. For lists, the complications related to repeatable indexing (that are addressed in the paper using prefix codes) should be avoidable.

It also might be interesting to generalize the treatment of "partial collections" to an ordered setting - in the paper, a bag or row can have a "row" or "rest of bag" hole representing unbounded other elements that we don't care about. For lists, we might want partial values to be things of the form

[1, □,3] ++ □ ++ [6,7,8] ++ □ ...

i.e. with multiple "sublist" holes. If arbitrary computations over lists are allowed, then encountering such a hole probably means you have to give up, but if you know you are doing a map, then you can take advantage of the independence of the different iterations.

[rolyp]

@min-nguyen Ok, looks like you’ve made good progress mocking up the list comprehension and convolution examples to see how they would look in Fluid. The next thing to do is to get the implementation compiling and tests running on your laptop. This should just be a question of making sure Node is installed and then running npm install (if you haven’t already done this) and then npm run browser-test, as per the README.

Once the tests are running locally a good starting task will be changing the grammar to replace the Unicode right arrow by ->. This means making the appropriate changes to src/grammar.ne and then regenerating the file Parse.ts by running nearleyc grammar.ne -o Parse.ts. The tests should rerun automatically if things are set up properly and the tests should fail because none of the examples will parse properly. Then it should just a question of doing a search-and-replace on the examples.

If you get stuck I’ll be able to help out on Monday. Once this workflow is in place we can start thinking about the changes needed to support list comprehensions.

[rolyp]

@min-nguyen Good to see progress on totalize (I suggest using UK spelling btw, i.e. totalise). Some quick feedback:

• from Just "" is probably a smell that indicates you should be writing fromJust absurd. And then if fromJust absurd $ lookup is a common pattern (as it seems to be), let’s introduce a helper for this (e.g. mustLookup).
• I’m not sure you need the ctrToDataTypeStr and dataTypeStrToCtrs shenanigans. Aside from the fact that ctrDataTypeMap is redundant with dataTypes, you should be able to get all the information you need from ctrToDataType and the definition of DataType.

Bit busy today but get me on Slack if you need to.