Lambda the Ultimate

I've sketched some ideas about slot-based interfaces as a way to turn method names into first-class citizens of the language, with an example of the resulting framework as applied to C++:

"Objects, slots, functors, duality "

The key idea is to treat objects as polymorphic functors and regard a method call like

x.foo(arg1,...,argn)

as an invocation of x where the first parameter (the slot) is an entity indicating the particular method called upon:

x(foo,arg1,...,argn)

If we now define a slot as a generalized functor accepting objects as their first parameter and with the following semantics:

foo(x,arg1,...,argn) --> x(foo,arg1,...,argn)

then objects and slots become dual notions, and many interesting patterns arise around method decoration, smart references, etc.

I wonder if these ideas have been already explored in a more general setting than the toy framework described here.

In brief
------

I'm porting an existing compiler/interpreter framework to Swift, from a more imperative code base. It currently exists in JavaScript (feh), Dart, and Objective-C. It has more-or-less the same (recursive descent) structure in all three languages; in particular, I use exceptions to immediately bail when I encounter a syntax error.

My proximal question is: how can I structure an exception-free parser to conveniently handle syntax errors? My more global question is: how do people do that in an idiomatically functional way?

Remarks
-------

Just about every line of parser code can (transitively) result in a syntax error. For example, to parse the language construct "split x into y" I write (roughly):

acceptToken(split)      // Could fail if split is misspelled
source = expression()   // Could fail if expression is faulty or missing
acceptToken(into)       // Could fail
dest = expression()     // Could fail
acceptToken(newline)    // Could fail
return new JoinNode(source, dest)

It is convenient to expect that any of these calls will throw an exception, in particular that lines subsequent to the failure will not execute. Repeated wrapping and testing each line is just the sort of thing exceptions are supposed to save us from. (Although I agree the details of handling exceptions — rolling back the program state — are almost impossible to get right.)

What I am looking for is a design architecture that will let me continue exploit the isomorphism between the grammar and the code structure: one term in the grammar maps to one line of parser code. Not one line of parser code, wrapped in conditional tests, with each line testing the success/failure of its predecessor.

There have been some suggestions in this thread:

https://devforums.apple.com/thread/227375?start=0&tstart=0

that involve optional types and comparisons to languages like Rust and Scala, but I did not see usable ideas from actual compiler writers. Suggestions or pointers/references welcome.