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

Handling Queries #2

Open
andygill opened this issue May 28, 2015 · 4 comments
Open

Handling Queries #2

andygill opened this issue May 28, 2015 · 4 comments

Comments

@andygill
Copy link
Member

How do we handle output, vs queries?

 display :: Effect ()        -- output is a side-effect
 display :: Effect Output -- output is returned, no side effect

We also need to consider reply. What happens in

  • interactive mode - Output would be displayed
  • batch mode - Output would be ignored automatically, aka >>
  • replay mode - Do we reply the primitives? Are Queries for interactive mode only.
@andygill
Copy link
Member Author

Currently:

query :: (Guts a) => Transform a b -> Shell ()

Replace with

query :: (Guts a, ... b) => Transform a b -> Shell b

@roboguy13
Copy link
Member

Hmm, would the complete new type signature be something like this?

query :: (Guts a, FromJSON b) => Transform a b -> Shell b

We need to implement a way for the server to send serialized data back in order to do this.

One potential problem I see is that the a in TypedEffectH a is a phantom type that doesn't carry any value level information. I don't think it can have a type other than () at the moment, so the particular type of (const (toJSON ())) is () -> Value in the line d6f26:HERMIT.Server.Parser#L44.

@andygill
Copy link
Member Author

We will eventually move to the query :: (Guts a, FromJSON b) => Transform a b -> Shell b type, or something equivalent. It is one of the advantages of Haskell, vs the old shell that did not have bindings.

@ecaustin
Copy link
Contributor

ecaustin commented Jul 7, 2015

My latest commits are a big first step towards getting this working right.

I modified parseTopLevel to add a new alternative case for parsing TypedEffectBox values which is the GADT that monomorphizes TypedEffectH by hiding and constraining its type variable.

The bad news is that these values aren't exactly parsing correctly right now.

The good news is that because parsing fails it just skips to the next alternative, so everything should work exactly as it did before, so you can essentially ignore my commits if they don't interest you.

I'll work on debugging what's going on tomorrow, but wanted to push up the GADTs in case anyone was curious how the work was going.

As a quick note, I'm planning to clean up and refactor things once everything's working; in the mean time, pardon my mess.

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