[erlang-questions] json to map

[ok@REDACTED]

> Op 28-8-2015 om 13:50 schreef Kevin Montuori:
>>>>>>> "rw" == Roelof Wobben <r.wobben@REDACTED> writes:
> -type t_Int()   :: integer() | int.
> -type t_Word()  :: word | string().

First, there should not be any t_Int() or t_Word() type at all.

Second, you are saying here that
  "Something is a t_Int() if and only if
   (1) it is an integer() or
   (2) it is the atom 'int'."

That does not make sense.   Going back to the Haskell
example,
   data Token
      = TInt Int | ...
says
   "Token is a new type.
    One kind of token is called TInt; that kind has
    an Int inside it. ...."
TInt here is NOT A TYPE (the "T" prefix stood for "token",
not "type"; Haskell has no type prefix convention),
it is a constructor function.
It's a *label* pasted onto a record to distinguish it
from all the other kinds of token.  I could write this
type in Pascal:

    type Token = record
       case tag  : (TInt, TWord, TDash, TSlash, TComma) of
           TInt  : (val : Integer);
           TWord : (Str : Alpha);
           TDash : ();
           TSlash: ();
           TComma: ()
    end;

The thing is that we want to be able to recognise an integer
token by PATTERN MATCHING (as in the example Haskell code),
*not* by type testing with a guard.  There's nothing wrong
with type testing with a guard when we have to, but we
prefer pattern matching when we can because it is easier for
*us* as well as the computer to tell when two patterns do not
overlap.

We want to say "Here is an int token AND here is its value",
as in {int,integer()}, not "here is an int token OR here is
its value".  But using integer() | int you are saying
"an integer OR the atom 'int'".  And there is no case where
the input is going to justify a "token" that is, in its
entirety, 'int'.

It would be really helpful if Erlang had distinct notation
for "this is a union of types that are meant to be disjoint"
and "this is a union of types that I expect to overlap".

Look, it seems as though you don't yet have a clue how types
in Erlang work.  FORGET THEM until you have mastered
pattern matching and the design of data structures that are
meant to be used through pattern matching.