Arbitrary input validates against `Void` schema about autodocodec HOT 12 CLOSED

@i-am-tom I think I'm convinced. The "trees that grow" technique, while complex, is probably still worth it compared to just having X times as many types.
We should revisit the VoidCodec idea then.
We already have the tests now for HasCodec Void, so that should be rather easy to do.

The collapsing of schemas is something we could also look into further.
There may be other schemas that we can collapse, like nested "or null" codecs.

EDIT: The collapsing of schemas will be important for this requirement:

the schema produced is not something we could currently release to the public.

from autodocodec.

Gently ping @i-am-tom and @plcplc

from autodocodec.

@plcplc Ok feel free to reopen at that point.

from autodocodec.

Or even

{
  "properties": {
    "Left": {
      "additionalProperties": true,
      "not": {}
    },
    "Right": {
      "type": "boolean"
    }
  },
  "type": "object",
  "info": {
    "title": "",
    "version": ""
  },
  "paths": {},
  "swagger": "2.0"
}

from autodocodec.

@plcplc That's a good point.
In general we don't try to guarantee that things not encoded don't validate, only that things that can be encoded do validate:

I'm open to suggestions about how to fix this.

from autodocodec.

More info on this: Because bimapCodec allows arbitrary parse-failures, there's no way for the schema to be as strict as the codec.

from autodocodec.

Because bimapCodec allows arbitrary parse-failures, there's no way for the schema to be as strict as the codec.

That is true - but it also feels like a low aspiration for a dedicated VoidCodec constructor :-)

I'm open to suggestions about how to fix this.

I think that just producing the following json schema for a VoidCodec is a passable solution:

{ 
  "not": {}
}

Alternatively, the approach taken by @i-am-tom in #32 which transitively censors void-containing branches from the schema is a good approach too I think (and one that results in a more informative schema).

from autodocodec.

@plcplc We decided against the VoidCodec constructor because I don't think it carries its weight in terms of complexity.
I don't even understand why you would use Either Void anywhere.
The HasCodec Void instance was probably a mistake in the sense that it's not useful, and only there because it can be.

Happy to reopen if there's a good case for a VoidCodec constructor.

from autodocodec.

@NorfairKing If it doesn't seem useful, then it's worth pointing out that Either Void is only the easiest degenerate example. Consider the following API type, or anything with a similar Trees That Grow feel to it:

data IdentifierQuery t
  = ByKey (Key t)
  | ByIndex (Index t)

This hypothetical type allows us to query different types of data store with a common interface, but by using Void as a Key or Index type, we can remove parts of the interface that don't make sense, and do so with full support from the exhaustiveness checker. For example, we can imagine:

class CanQuery t where
  type Key t :: Type
  type Index t :: Type

instance CanQuery Array where
  type Key Array = Void
  type Index Array = Int

instance CanQuery (Map k) where
  type Key (Map k) = k
  type Index (Map k) = Void

instance CanQuery Set where
  type Key Set = Void
  type Index Set = Void

We can query an array by index but not field, we can query an object by field but not index, and we can query a set by neither. With that in mind, I would like to be able to write:

instance (HasCodec (Key t), HasCodec (Index t)) => HasCodec (Query t)

... and have that instance specialise to the various different types throughout my schema, as I can with e.g. ToJSON/FromJSON instances. This is why HasCodec Void is useful.

Pushing a bit further, though, we can imagine another API type:

data UpdateName t
  = UpdateName
       { newName :: String
       , target :: IdentifierQuery t
       }

instance (HasCodec (Key t), HasCodec (Index t))
  => HasCodec (UpdateName t)

So, what does the schema look like for UpdateName Set? This is why "bubbling up" Void (and collapsing Void sides of a sum) is useful: there are whole branches of complex structures that end up not existing.

The HasCodec Void instance was probably a mistake in the sense that it's not useful

This made me a bit sad to read, so I'm sorry about the wall of text. The problem is that we use this library a lot (and like doing so), but the schema produced is not something we could currently release to the public. Our codebase uses this trick a lot to try to maintain consistency where possible across different implementations of an interface.

That said, maybe this is a reasonably unique problem to us, and if TTG-style types are a niche that isn't worth the burden, then that's our problem, not autodocodec's :)

from autodocodec.

@i-am-tom will you make another PR?

from autodocodec.

@i-am-tom When you make a PR, you could start by looking at the voidcodec branch and getting the tests that are failing to pass.

from autodocodec.

@NorfairKing: Just want to let you know that while I do want to work on this, we're somewhat short on time for API-codecs related stuff at the moment. I'll revisit this if/when that changes in the future.

from autodocodec.