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