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

Ok, this makes sense. I will refactor it so that low level facilities remain
in the delite framework, and also the separate collections dsl.

Cheers,
Alex

On Sat, Oct 8, 2011 at 1:27 PM, Tiark Rompf <
reply@reply.github.com>wrote:

> 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
>
> --
> Reply to this email directly or view it on GitHub:
>
> https://github.com/vjovanovic/Delite/commit/ff82c104f7408c8f661b394ed40691284d8ee8b4#commitcomment-638865
>