I haven't used aeson much yet, but it *does* seem possible to generate objects with ToJSON. In fact, the example given for an instance is: data Coord { x :: Double, y :: Double } instance ToJSON Coord where toJSON (Coord x y) = object ["x" .= x, "y" .= y] I'm not opposed to creating some kind of QQ syntax if it will help things out, but let's come up with some real-life use cases where the built-in operators and functions are insufficient. Michael On Thu, Mar 17, 2011 at 8:44 AM, Max Cantor wrote:

ToJson doesn't seem to be able to generate JSON objects (key/value maps).  Also, one problem that I've had with other generic JSON libs is that they dont give you enough control over the JSON structure.  So, you need to write your client code around a particular JSON structure which can be unwieldy at times.

max On Mar 17, 2011, at 1:37 PM, Greg Weber wrote:

...

Are you using the ToJson converter? I don't think QQ offers much advantage over utilities that can automatically convert haskell data structures to JSON. I believe aeson comes with this functionality and also some generics functionality if you define a Data instance.

http://hackage.haskell.org/packages/archive/json-enumerator/0.0.1/doc/html/T...

On Wed, Mar 16, 2011 at 8:32 PM, Max Cantor wrote: I know that the kickass yesod team is looking to change the json library to aeson.

One nice feature would be quasi-quoting for the library like in the following library. hackage.haskell.org/packages/archive/text-json-qq/0.2.0/doc/html/Text-JSON-QQ.html _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

I think my main issue is that it because it needs a map from json <-> haskell type, can you have json objects with differing keys? For instance, say we want to return one of: {status: 0, content: "boo.."} and {status: 1, errorMsg: "duck typing is bullsh*t"} with the json library's generic functions you can't do this. even: data Msg = Msg { status :: Int, content :: Maybe String, errorMsg :: Maybe String } won't work as it will choke on the "missing" fields. Max On Mar 17, 2011, at 10:01 PM, Greg Weber wrote:

I agree that ToJson as is now is biased towards arrays. I have some code like the below now. After we switch over we should make sure it is easy to create key-value objects. Perhaps we will need a second ToJson that is biased towards key-value objects instead of arrays.

documentToJson :: [Field] -> J.Value documentToJson = jsonMap . map toAssoc

toAssoc :: Field -> (String, J.Value) toAssoc (l := v) = (unpack l, toJson v)

On Wed, Mar 16, 2011 at 11:44 PM, Max Cantor wrote: ToJson doesn't seem to be able to generate JSON objects (key/value maps). Also, one problem that I've had with other generic JSON libs is that they dont give you enough control over the JSON structure. So, you need to write your client code around a particular JSON structure which can be unwieldy at times.

max On Mar 17, 2011, at 1:37 PM, Greg Weber wrote:

...

Are you using the ToJson converter? I don't think QQ offers much advantage over utilities that can automatically convert haskell data structures to JSON. I believe aeson comes with this functionality and also some generics functionality if you define a Data instance.

http://hackage.haskell.org/packages/archive/json-enumerator/0.0.1/doc/html/T...

On Wed, Mar 16, 2011 at 8:32 PM, Max Cantor wrote: I know that the kickass yesod team is looking to change the json library to aeson.

One nice feature would be quasi-quoting for the library like in the following library. hackage.haskell.org/packages/archive/text-json-qq/0.2.0/doc/html/Text-JSON-QQ.html _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

oh, you are using Maybe- the field needs to be filled in with Nothing On Thu, Mar 17, 2011 at 7:52 AM, Greg Weber wrote:

That seems like a fundamental limitation of haskell records- they aren't meant to have empty fields. I would create 2 different kinds of messages or use an alist or a map. Otherwise you could try to wrap the field in a Maybe.

On Thu, Mar 17, 2011 at 7:33 AM, Max Cantor wrote:

...

I think my main issue is that it because it needs a map from json <-> haskell type, can you have json objects with differing keys?

For instance, say we want to return one of: {status: 0, content: "boo.."} and {status: 1, errorMsg: "duck typing is bullsh*t"}

with the json library's generic functions you can't do this. even:

data Msg = Msg { status :: Int, content :: Maybe String, errorMsg :: Maybe String }

won't work as it will choke on the "missing" fields.

Max

On Mar 17, 2011, at 10:01 PM, Greg Weber wrote:

...

I agree that ToJson as is now is biased towards arrays. I have some code like the below now. After we switch over we should make sure it is easy to create key-value objects. Perhaps we will need a second ToJson that is biased towards key-value objects instead of arrays.

documentToJson :: [Field] -> J.Value documentToJson = jsonMap . map toAssoc

toAssoc :: Field -> (String, J.Value) toAssoc (l := v) = (unpack l, toJson v)

