[erlang-questions] json to map

ok@REDACTED ok@REDACTED
Sat Aug 29 14:13:43 CEST 2015


> 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.






More information about the erlang-questions mailing list