
On Nov 19, 2008, at 9:11 AM, Justin Bailey wrote:
On Tue, Nov 18, 2008 at 6:23 PM, Warren Harris
wrote: I am working on a query language translator, and although I feel that a monadic formulation would work well for this application, I've stumbled on a number of questions and difficulties that I thought the knowledgeable people here might be able to help me with.
HaskellDB takes a similar approach. It's "Query" monad allows you to build queries which are then translated to SQL by a "runQuery" function. Could your bind operation collect the 'input' expressions and then output them all at once via a "runTranslation" function?
Thanks for pointing this out. I had looked at Leigen & Meijer's paper a while back which describes this, and in one branch of my code taken a very similar approach by using an abstract datatype with phantom types to represent the target language. However, I had concluded (perhaps incorrectly) that the technique was not amenable to streaming the results back to the client without first constructing an in-memory list with a universal type representing the values returned. Now perhaps the in-memory list part was a bad conclusion since the queries can be decorated with translation functions capable of streaming the results out to another channel. However, the use of a universal type for the values would still seem to be required since there is no way to implement type-indexed values when the queries themselves are expressed as an abstract datatype rather than as functions. Am I overlooking something? As an aside, maybe I've been unduly concerned with wrapping the raw values in a universal type since I've found that in most cases for my target language I must deal with the possibility of null results, and must wrap most values in a Maybe type anyway. So I must pay the allocation cost in most cases... and with phantom types perhaps I can avoid the possibility of dynamic type errors due to unexpected data or ill-formed target queries.
Do you have to do in-place translation?
Not sure I follow. Warren