Reading multiple indices on MagmaCollections

[Brent Pinkney]

Hi,
> Hi Brent, in fact, I've been thinking about this very problem lately.
> This work is critical for Lava and extremely useful for plain Magma
> programs too.  Yes, I'll help out.
It is critical for Lava but I really need it for a plain of Magma programme.

> Just for clarity and context, the full series of conversions from SQL
> to LavaResultTable is, (please fill in as necessary):

SQL					parse		-->	Abstract Syntax Tree (AST)
AST + Schema			analysis		-->	Canonical Syntax Tree (CST)
CST + Schema			optimisation	-->	Optimised Syntax Tree (OST) -  optional step
OST/CST				generation	-->	Smalltalk code
Smalltalk code			compile		-->	Smalltalk classes + methods (processor)
processor + session	execute		-->	result

> Wow.
It is not so scary in baby-steps. The real problem is how poor SQL is as a 
language: big, ambiguous, and hard to parse.

> Since you've got Lava, I guess most of this work is concentrated
> between ?? and creation of the temporary "result" MaHashIndex.  

I think we will get a better solution if we focus just on plain Magma with one 
eye open to Lava. It is however useful to start from a SQL query as it is a 
well understood point of departure.

>   - deciding the best client API's
>   - generation of the clause-tree
>   - parsing the clause-tree
>   - enhnancing MaHashIndex to quickly conjunct
>   - efficiently providing a Reader that can page through the result set

Agreed
> Please fill in anything I've forgotten.  How would you like to tackle?

> Will your actual Lava code-generation be affected by the API's that
> create the clause-tree?  Hopefully not.

The LaOptimiser just emits the appropriate Smalltalk during this phase. This 
really is not a problem.

> I have an idea for the backend work needed on the MaHashIndexes.  I
> haven't tried to implement it yet, but will post my notes separately
> that you or anyone may comment.

Ok - I have some initial ideas on the client api. I will send them in a 
separate message.

Brent