shorts/data_types.tex

   1 %&pre
   2 \title{Data types \`a la carte}
   3 \date{2016{-}03{-}16}
   4 \begin{document}
   5 \maketitle
   6 \subsubsection*{Summary \& Evidence}
   7 %Summary (as briefly as you can - two or three sentences)
   8 The paper provides a method of data types, functions and monads of a restricted
   9 kind to create more flexible representations. It shows that by using
  10 co-products and type constraint type-constructors one can combine individual
  11 parts and using this technology one can create less monolithic monads that
  12 better reveal the functionality and purpose.
  13
  14 %Evidence (what evidence is offered to support the claims?)
  15 Usefulness and proofs are given by tackling several classical problems in pure
  16 functional languages such as the expression problem, input/output and the
  17 problem of a having a global state. In these problems the function signatures
  18 are different compared to the classical monadic approach. The function
  19 signature reveals more about the semantics and thus gives more clarity about
  20 the function.
  21
  22 \subsubsection*{Strengths \& Weaknesses}
  23 %Strength (what positive basis is there for publishing/reading it?)
  24 As many other papers within this field of research the power of the introduced
  25 techniques is shown by tackling classical problems. Researchers from the field
  26 are likely to be already familiar with said problems. In that way immediately
  27 the practicality of the techniques become clear.
  28
  29 %Weaknesses
  30 In contrast the paper is very complex and introduces a lot of new abstractions
  31 notations and functions which makes the paper a tough read if you are not
  32 already deep in the materials. A lot of abbreviations are used which are not
  33 properly explained that could lead to confusion and the obligation to reread
  34 the parts several times to figure out the meaning.
  35
  36 \subsubsection*{Evaluation}
  37 %Evaluation (if you were running the conference/journal where it was published,
  38 %would you recommend acceptance?)
  39 The paper would be a good addition to very specific functional programming
  40 conferences or journal. I would not advise to publish this in a general
  41 theoretical computer science journal because of the weaknesses described above.
  42
  43 %Comments on quality of writing
  44 Concerning quality of writing; it requires quite some background knowledge to
  45 read the paper but the author managed to have a good build-up to the
  46 technicalities. Moreover, it is embedded well in the literature.
  47
  48 \subsubsection*{Discussion}
  49 %Queries for discussion
  50 \begin{itemize}
  51         \item Why is the representation really a saviour for the monolithic IO
  52                 monad. The regular approach does not have that much overhead.
  53         \item Since free monads are not widespread and mostly only known in
  54                 category theory. Do we really have a useful application? Are the monads
  55                 who really need such a restructuring unsuitable for it?
  56 \end{itemize}
  57 \end{document}