- expression-oriented programming one of the great advances of FP
- expressions plug together like legos, making more malleable programming experience in-the-small
Write in an expression-oriented style, scoping variables as locally as possible:
let x = do {
let tmp = f();
tmp * tmp + 1
};
Use conditional statements as expressions, instead of awkward nested ternaries:
let x = do {
if (foo()) { f() }
else if (bar()) { g() }
else { h() }
};
Especially nice for templating languages like JSX:
return (
<nav>
<Home />
{
do {
if (loggedIn) {
<LogoutButton />
} else {
<LoginButton />
}
}
}
</nav>
)
- key refactoring principles:
do { <expr>; }
equivalent to<expr>
(do { <stmt> };)
equivalent to{ <stmt> }
- this semantic transparency is demonstrated by the semantics:
- Return the result of evaluating Body.
How to avoid either parsing conflict in statement context with do
-while
, or dangling-else type of ambiguity:
do do f(); while (x);
I have several alternatives I intend to explore here.
@cvoege actually I would actually want the promise, not the text in the file, that way I can use it with Promise.all/Promise.race later.
As an example of how you'd use it:
Without async do expressions it would wind up something like this:
Which while not terrible it feels unnecessary to still require IIFE with do expressions when it seems like the idea of do-expressions is do be able to do away with the semantics of IIFE so instead of this:
I can have this:
Not having the same for async feels like unnecessary symmetry breaking. Now while I understand eval doesn't actually consider
await
statements there's no reason it couldn't be created for the context ofasync do