Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

abandoned? #2

Open
heyakyra opened this issue Sep 1, 2016 · 7 comments
Open

abandoned? #2

heyakyra opened this issue Sep 1, 2016 · 7 comments

Comments

@heyakyra
Copy link

heyakyra commented Sep 1, 2016

has this been abandoned?

@stepcut
Copy link
Owner

stepcut commented Sep 1, 2016

Nope. Every week I have lofty plans about how this is going to be the week I really make some progress on it. But then something else higher priority comes up.

@theunixman
Copy link

Hey hey, is there anything you know of off the top of your head that I could help with in my copious free time? I'm checking out the code now and trying it with 8.0.1, and if nothing else comes up I'll at least port it there if there's anything to be done for that.

@stepcut
Copy link
Owner

stepcut commented Feb 26, 2017

Hello!

I was just thinking last week that I need to dedicate Friday's to working on hyperdrive.

I am going to start by blogging about various approaches to verified parsing in Haskell. Haskell is getting pretty crazy these days. You can now do stuff like:

pHttpVersion :: [abnf| "HTTP" "/" 1*DIGIT "." 1*DIGIT |] (Int,Int)
pHttpVersion = _

And get compile time guarantees that your parser matches the ABNF specification :) Now -- if you want a stupidly fast parser, you might have to result to low-level bytestring manipulation. But if you are doing that you want to be able to use QuickCheck to make sure that your hand optimized parser are correct. And that is where the verified parser comes into play. It provides a known reference parser that has a high assurance of correctness.

hyperdrive has been on the back burner for a while because I have been experimenting with developing client-side Haskell frameworks. I am now on the third generation of that yak shaving expedition. But getting to the point where I want to have hyperdrive+servant+chili -- where 'chili' is the codename for my latest unreleased clientside framework. (It will definitely be renamed before it is released, the name is an inside joke).

I will make a serious attempt to start publishing this Friday. I want the development of hyperdrive to be a very interactive process where I blog my ideas and get immediate feedback. So hopefully that will open some avenues for contribution.

@theunixman
Copy link

I was literally just talking about replacing the WAI stack in servant with hyperdrive, which is what led me here via @thekyriarchy! And of course ghcjs in the browser would be neat if I can build it...

@stepcut
Copy link
Owner

stepcut commented Feb 26, 2017

So, I have previously replaced the WAI stuff with Happstack,

https://github.com/happstack/servant-happstack

But it is very bit rotten because I have not had time to merge the many servant changes since then. Since WAI no longer depends on conduit (and has not for a while), it seemed like having hyperdrive support WAI would be a lower maintenance solution?

@theunixman
Copy link

I have strong feelings about the current state of monoculture in the Haskell ecosystem, and if there's anything I can do to help with maintaining that until hyperdrive is ready I'm definitely interested.

@theunixman
Copy link

Oh also since I completely misread what you wrote, I think WAI support would bring a lot of other projects in. I also think that having something like pluggable "adaptors" would be even more interesting. For example, having a way to support something like pipes or machines as scaffolding on top of hyperdrive would also be really attractive. And possibly even better resource managers like "managed", in place of the baroque ResourceT. I know I'm new to Haskell, the language, but I also see that there's a lot of interesting work going on independent of the Commercial Haskell work that's far more robust, and really does use the type system to its fullest, and anything that can bring that out into the open I really strongly support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants