y %>% f(x, ., z)  ===  f(x, y, z)

(it's probably a bit more involved because %>% also supports

  a %>% f(b)  ===  f(a, b)

---

[1] https://en.wikipedia.org/wiki/Fexpr

[2] think `_` in python etc. R uses dots instead of underscores

  >>> x = [0]
  >>> for x in xs:
  ...   print(x)
  ...   xs.append(x+1)

tbh i haven't checked, but isn't the transpilation step for typescript just stripping out the type annotations? TSC is build-time only, so it won't factor into your bundle size, and i can't imagine the generated JS is significantly bigger than source -- if anything, it should be smaller ;p

I would guess running the TypeScript output through the Google Closure compiler (or adding similar optimizations directly to the TypeScript compiler) could make TypeScript bundles comparable to JavaScript bundles or smaller. It looks like people see significant improvements running TypeScript output through Closure compared to just WebPack [0].

[0]: https://medium.com/appmonet/using-closure-compilers-advanced...

[0] https://dev.to/haruanm/does-typescript-increase-the-bundle-s...

Consider this example:

  # base R
  starwars[starwars$height < 200 & starwars$gender == "male", ]
  
  # dplyr
  starwars %>% filter(
    height < 200,
    gender == "male"
  )

Where'd `height` and `gender` come from in the dplyr version? They're just columns in a DF, not variables, and yet they act like variables... Well that's the dplyr magic baby!

dplyr (and other tidystuff) achieves this "niceness" by doing a whole bunch of what amounts to gnarly metaprogramming[1] -- that example was taken from a whole big chapter about "Tidy evalutation", describing how it does all this quote()-ing and eval()-ing under the hood to make the "nicer" version work. it's (arguably) more pleasant to read and write, but much harder to actually understand -- "easy, but not simple", to paraphrase a slightly tired phrase.

---

[1] IIRC it works something like this. the expressions

  height < 200
  gender == "male"

> My experience is that this weird evaluation order stuff is only confusing for students with a lot of programming experience who already expect nice lexical scope

fair point, but for the most part, R itself does use pretty standard lexical scoping unless you opt into "non-standard evaluation" by using `substitute`[1]. so building a mental model of lexical scoping and "standard evaluation" is a pretty important thing to learn. after that, the student can see how quoting can "break" it, or at least be able to understand a sentence like "you know how evaluation usually works? this is different! but don't worry about it too much for now". and i think dropping someone new straight into tidyverse stuff gets in the way of this process.

> and even then, base R isn’t any simpler: the confusing evaluation order is built into R itself at the deepest level.

i mean, quoting can't really work without being deeply integrated into the language, can it? besides:

- AFAICT base R data manipulation functions don't use it a lot. [2]

- for the most part, R's evaluation order can be ignored (at a certain learning stage) because it's not observable if you stick to pure stuff, which you probably should anyway.

---

[1] http://adv-r.had.co.nz/Computing-on-the-language.html#captur...

[2] admittedly, stuff with `formula`s is similarly wacky, and if you're doing stats you're going to run into that sooner or later...

But try out this bit of base R:

> hello = function(cats, dogs) { return(cats) }

> hello(100, honk) # where honk has never been defined

> hello(100, print("hello!"))

> hello(100)

---

[1] well, not "natural", but aligned with how math stuff is usually taught/done. in most cases, when asked to evaluate `f(x+1)`, you first do `x+1` and then take `f(_)` of that.

tldr: basically, R passes all function arguments as bundles of `(expr_ast, env)` [called "promises"]. normally, they get evaluated upon first use, but you can also access the AST and mess around with it. AFAIK this is called an "Fexpr" in the LISP world.

(originally i had a nice summary, but my phone died mid-writing and i'm not typing all that again, sorry!)

it's very powerful (at the cost of being slow and, i imagine, impossible to optimize). it enables lots of little DSLs everywhere - e.g. lm() from stats, aes() from ggplot2, any dplyr function - which can be both a blessing and a curse.

  x = match y:
    case 0: "zero"
    case 1: "one"
    case x:
      y = f(x)
      y+y
  
  print(x)

(yes, i know you could use the walrus operator in the third case)

(also, if anyone wants to reply with "use a named function because READABILITY", please save it)

In general, breaking Python's syntax rules to introduce block expressions or what you want to call it seems like a steep price to pay for what amounts to syntactic sugar in the end.

However, your proposal actually misses the mark in the same way as the actual match/case does as well. What would be /really/ handy in Python is something like

    {'some_key': bind_value_to_this_name} = a_mapping

I think you should read the PEPs on match/case, these things have actually been considered. One idea was to introduce a keyword to say which variables are inputs and which are outputs, but that also violates the general grammar in a way that isn't very nice.

The accepted solution has warts, I agree, but at some point you just have to accept that you can't reach some perfect solution.

i'm at peace with that :) [1]

> In general, breaking Python's syntax rules to introduce block expressions or what you want to call it seems like a steep price to pay for what amounts to syntactic sugar in the end.

that's your opinion, i disagree! i think Python would be a better, more pleasant to use language if they figured this out. a girl can dream, ok?

> What would be /really/ handy in Python is something like

  {'some_key': bind_value_to_this_name} = a_mapping

> I think you should read the PEPs on match/case

i read them when they came out. i'm assuming you're referring to this section from PEP 622:

> "In most other languages pattern matching is represented by an expression, not statement. But making it an expression would be inconsistent with other syntactic choices in Python."

https://www.python.org/dev/peps/pep-0622/#id77

i believe Python's statement-orientatation kinda sucks, so to me this is just "things aren't great, let's stay consistent with that". yeah, yeah, "use a different language if you don't like it" etc.

---

[1] well, maybe not quite, after all i'm here arguing about it.

[2] `match` uses patterns like the one you described in `case` arms, but is distinct from them. i don't see why dict-destructuring syntax couldn't be added in a separate PEP.

looks like i messed up my PEPs -- i linked to PEP622, which was superseded by PEP635 [1]. the gist of it hasn't changed though.

---

[1] https://www.python.org/dev/peps/pep-0635/#the-match-statemen..., Ctrl+F "Statement vs. Expression"

I'm less interested in the syntax (will take anything accepted by a modified ast module), more in the semantics.

Here's a syntax I played with in the past:

  def area(s: Shape):
    pmatch(s):
        Circle(c):
            pi * c.r * c.r
        Rectangle(w, h):
            w * h
    ;;

  def times10(i):
    x = pmatch(i):
        1:
            10
        2:
            20
    ;;
    return x

  * Had to be pmatch, since match is more likely to run into namespace collision with existing code.
  * The delimiter `;;` at the end was necessary to avoid ambiguity in the grammar for the old parser. Perhaps things are different with the new PEG parser.

I’d be curious if currently available vaccines stimulate such preexisting antibody-producing bone marrow cells of past COVID patients (which sounds more optimal on the face of it), or they trigger yet another variety of antibodies to be produced in addition to the “native” one.

[0] https://www.nature.com/articles/d41586-021-01442-9#ref-CR1 “Had COVID? You’ll probably make antibodies for a lifetime”

If antibodies fall off quickly from an actual infection, why would this not also happen for the antibodies produced because of taking the vaccine?

it's basically continuation-passing-style (`a -> m b` is the "continuation"), you might as well ask "why can you represent so many control-flow things using CPS?". idk why, but you can!

from another angle, you could compare Monad with the less powerful Applicative. a formulation[0] that's easier to parse than the usual one[1] is:

  class Functor f => Applicative f where
    unit :: f ()
    pair :: f a -> f b -> f (a, b)

  >>=  (Monad)        Promise.then
  pair (Applicative) ≈ Promise.all
  unit   (Applicative) =
  return (Monad)       = Promise.resolve

---

[0] Called "Monoidal" here: https://stackoverflow.com/q/45267953 [1] https://en.m.wikibooks.org/wiki/Haskell/Applicative_functors...

"avoid success at all costs" is usually meant to be parsed as "avoid [success at all costs]" i.e. don't compromise the language just to make it more popular.

https://news.ycombinator.com/item?id=12056169

  import * as $ from '@appliedblockchain/assert-combinators'

  const validateFooBar = (
    $.object({
      foo: $.string,
      bar: $.boolean
    })
  )
  // probably roughly equivalent to
  /*
  const validateFooBar = (x) => {
    console.assert(
      typeof x === 'object' &&
      typeof x.foo === 'string' &&
      typeof x.bar === 'boolean'
    )
    return x
  }
  */


  const test1 = { foo: "abc", bar: false }
  const test2 = { foo: 0, quux: true } 
  const { foo, bar } = validateFooBar(test1) // ok
  const oops = validateFooBar(test2) // throws error

https://github.com/appliedblockchain/assert-combinators/blob...

https://github.com/appliedblockchain/assert-combinators/blob...