vjovanovic/Delite — comment on commit ff82c104f7408c8f661b394ed40691284d8ee8b4
File:  line 0
By TiarkRompf:

It's not super critical right now and we can still refactor and move things around later. In general however we should try to be as modular as possible and have mostly infrastructure stuff in 'framework' while the user-facing apis are under dsls (check the division between OptiML vector and matrix classes and DeliteOps.scala for example). I think a good way to structure things would be to have both a collections dsl (which really is more of a dsl module that can also be mixed in by other dsls) containing the user-facing abstractions, and extend 'framework' to support the underlying stuff (low-level support for hash tables, emitter abstraction, that kind of thing). This will allow us to use the low-level things for other dsls, too, which for example might want to use hash tables internally but provide an api different from collections. OptiQL is one such example: hash tables will be needed for groupBy and joins but the api is more like SQL or LINQ than like Scala collections. And as i already mentioned, with any changes to 'framework' we need to make sure that we do not break existing stuff like OptiML in any fundamental way.

Cheers,
- Tiark

On Oct 8, 2011, at 10:19 AM, Aleksandar Prokopec wrote:

> Hi,
>
> I had to make the code generation aware of the emitter abstraction, so I moved the whole thing to the framework. It was my understanding that we want to so this at one point. I'll add some tests, though.
>
> Alex