On Wed, Mar 16, 2011 at 11:44 PM, Max Cantor wrote: ToJson doesn't seem to be able to generate JSON objects (key/value maps). Also, one problem that I've had with other generic JSON libs is that they dont give you enough control over the JSON structure. So, you need to write your client code around a particular JSON structure which can be unwieldy at times.

max On Mar 17, 2011, at 1:37 PM, Greg Weber wrote:

...

Are you using the ToJson converter? I don't think QQ offers much advantage over utilities that can automatically convert haskell data structures to JSON. I believe aeson comes with this functionality and also some generics functionality if you define a Data instance.

http://hackage.haskell.org/packages/archive/json-enumerator/0.0.1/doc/html/T...

...

On Wed, Mar 16, 2011 at 8:32 PM, Max Cantor

...

I know that the kickass yesod team is looking to change the json

wrote: library to aeson.

...

One nice feature would be quasi-quoting for the library like in the

following library.

...

hackage.haskell.org/packages/archive/text-json-qq/0.2.0/doc/html/Text-JSON-QQ.html

...

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

Oh, I think I see where this is headed now. You're not just worried about the ToJSON instance, you want to make sure we have a matching FromJSON instance. Is that right? I agree that in general it's a bad idea to need to specify both the serialization and deserialization as separate components, instead of defining it once and automatically deriving the serialize/deserialize code from that. That's actually the main motivation for having all the TH code for parsing/rendering routes. Yeah, I think this would make sense for *some* kind of DSL. I'm not sure what exactly it should look like yet, but this is definitely worth a discussion. Michael On Thu, Mar 17, 2011 at 4:34 PM, Max Cantor wrote:

I'm not saying a DSL/QQ is necessarily the answer, but it very much feels like the "yesod way" of doing things.

max

On Mar 17, 2011, at 10:01 PM, Greg Weber wrote:

...

I agree that ToJson as is now is biased towards arrays. I have some code like the below now. After we switch over we should make sure it is easy to create key-value objects. Perhaps we will need a second ToJson that is biased towards key-value objects instead of arrays.

documentToJson :: [Field] -> J.Value documentToJson = jsonMap . map toAssoc

toAssoc :: Field -> (String, J.Value) toAssoc (l := v) = (unpack l, toJson v)

On Wed, Mar 16, 2011 at 11:44 PM, Max Cantor wrote: ToJson doesn't seem to be able to generate JSON objects (key/value maps).  Also, one problem that I've had with other generic JSON libs is that they dont give you enough control over the JSON structure.  So, you need to write your client code around a particular JSON structure which can be unwieldy at times.

max On Mar 17, 2011, at 1:37 PM, Greg Weber wrote:

...

Are you using the ToJson converter? I don't think QQ offers much advantage over utilities that can automatically convert haskell data structures to JSON. I believe aeson comes with this functionality and also some generics functionality if you define a Data instance.

http://hackage.haskell.org/packages/archive/json-enumerator/0.0.1/doc/html/T...

On Wed, Mar 16, 2011 at 8:32 PM, Max Cantor wrote: I know that the kickass yesod team is looking to change the json library to aeson.

One nice feature would be quasi-quoting for the library like in the following library. hackage.haskell.org/packages/archive/text-json-qq/0.2.0/doc/html/Text-JSON-QQ.html _______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

_______________________________________________ web-devel mailing list web-devel@haskell.org http://www.haskell.org/mailman/listinfo/web-devel

On Fri, Mar 18, 2011 at 9:55 AM, Max Cantor wrote:

...

Yeah, I think this would make sense for *some* kind of DSL. I'm not sure what exactly it should look like yet, but this is definitely worth a discussion.

This is nice: http://hackage.haskell.org/packages/archive/text-json-qq/0.2.0/doc/html/Text...

If I'm not mistaken, text-json-qq is only for generating output, not for parsing JSON back into Haskell. I think if we go the route of a DSL, we should make sure to support both. Michael

Actually, I thought he mentioned the it uses aeson's types. I think it sounds like a *very* enticing idea. On Mon, May 9, 2011 at 7:07 PM, Greg Weber wrote:

Is aeson working out for you? It looks like a more flexible json generator was just released [1], including support for generating converters in both directions. Yesod will definitely still be sticking with aeson, but we aim to make the usage of alternatives convenient. Greg Weber

[1] http://martijn.van.steenbergen.nl/journal/2011/05/08/introducing-jsongrammar... On Sun, Mar 20, 2011 at 12:54 AM, Michael Snoyman wrote:

...

On Fri, Mar 18, 2011 at 9:55 AM, Max Cantor wrote:

...

...

Yeah, I think this would make sense for *some* kind of DSL. I'm not sure what exactly it should look like yet, but this is definitely worth a discussion.

This is nice:

http://hackage.haskell.org/packages/archive/text-json-qq/0.2.0/doc/html/Text...

If I'm not mistaken, text-json-qq is only for generating output, not for parsing JSON back into Haskell. I think if we go the route of a DSL, we should make sure to support both.

Michael