Re: "dict"ionary typing?

"Richard A. O'Keefe" <[email protected]>
Newsgroups gmane.comp.ai.prolog.swi
Message-ID <[email protected]>
On 28/11/2013, at 2:20 AM, Jan Wielemaker wrote:

> On 11/26/2013 05:16 PM, Alan Baljeu wrote:
>> I guess there are two main uses for a dict:
>> a) as a struct where there are fixed elements of varying types.
>> b) as a map where there are variable elements of fixed types.
> 
> Not sure I get that.

These are the two use-cases I distinguished in the frames
proposal for Erlang.

(a) In a typed functional language you would be using a record
    type with named fields; the compiler would be able to check
    at compile time that the field names you mentioned existed
    in the type and the associated values were meaningful.

    Haskell example:

    newtype Date = Date {year :: Int, month :: String, day :: Int}

    today = Date {year = 2013, month = "Nov", day = 28}

    this_month = month today

    tomorrow = today {day = day today + 1}

    In this use case there may well be thousands or millions of
    instances of the type, with the same set of fields.  Updates
    are copies, but they preserve the set of fields; fields are
    neither added nor removed.  The number of fields tends to be
    at most in the low tens.

(b) In a typed functional language you would be using some sort of
    "finite map" data type where all the keys have the same type
    and all the associated values have the same type.

    Haskell example:

    import qualified Data.Map.Lazy as Map

    days = Map.fromList [("Sunday",1), ("Monday",2), ("Tuesday",3),
                         ("Wednesday",4), ("Thursday",5), ("Friday",6),
                         ("Saturday",7)]

    disc_world_days = insert "Octeday" 8 days

    In this use case the set of keys is not known at compile time;
    the set of possible keys may very well be infinite and the set
    of actual keys extremely large.  Keys can be added (with values)
    and removed.

I argued at length in the frames proposal that it would be hard to
find a data structure which handles both use cases as well as a
more specialised data structure for each, and proposed a data
structure specifically for the record-like use case.  The Erlang/OTP
team believe that one data structure CAN do both well -- although I
have not seen any numbers that would match the benchmarks for mine --
and have provided a "map" data type with the operations necessary
for use case (b) and syntax appropriate for use case (a).
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.