Re: plists, alists, and hashtables

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 07 Aug 2015 02:08:58 +0200 "Pascal J. Bourguignon" <pjb@informatimago.com> wrote: 
 
PJB> Ted Zlatanov <tzz@lifelogs.com> writes:
>> Maybe the macro is good enough, but I think the keys and values have to
>> be clearly separated from each other and from other cells to make it
>> visually useful.  

PJB> I understand that, and I cannot advise more strongly that you add
PJB> newlines and indent your data to clearly show it.

PJB>          (hash-table  k1      v1
PJB>                       kkkk2   v2
PJB>                       k3      vvvvvv3)

I don't think it's good to force the programmer to reformat their code
because the syntax doesn't do the right thing.

PJB> Also, I would admit that using parentheses around the entries could help
PJB> editing the data structure, since that allows adding or removing entries
PJB> easily with a structural editor like emacs+paredit.

PJB>         (mhash-table  (k1      v1)
PJB>                       (kkkk2   v2)
PJB>                       (k3      vvvvvv3))

PJB> It works well enough for a macro (eg. let), but for a function it is a
PJB> real bother

I think that's good enough in the `let' format, as a macro. The
syntactic shortcut of creating keys without a cell with a null value is
nice too. Can we agree that this is a good syntax and move back to
discussing Unicode markers again? :)

>> The second part of my question was whether Customize support for
>> hashtables would make them more approachable and useful.

PJB> This could definitely help.

OK, I'm glad you agree.  Maybe that discrete work would be generally
helpful regardless of the rest of this discussion.

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

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

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

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

I see your point.  It connects with Stefan's point about cons-ing alists
and plists because they're persistent.  Thank you for stating it well.

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

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

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

OK, and your experience confirms the answer to my question.  This is
very helpful to countermand my intuition, which is perhaps guided too
much by the other languages I use.

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

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

Yup, I understand.  I'll look into making it.

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

Is this work already planned?

How much of it must be done to accomplish what I want, a library that
lets me say `{ "k1": "v1" }' (giving JSON syntax as an example) and
translates it to the correct #s(hash-table ...) serialization?

Together with the Customize support for hashtables, I think we can agree
these would be nice usability improvements.

Stefan also mentioned there could be performance optimizations for
hashtables themselves.  I think that's a good direction too.

Ted