Re: plists, alists, and hashtables

[Pascal J. Bourguignon]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 06 Aug 2015 20:46:09 +0200 "Pascal J. Bourguignon" 
> <pjb@informatimago.com> wrote: 
>
> PJB> Ted Zlatanov <tzz@lifelogs.com> writes:
>
>>> OK, it's possible, but that's a terrible syntax. Maps should *look*
>>> different from lists and their keys and values, in particular, should be
>>> easily distinguished from each other.
>
> PJB> Why?
>
> Because I don't want to look at (a b c d e f g h) and count until I find
> that g is a key and h is a value.  That's dumb and leads to mistakes.

But you never have  (a b c d e f g h).
You either have:    (:a b :c d :e f :g h)
or you have:        (a b
                     c d
                     e f
                     g h)

Really, it is quite rare that the form and type of the keys be the same
as for the values, so even when written on one line, there's no
confusion.

The only case where you would have the same form, is for an actual
dictionary to translate words, or a map used to represent a discrete
numeric function.

(defvar *increment[4]* (dictionary 0 1 1 2 2 3 3 0))
(defvar *localize* (dictionary "hello" "bonjour" "bus" "car" "car" "voiture" 
"hide" "cache" "cache" "cachette"))

could be confusing, but not:

(defvar *increment[4]* (dictionary 0 1
                                   1 2
                                   2 3
                                   3 0))

(defvar *localize* (dictionary "hello" "bonjour"
                               "bus" "car"
                               "car" "voiture"
                               "hide" "cache"
                               "cache" "cachette"))

 
> PJB> Additionnal syntaxes can be useful, and should only be used, for end
> PJB> users and DSL implementing a domain with pre-existing _extensive_ use of
> PJB> that syntax.
>
> My claim, I guess, is that general ELisp programming involves an
> extensive use of maps, so it could use a syntax for it.
>
> I am not making any philosophical claims about the essence of Lisp.

Well, as mentionned before, if you abstract away a given type of maps:

- you may hide the costs, and that would lead to bad results,

- you would impose one kind of data structure usage (mutable hash or
  immutable a-list or mutable a-lists or llrb-trees? etc)

- or if you don't and make it adaptative, we observe that there's
  actually very little gain obtained, (because it takes time to convert
  the data structures, and therefore it's hard to amortize that cost).


And therefore the general conclusion is that it's not such a good idea
to abstract away a higher level notion.

Ie. the programmers must have the choice between hash-table and a-list
or something else.

If you don't believe that, you can always implement a library to provide
a common API over various dictionaries. I did just that in CL:

https://gitlab.com/com-informatimago/com-informatimago/blob/master/common-lisp/cesarum/dictionary.lisp
(sorry, I've not written the automatic adaptative code yet).

Let me just say that this is not the API I reach first when I write lisp
code.  Just use a-lists or hash-tables directly, depending on the
circumstances determined at program-writting time.



> PJB> But maps are not something out of this lisp world.  They existed from
> PJB> the start as a-list, then p-list and then hash-tables.  They are a basic
> PJB> data structure perfectly integrated to an algorithmic programming
> PJB> language, and don't constitute a different, Domain Specific Language.
>
> I've given examples of why lists, in my opinion, don't make a good read
> syntax for maps.  If that's not enough to convince people, then it's not
> a good idea.

Notice that as mentionned before, the question here is whether that
should be included into the emacs lisp language, or whether that should
be defined as a user library.

As a user library nobody will say that it's a bad idea and that it
cannot have its usage in some program.

What we reject, is the idea that it should be included in the emacs lisp
language.

And this is why we feel the lack of reader macros, since that would
clearly allow you to write a new syntax in a user library, instead of
having to beg it from the emacs lisp language itself.



-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk