Hacker News Reader

Comment by usrusr | Hacker News Reader

Whenever I play with that idea in my head I get hung up on the question wether one could go even further down that road and drop variable names as a concept separate from types. If you already have a Surname instead of a String and a Birthday instead of a Date, why duplicate that into surname and bday? In a way, variable names are a bit like informal domain subtypes. Could we make them formal?

I'm really not sure if that could be in any way practical at all, but I like the idea.

View on HN

In some languages you don't give field names, just types. You bind fields to names only when pattern matching. For example in Haskell:

    type Year = Int
    type Month = Int
    type Day = Int

    -- fields have no names, just types
    data Date = Date Year Month Day

    -- we bind fields to names only when necessary
    next (Date y 12 31) = Date (y + 1) 1 1
    next (Date y m d)
      | d == daysOf m = Date y (m + 1) 1
      | otherwise     = Date y m (d + 1)
      where daysOf = (!!) [0, 31, 28, 31, 30,
                              31, 30, 31, 31,
                              30, 31, 30, 31]

Is something like this what you mean?

Thank you, good to know.

Maybe those who don't know Haskell are doomed to reinvent isolated parts of it.

( yes )

That's where my mind was headed as well. You'd still want variables for passing around instances (in a general sense; not specifically an OO sense) but everything else could be defined on the type. Sort of a types-as-classes approach.

There is/was a programming language called Wake that used this idea. The supposed domain is down right now, so this documentation source code is the best reference I can find in a few minutes: https://github.com/MichaelRFairhurst/wake-compiler-docs/blob...

Reply on news.ycombinator.com