An interesting discussion about the distinction between callbacks and continuations over on SO has prompted this question.  By definition, a continuation is an abstract representation of the logic needed to complete a computation.  In most languages this manifests as a one argument procedure to which you pass whatever value needs continued processing.  In a purely functional language (where all functions are pure and first class citizens), I would think a continuation could be entirely modeled as a function.  This is, after all, how I've previously understood continuations up to this point.  However, the world is full of state (sigh..) and so the general definition does not require that a continuation capture program state -- it need only encompass intent.  To help my understanding, can an example be provided in a functional language where the continuation is expressed in a more abstract way than a function?  I know Scheme allows you to grab the current continuation in a first-class manner (call/cc), but even so, it seems that the one argument procedure passed to call/cc is simply given the current continuation in the form of another one argument procedure to which the call/cc'd function can apply its result.
What is an example of a continuation not implemented as a procedure?
programming languages;language agnostic;functional programming;functions;continuation
tl;dr; The type is the overarching abstraction over a continuationA continuation is the type of its inputs and outputsThe closest thing you will find to a non-procedure based continuation is likely the continuation monad in Haskell as it is expressed as a type, for which many functions may be used to interact with the type to interrupt, resume, backtrack, et al.You can encapsulate that closure in a type such as the Cont type in Haskell where you get the monad abstraction as a higher level abstraction, and there are other forms of abstraction over continuations you get when you look at the continuation as a type instead of simply a procedure, for instanceYou can take two continuations and do an alternative between them if the type follows the laws to be a monoidYou can abstract over the type to change the input or output types of the continuation if you encapsulate the closure in a type that abides the laws of a functorYou can arbitrarily and partially apply or decorate your continuation with functionality such as input validation or input conversion if you encapsulate the closure in a type that follows the laws of an applicative functorClosure vs. ProcedureAt the end of the day you're basically right; a continuation is a procedure, though I would rather refer to it as a closure. Often times continuations are best expressed as first class closures that have enclosed a bound environment. In a pure functional language you might say this is not particularly reasonable because you lack references; this is true but you can enclose values and single assignment makes enclosing the value vs. the reference the exact same thing. This gives rise to in Haskell:(\x -> \y -> insideYIcanAccess x (and y))A language that lacks the ability to enclose a binding environment may technically lack first class closures, but even then there is some environment (generally the global) which is available to the closure.So I would say it's more accurate to describe a continuation as: A closure being used in a particular way.ConclusionTo the question of Is a continuation implementable in any way other than a procedure? No. If you don't have first class functions you really can't have continuations as such (yes function pointers count as first class functions, so alternatively arbitrary memory access can suffice).Now to the question of Are there any ways to express a continuation in a more abstract way than a procedure? Expressing it as a type gives you a much greater abstraction, allowing you to treat the continuation in very general ways such that you can interact with the continuation in many more ways than just executing it.