| > I haven’t seriously put thought into that use-case. … Do you explicitly require a map or list comprehensions or do you “broadcast” automatically, and if you do, what are the pitfalls? It’s all automatic. Basically, any function a→b can be used as [a]→[b], [[a]]→[[b]], and so on; functions with multiple arguments work similarly. In the intermediate language, each argument is then annotated with the amount by which it needs to be lifted. (So e.g. if `xs : [Int]`, then `10/xs` gets translated to something like `(/)({10,1}, {xs,0})`. As for pitfalls… well, I haven’t encountered all that many yet. The implementation is a little unprincipled at this point, but there’s probably some way to make it more rigorous. It’s basically as close as I can get to J or MATLAB in a typed language, and people don’t often have problems with broadcasting in those languages. > I have put some thought into something related which is aggregations. On a given table I want to be able to add a column which implements any mapAccum over the table, such as balance over time. The code generated would be table.accum(state: row: state + row.x) for example. The UI would make it easy to pick common accumulators and folds, but also trivial to write an expression. Your voltage current example would work like that. This does sound quite similar to what I’m doing, though perhaps more limited. > Incidentally [applying substitutions at the same time as unification] is needed if you want to combine two row types and assign a type to the expression. Hmm, interesting. You don’t happen to have a link, do you? (Though I seem to recall hearing TAPL has something about this… I really do need to read it one of these days.) > I might only have time to discuss ideas and no time to collaborate on dev right now, but happy to swap contact details. If you drop a mail anything@inflex.io I’ll reply via my personal email. Sure, that sounds great! I’ll send you an email now. |