Love your attitude—-both submitting early, and learning from submitting too early. Mind giving us f-expression virgins a note or two on why they’re awesome?
I can try, though as the night wears on my brain gets fuzzier...
Basically, f-expressions unify macros and functions. This combined thing is called a "combiner". It works by being different from a macro/function in two main ways: 1) It has a "wrap level" that encodes how many times arguments to this combiner should be evaluated when it is called and 2) it has an extra parameter that receives the dynamic calling environment when the combiner is called. A normal function is simply a combiner with a wrap level of 1 and ignores the dynamic environment parameter. A macro is a combiner with a wrap level of 0 and first constructs new code out of the passed regular parameters before evaluating the entire thing using the dynamic environment that was passed in (using an eval function, like you would find in JS or Python).
The cool bit is that these are all first class, available at runtime, and subsume not only functions and macros but also all special forms in the language! "if" and "let" and "while" can all be normal combiners (albeit built-in ones), and you can define new ones as easily as writing a function would be.
This makes the language much simpler and uniform while gaining expressive power, and fixes a lot of rough edges. (For instance, you can't do the equivalent of "(map and '(true false true true))" in Scheme, because "and" is a macro and thus can't be passed to higher-order functions. It can work just fine in a language built around f-expressions, though!)
The major downside to f-expressions is that they tend to be unbearably slow, since they (normally) prevent pretty much all optimization and remain to re-run over and over at runtime (unlike macros which would be expanded once into new code, and permit optimization and compilation after that).
I've managed to create a partial evaluator + compiler for f-expressions in a pure functional language that can remove most of the overhead for f-expressions that fall in the function-like and macro-like categories, resulting in a reasonably fast language where only the more exotic f-expressions fall back to slower interpretation. Writing it up in an academic paper is proving to be almost as hard and time consuming as solving the problem in the first place, but it'll get there, eventually.
