I was an entrepreneur (failed twice), and I'm now a professor.
Being a pre-tenure professor is way more terrifying than being an entrepreneur was.
And, depending on the field, between 25% and 75% of your salary as a professor will come from being able to procure external funding.
If you can't convince the funding agencies to pay you, then tenure buys you an office, a teaching load and health care.
It's been terrifying for me because my hit rate is about the same as Matt's. I've had very little luck getting funding for my research.
And, at the last funding panel I served on, the funding rate was down to 5%. My own fund-seeking overhead is now at 60% of my time, and I'm still not getting any.
Either we have too many scientists, or not enough science funding. I don't think the current system is sustainable.
In short, you can use the macros to hide the context-switching (yielding).
You could, for instance, force every function to perform a context switch right after its called. Since languages like Scheme encode even loops with function call, you're guaranteed to eventually hit a switch point. (And, if you allow other looping constructs, you could use macros to hide a yield inside them as well.)
When I taught advanced compilers last semester, one of the projects was a Scheme-to-C compiler that implemented first-class continuations via call/cc.
I realized when going over that material, however, that most students didn't know what a continuation was, or how to use them, so I created a "by-example" tutorial:
For anyone that uses an ML (e.g. OCaml), Haskell or Scala, Milner was responsible for the Hindley-Milner type system and inference algorithm that sits at the foundation of these languages.
It ignited a wave of research into type theory that continues to this day, yet in many ways, Hindley-Milner is still the most significant contribution to the field.
I remember reading his original paper on polymorphic typing for my qualifiers and being struck by the elegance and approachability of his writing.
Back when I took calculus in high school, the instructor asked for a show of hands for first-borns. All hands but one went up--well above 80%. I've wondered why that was so ever since. Why weren't middle and younger children pushing themselves to get into the "advanced" math classes?
* Does the transfer function not need to take some input other than the state?
It depends on how you're encoding things. You might want to supply the I in I/O as an extra parameter to the transfer function.
Or, you could kick off the execution with the state containing a (possibly infinite) sequence representing all of the I/O events it will encounter during execution.
For the most part, transfer functions operate on just states.
* Can you convert a denotational semantics to an operational semantics (and vice versa)? Is there any value in doing this?
Yes, Olivier Danvy has a strong research program in this area. He has a battery of techniques that allow you to (almost) mechanically calculate one kind of semantics from another.
In many cases, calculating an operational semantics from a denotational semantics is the easiest way to prove their equivalence.
If you're wondering what things like "operational" and "denotational" mean and what they look like in code, I created this article for my compilers students:
* A denotational semantics is a function M : Program -> (Value -> Value) that maps a program to a mathematical function.
* An operational semantics is a relation (=>) between consecutive machine states. That is, if state => state' holds, then the machine transitions from state to state'.
* The relation in a "big-step" operational semantics need not be decidable. Big-step relations are usually recursive.
* The relation in a "small-step" operational semantics must be decidable.
* When you implement a transition relation, =>, it's usually implemented as a function. That is, if you have a relation R \subseteq State x State, you can encode this as a "transfer function" f : State -> 2^State.
Herb Simon noted the optimal solution is often infeasible a long time ago.
He argued that economic agents rarely finding a satisfying solution to their constraints, and instead choose a "satisficing" or "good-enough" solution.
Simon also noted that the satisficing solution found by humans is often close to the optimal solution.
He got (and deserved) a Nobel prize for these two observations.
I find work of the flavor "X reduces to P = NP, so Nyah!" to be deeply unsatisfying and misleading.
For problems of human importance, good-enough solutions to NP problems can often be found in a reasonable amount of time.
In fact, state-of-the-art SAT solvers are mind-bogglingly fast (on average). They can find solutions in seconds, where the theoretical worst case solution time is many-fold the expected lifetime of the universe.
Generating a hard instance of SAT is actually hard to do. One of the few reliable techniques we know of is to encode prime factorization into a circuit. This is good news for crypto, but bad news for anyone looking to show the real-world intractability of a process by reducing it to P=NP. Few processes in nature actually mimic prime factorization or graph isomorphism.