swish / TODO

Some things I want to/should do (not in order)

- use types better - e.g. ScopedName/Namespace has a lot of String
  entries which could be replaced by Maybe String and URI

  Should there be a type-level constaint that an RDF Arc can only have
  a literal in the object position?

- the RDFLabel data type could be split up to add additional type
  constraints, namely Lit could be split up into something like ULit
  for an untyped literal, LLit for a language lit coupled with a
  LString type that combines text and language tag), and DLit for a
  literal with a datatype. This would require a minor version update

  An alternative change would be to make it 'Lit RDFLiteral' with
  RDFLiteral having the Untyped/Typed/Language options.

- remove parsec parser, replace by attoparsec-text

  - use Text rather than String
  - use attoparsec-text-enumerator?

  This would require a minor version update

- move a lot of parser/formatter tests out to ntriples files (ie the
  test data in external files).

- turtle parser, then RDF/XML.

- look at using fgl rather than existing graph code (may or may not be
  worth it), especially given that it's not really a graph

- look at using something like a TextBuilder for processing output

- profile (have added the -fdeveloper cabal flag which can be combined
  with the --enable-library-profiling and --enable-executable-profiling

- improve test coverage (-fhpc cabal flag)

- how much of the support code - e.g. Swish.Utils.LookupMap - can now
  be replaced with packages from hackage? Swish.Utils.DateTime is now
  marked as deprecated since it isn't used by any other module.

- move to camel case for names, in particular for
  Swish.RDF.Vocabulary; this would require a minor version update

- change SwishAction from a tuple to a SwishStateIO (); requires an
  minor version update

  can we improve the processing of the commands, so that they
  exit on error immediately, with a single error message.

  An EDSL for the command language or for the base components
  such as RDFTriple/Graph?

- remove the containedIn function of the LDGraph type class,
  or implement it. It is currently unused in the code base.

- would it make sense to add some form of XSDType type class which
  would contain to/from and show canonical String methods and some
  form of equality test; these could then be used to create the
  RDFLabel instances and the showCanon RDFLabel routine? Need to think
  about this as technically it need not be restricted to XSD types.

  Errr, there is Swish.RDF.Datatype which looks to have the
  semantics we need (ie remove the To/FromRDFLabel typeclasses); 
  it may still be useful to have a typeclass for conversion between
  strings and values for the formatter/parser code (such as,
  perhaps, Swish.RDF.Datatype.DatatypeMap)