Function composition operator #258
Comments
|
I'm unsure how often this chain of single-function arguments occurs
(especially in the data management context we are exploring) and don't
know how we can find out (except to wait and see what functions get used).
Some other options include:
* use unix pipe syntax e.g. x|a|b|c where x is an expression and a,b,c
are one-argument functions
* use jquery-like method calls with chaining: x.a().b().c()
Note that with both of these the order of function application is left
to right instead of the right to left; I think that might be more
natural for non-programmers, to start with the "input" and then have the
functions applied in the order you read them instead of having to
remember to invert everything? On the other hand if they've done a lot
of math they'll expect the opposite; a conundrum.
But I do wonder whether this kind of chaining of functions is good for
non-programmers, or if they might be better off defining a sequence of
intermediate variables/properties a=f(x), b=g(a), c=h(b) etc. This has
the advantage, in our reactive model, of creating variables whose value
can be inspected when they are trying to figure out what went wrong.
A lot of this depends on really understanding our target audience, and
since there's actually more than one, it's a challenge!
…On 8/5/2017 11:26 PM, Lea Verou wrote:
Currently, expressions can require a lot of nested parentheses, which
is something even seasoned programmers often make err on 1
<https://twitter.com/LeaVerou/status/892308056092037120>. One way to
solve it would be to try to perform fixup and add forgotten parens or
remove extra parens if expression evaluation fails (is this a good idea?).
Another way would be to design the syntax in such a way that
unnecessary parens are eliminated. A lot of the time, the output of
one function is the input of another, with no extra arguments. We
could introduce a function composition operator that eliminates
parentheses from such function calls, akin to the one in Maths’ where
g∘f(x) = g(f(x)).
For example, with such an operator, an expression like
|readable(to(filename(image), '.'))| would become |readable ∘
to(filename(image), '.')|.
Obviously, we can’t use ∘ for the actual operator, since that would be
a pain to type. We could use the actual word |of|, which is how such
function calls are often read anyway. The example would then read
|readable of to(filename(image), '.')|, which is not terribly readable
(oh the irony), but is not too bad. Most importantly, it seems to
really improve things in terms of parens: even by removing 1 pair of
nested parens, it became much easier to balance them.
Thoughts?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#258>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABFpXgSPFttAFgo8LB88UYVYpqLa71_oks5sVTJWgaJpZM4OuoAI>.
|
|
Good ideas re: inverse order and pipe! Yet another reason for this operator: that order is much more natural. A bit concerned that pipe might be confused with OR by those that have used JS. Now that the order would be reversed, what about The operator could also work by currying, where
No conundrum, I think we can safely say that the population that has done a lot of maths is comparatively fairly small :P
Intermediate variables are already possible, by defining properties whose value is an expression. Few people used them in the user study. |
|
One issue with the pipe syntax is that it's not directional, nothing indicates flow, whereas something like |
|
Sorry; paper deadline. I'll try to keep up the discussions. I like the then syntax; also makes it less likely users will consider it counterintuitively contradicting the normal a(b(c function application order. Note that the first function in the then chain can be allowed to take multiple arguments; (f then g then h)(x,y). Also note potential ambiguity if some exprs return functions; e.g. f then g (x) (y) could mean ((f then g)(x))(y) or (f then g(x))(y) As for intermediate values, I know they are possible; my point was that maybe they should be encouraged (preferentially over complex expressions), not least because they make debugging easier. |
|
Some more prior art: VueJS and AngularJS support "filters" for formatting data, which are basically functions, and they are combined with a pipe ( |
Currently, expressions can require a lot of nested parentheses, which is something even seasoned programmers often err on 1. One way to solve it would be to try to perform fixup and add forgotten parens or remove extra parens if expression evaluation fails (is this a good idea?).
Another way would be to design the syntax in such a way that unnecessary parens are eliminated. A lot of the time, the output of one function is the input of another, with no extra arguments. We could introduce a function composition operator that eliminates parentheses from such function calls, like to the one in Maths where g∘f(x) = g(f(x)).
For example, with such an operator, an expression like
readable(to(filename(image), '.'))would becomereadable ∘ to(filename(image), '.').Obviously, we can’t use ∘ for the actual operator, since that would be a pain to type. We could use the actual word
of, which is how such function calls are often read anyway. The example would then readreadable of to(filename(image), '.'), which is not terribly readable (oh the irony), but is not too bad. Most importantly, it seems to really improve things in terms of parens: even by removing 1 pair of nested parens, it became much easier to balance them.Alternatively, it could be a non-word operator, e.g.
<<. The example would then becomereadable << to(filename(image), '.').Thoughts?
The text was updated successfully, but these errors were encountered: