[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: plists, alists, and hashtables
From: |
Ted Zlatanov |
Subject: |
Re: plists, alists, and hashtables |
Date: |
Thu, 06 Aug 2015 22:14:24 -0400 |
User-agent: |
Gnus/5.130012 (Ma Gnus v0.12) Emacs/25.0.50 (gnu/linux) |
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
- RE: plists, alists, and hashtables, (continued)
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/06
- Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/06
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/07
- Message not available
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/08
- Re: plists, alists, and hashtables, Rusi, 2015/08/08
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/06
- Re: plists, alists, and hashtables,
Ted Zlatanov <=
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/07
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Ted Zlatanov, 2015/08/07
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/07
- Message not available
- Re: plists, alists, and hashtables, Pascal J. Bourguignon, 2015/08/07
- Re: plists, alists, and hashtables, Stefan Monnier, 2015/08/07