Haskell Summer of Code 2018?

[saurabhnanda]

I'm planning to propose a few ideas for pg-simple in HSoC 2017. Is anyone else interested in mentoring? Importantly, can we get a time-window where PRs are actively reviewed and merged?

Off the top of my head:

• Fix error messages
• Benchmark and improve performance
• Implement bind/execute
• Fix "hodor" parsing

[lpsmith]

Well, considering my personal needs, postgresql-simple is currently on the backburner, though I want to try to get a release out within the next week or two. I don't know what this coming year has in store for me, but the most reliable way to get and keep my attention would be to pay for my time, which is available through Iterative Systems. I may be interested in mentoring.

I'm absolutely in favor of the first two issues you list. I'm not sure exactly what you mean by the third, do you mean parameter-level protocols? I'm in favor of that, though it's quite a lot of work, and it may be tricky to maintain backwards compatibility and have a nice API in the end. If you mean Postgres's SQL commands PREPARE and EXECUTE, maybe, but I'm less enthusiastic. (As things currently stand, there is nothing stopping people from using those via the public API.)

The fourth issue is kinda tricky. I understand why you might see the current parsing interface as a bit silly, but it's actually capable of much more, it's just that typical parsing needs are simple. For the common 'hodor' case, there are Generic instances for FromRow and ToRow that need to be documented, and it might be nice to include some form of Template Haskell as an alternative.

That said, I am not entirely satisfied with the parsing interface, and am very much interested in improving it. What I'd like to see is some kind of type-level programming so that we could hoist type-checking to once-per-result instead of the current once-per-row, and also be able to know what rows are consumed by a parser so that we could (for example) write a generic instance FromRow a => FromRow (Maybe a). How well this would fit into a HSoC type of project I'm less than clear about, as there are a lot of unknowns here that I think have a high chance of leading to failure (of at least this part of the project.)

[saurabhnanda]

but the most reliable way to get and keep my attention would be to pay for my time, which is available through Iterative Systems.

I wouldn't mind fast-tracking this work by giving out a commercial contract for it, but you being based in US and me being based in India, makes it near impossible. Is there any other commercial user interested in paying for fixing these issues? Maybe all of us can contribute.

And the very reason I brought this discussion up is because GSoC gives us a unique opportunity where Google funds this development. However, the project maintainer (you, or someone else) would stil need to set aside time to mentor students and merge PRs.

Coming to the specific issues:

do you mean parameter-level protocols? I'm in favor of that, though it's quite a lot of work, and it may be tricky to maintain backwards compatibility and have a nice API in the end. If you mean Postgres's SQL commands PREPARE and EXECUTE, maybe, but I'm less enthusiastic. (As things currently stand, there is nothing stopping people from using those via the public API.)

I'm not sure what you mean by parameter-level protocols? Any link? I meant PREPARE/EXECUTE. How can one currently do this via the public API?

For the fourth case, why isn't a simple interface where each row is handed off to the user in the form of a map or a [(colName, byteString)] an options?

====

The core question is, would the PG simple project be interested in participating in GSoC/HSoC? If yes, then now is the time to organize and plan.

[lpsmith]

I wouldn't mind fast-tracking this work by giving out a commercial contract for it, but you being based in US and me being based in India, makes it near impossible.

Oh, believe me, I understand quite well that this does result in a number of additional complications, some of which I don't understand. But, I don't think these issues are insurmountable. Let's discuss over email. I'll send you an email at your Vacation Labs address soon-ish.

Is there any other commercial user interested in paying for fixing these issues? Maybe all of us can contribute.

Not that I'm aware of. However, that would be another approach.

And the very reason I brought this discussion up is because GSoC gives us a unique opportunity where Google funds this development.

IIRC, Haskell actually has not received funding from Google the last few years, and the HSoC has instead been funded by a few individuals and companies. I haven't really been involved, so I don't know what this implies, exactly, or if we are attempting to re-establish ourselves as a GSoC participant.

I'm not sure what you mean by parameter-level protocols? Any link?

Err, I meant protocol-level parameters. My bad. The frontend/backend protocol isn't as nicely documented as I would hope, but basically it's where you use $1, $2, etc inside the SQL string as placeholders for the parameter, and then send each parameter as a (Type Oid, format (text or binary), bytestring (length-delimited)) triple inside a protocol message instead of putting it inside the SQL.

See for example, execParams, which, IIRC (I may be slightly incorrect), basically sends a Parse message followed immediately by a Bind message in one round-trip, (possibly a single packet?), without waiting for a response to the original Parse before sending the Bind.

One of the big advantages here is that you can use binary formats, which is a big win for some types such as integers, floating point numbers, and timestamps.

So there's a protocol-level notion of statement preparation that differs from the statement-level statement preparation via PREPARE and EXECUTE. I'm not clear on all the differences, but I'm guessing they are more-or-less the same underlying mechanism, possibly (probably?) with a different namespace.

I meant PREPARE/EXECUTE. How can one currently do this via the public API?

You execute a PREPARE statement, then you either execute or query an EXECUTE statement.

For the fourth case, why isn't a simple interface where each row is handed off to the user in the form of a map or a [(colName, byteString)] an options?

This is vaguely similar to what mysql-simple does, and what very early versions of postgresql-simple (before 0.1) does as well. The current interface was suggested by Ozgun Ataman, and I liked it enough that I based the whole implementation around it and evolved the interface a bit to avoid creating intermediate data structures that need to be allocated.

It sounds like what you really want, is column-name-based parsing instead of positional parsing. I can definitely understand this desire. My main concern is how column-name parsing would interact with positional parsing.

===

The core question is, would the PG simple project be interested in participating in GSoC/HSoC? If yes, then now is the time to organize and plan.

Quite possibly.

[saurabhnanda]

IIRC, Haskell actually has not received funding from Google the last few years, and the HSoC has instead been funded by a few individuals and companies. I haven't really been involved, so I don't know what this implies, exactly, or if we are attempting to re-establish ourselves as a GSoC participant.

I assume that the Haskell.org committee will attempt getting Haskell included in GSoC this year. Do you want me to formally check with a committee member, or is this a reasonable assumption?

Err, I meant protocol-level parameters. My bad. The frontend/backend protocol isn't as nicely documented as I would hope, but basically it's where you use $1, $2, etc inside the SQL string as placeholders for the parameter, and then send each parameter as a (Type Oid, format (text or binary), bytestring (length-delimited)) triple inside a protocol message instead of putting it inside the SQL.

I would vote for this if this were on the table.

You execute a PREPARE statement, then you either execute or query an EXECUTE statement.

This is technically correct. I would've wanted to provide a nicer Haskell-level API for PREPARE/EXECUTE with some type-safety on top of the raw SQL API.

It sounds like what you really want, is column-name-based parsing instead of positional parsing. I can definitely understand this desire. My main concern is how column-name parsing would interact with positional parsing.

This could be the first goal for interested students - to come up with various ideas for the resulting API and collecting feedback before jumping into implementation.

The core question is, would the PG simple project be interested in participating in GSoC/HSoC? If yes, then now is the time to organize and plan.

Quite possibly.

If that's a firm "yes", then we will need to start acting now! Here's the timeline - https://summerofcode.withgoogle.com/how-it-works/#timeline Applications for organizations are open from 4-23rd Jan.

[saurabhnanda]

Btw, from https://summer.haskell.org/

This year, we will either organise it under the umbrella of the Google Summer of Code, or run our own program – depending on whether or not we are selected for the former.

[saurabhnanda]

Reminder.

[lpsmith]

I don't know if I have enough enthusiasm about this project in order to take it on myself, but I am certainly interested. If you'd like to take the initiative on this, I will do my best to participate. However, I have a lot of other issues to deal with at the moment...