While this is more correct, and needs doing for the SQL^2 case, it's really not great for everywhere else we use it in SlamData. I guess we'll need a variety which is a Coproduct of EJsonF and like EJsonTypedF or something like that... without that the EJSON values that Quasar produces from its endpoints will be unusable.

@garyb This looks like it is useless, but in fact it's not. In slamdata/slamdata#1624 quasar values are used to construct SqlSquare AST, that has all those funcs: TIME, DATE, TIMESTAMP.

So, there's motivation

• VarMapValue initially is EJson + Set (List EJson) + QueryExpr -- that is this type is effectively reduced Mu (SqlF EJsonF)
• All quasar values are encoded to VarMapValues (This one is surprised me a bit, but it seems really natural then)
• Since VarMapValues are Sql and we used to construct date|time only in VarMapValues it's clear that we can drop support of date|time in ejson.
• Moreover there're problems with composing ASTs of Sql and EJson if EJson has specific notation for tagged literals --> like it's very special case of InvokeFunction, it must be parsed separately, it must be encoded/decoded separately etc.

OTOH, @sellout said that EJson has special notation of metadata like

{ {"foo": 1}: [ 1, 2, 3 ] } @ { "type": "my-awesome-type" }

And this can be used when we switch from json to ejson. But I think adding this @ is for different pr.

I understand all that stuff, but I don't think we want to parse a response that is typed as application/json;mode=precise as SQL^2.

What I'm suggesting is we use a different representation for that data that is EJsonF + typed literals, that we can translate to an SQL^2 type if we need to, but when we're just loading data, we don't want to deal with function invocations just to be able to know that a value is typed as TIMESTAMP - otherwise we're basically re-implementing chunks of Quasar in the front-end 😄

I'm not sure that I follow :(

We get untyped thing if we use application/json and even if we use application/json;mode=precise we get untyped thing but w/metadata (That can be encoded as json of course). So we need to parse string to datetime anyways.

I understand that we want to preserve structural types info, but they probably would be presented as tags/metadata that we can decode to separate EJsonTyped or whatever. But this could be just transformation on top of EJsonF

BTW, we don't use any date|time info in SlamData, it's produced by markdown and then printed and vice versa, parsed and set to markdown value.

We get untyped thing if we use application/json and even if we use application/json;mode=precise we get untyped thing but w/metadata (That can be encoded as json of course). So we need to parse string to datetime anyways.

The "untyped+metadata" still has explicit formats for date, time, etc. though - we don't want to have to do the work of parsing that based on metadata values every time, we just want to get something back that has already decoded it into purescript types - otherwise we'll be back to the situation we had up until recently (when the constructors were stringly typed) where we have a whole bunch of duplicated code that does the decoding/parsing of these values.

I understand that we want to preserve structural types info, but they probably would be presented as tags/metadata that we can decode to separate EJsonTyped or whatever. But this could be just transformation on top of EJsonF

I think we're agreeing 😄 - I'm suggesting we move those literal constructors that were deleted into a new algebra, and then I can use that as Mu (Coproduct EJsonF TypedThings) in the structure editor, etc.

Ok, cool. BTW, why not produce SqlF EJsonF in structure editor?