Roadmap for hackage release?

[martyall1]

I would just like to ask what the authors thoughts are for what remains to be done before this can be on hackage. Can you highlight any of the existing issues that need to be addressed? Are there some which are not listed? I'd like to start contributing in whatever direction will lead to this if I can.

[martyall1]

@k0001 do you want to comment on this one?

[k0001]

@martyall even though the current tisch code, as it stands, is expected to work correctly, I am not satisfied about some things and want to change them before moving forward with pushing this to Hackage (which comes with a commitment to maintenance).

The main two things I want to change are:

1. Use flay instead of HLists everywhere. The rationale for this is simplifying the API and UX, as well as improving error messages and field time access for large rows.

2. Do not rely on opaleye anymore. The rationale for this is avoiding the additional level of indirection which complicates the internals of tisch, as well as decoupling tisch roadmap from opaleye's roadmap.

After those those things are in place, I look forward to pushing a stable version to Hackage to be maintained for the foreseeable future.

[k0001]

Also, something else: I would like tisch to make use of linear types for its connection handling machinery http://www.tweag.io/posts/2017-03-13-linear-types.html

[martyall1]

Thanks for getting back. I can't tell if any of the current branches are working toward these goals, but again if there is some kind of roadmap for working on these stories I'm glad to try to help if you want it. All I would need is maybe some kind of story board, or list of checkboxes, or whatever. Keep me posted.

[k0001]

@martyall no, I haven't started any work towards this yet. I'll try and make the process public so that you and others can get involved. Thanks :)

[boj]

I'm using tisch at our company knowing the API will be in flux for awhile. We'd be happy to help test and submit any bug reports as things change.