[erlang-questions] Special syntax for dictionaries

Richard O'Keefe ok@REDACTED
Fri May 7 00:45:49 CEST 2010


On May 6, 2010, at 1:18 PM, Tony Arcieri wrote:

> On Mon, May 3, 2010 at 5:10 PM, Richard O'Keefe <ok@REDACTED>  
> wrote:
> My proposal for 'frames' has been sitting around for years.
> but it's NOT a hashmap because it's NOT mutable
>
> I'm kind of confused as to what you're saying here.  Dicts aren't  
> mutable either.

Did I say they were?
>
> When you say "frames" wouldn't be mutable, how does that differ from  
> dicts (or for that matter, records)

I nowhere said that frames differed from either dicts or records
*in this respect*.  I just said they weren't hashmaps.
java.utils.HashMap is a well known Java class -- indeed, that is where
the "word" hashmap comes from, before Java's class, people talked about
hash tables or tables or hashes or dictionaries mostly.  And hashmaps
support put() and remove() mutation operations.

If it comes to that, frames aren't _any_ kind of hash table, as
in order to achieve the best space efficiency I could think of they
do not use any form of hashing at all.  This is another way in which
they differ from dicts:  you aren't really _expected_ to access one
field at a time, you're expected to access _several_ fields.  The
report has one extended example.  It's not the only one I've done.
A manual optimisation I found often useful was to replace

	f(..., R, ...) ->
	    ... use R's f ...
	    ... use R's g ...
	    ... use R's h ...

by
	f(..., R = <{f ~ F, g ~ G, h ~ H}>, ...) ->
	    ... use F ...
	    ... use G ...
	    ... use H ...

Indeed, I did at one time think of allowing
	(frame-valued expression) ~ field
with the obvious meaning, but dropped it in order to encourage
this more efficient style.  Of course a compiler can perfectly
well gather all the field accesses on a path and put them into
an earlier match, EXCEPT that this changes the failure behaviour
of the program:  if R doesn't _have_ an h field the upper
example will crash when you try to get it, but the lower one
will crash in the function's head, which is, other things being
equal, a better thing to do.  It also meant that I didn't have
to give two related-but-confusingly-different readings to ~ .



More information about the erlang-questions mailing list