all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Andrea Corallo <akrl@sdf.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel@gnu.org
Subject: Re: new function proposal alist-to-hash
Date: Sat, 05 Oct 2019 08:18:19 +0000	[thread overview]
Message-ID: <xjfa7af61x0.fsf@sdf.org> (raw)
In-Reply-To: <jwvmueg2v7d.fsf-monnier+emacs@gnu.org> (Stefan Monnier's message of "Fri, 04 Oct 2019 15:16:13 -0400")

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> - I think is quite useful to be able to create in a concise and
>>   explicit way nested hash tables. This is a common feature of many
>>   "modern" languages.
>>   Here both solutions compared:
>>
>> (alist-to-hash '((a . x)
>> 		 (b . ((i . j)
>> 		       (k . l)))
>> 		 (c . y)))
>>
>> (map-into `((a . x)
>> 	    (b . ,(map-into '((i . j)
>> 			      (k . l))
>> 			    'hash-table))
>> 	    (c . y))
>> 	  'hash-table)
>
> Not sure I understand: if you only use it for immediate/literal data,
> then I guess you could just use the #s(hash-table data (...)) syntax.

Sure, my example was just to point out easiness of use from a syntactic
point of view. The good of having the list quoted by the user is that
he can quasi-quote when needed what he needs.

> And for non-literal maps, this needs to somehow distinguish values that
> are alists from others, like
>
>     (map-into (mapcar (lambda (x)
>                         (if (and (consp (cdr x)) (consp (cadr x)))
>                             (cons (car x) (map-into (cdr x) 'hash-table))
>                           x))
>                       my-alist)
>               'hash-table)
>
> But I suspect that this is not frequently needed.
> [ BTW, the above code is screaming for something like `map-values-apply`
>   but which returns a *map* rather than a list.  ]
>
> And if you really need this to apply recursively, it basically means
> you don't have a map but a *tree* where each node is originally
> implemented as an alist and which you want to transform into the same
> tree where each node is now a hash-table.  Again, this is likely not
> needed very frequently (and I suspect that each time it's needed, it
> will have slightly different needs/constraints).

I've maybe used not the correct nomenclature sorry.
What I want to say is that being an hash table a key value map it maps
1:1 into alist.
That said I think is quite important to be able to express in a clear
and short way nested hashes.
In python it would be simply something like this:

nested_dict = { 'dictA': {'key_1': 'value_1'},
                'dictB': {'key_2': 'value_2'}}

Note that here just litteral are used but also variables can be
evaluated while creating the dictionaries.

A tree of a-list for the reason I've expressed above would be to me the
most natural way to express the same.  Given that a recursive
implementation that walks this tree like the one in patch I've posted
can do the job.

Maybe I'm the only that see a value on that but I think is useful :)

>> - map-into does not let you tweak make-hash-table parameters.
>>   This is especially a limitation regarding :test so is effectively a
>>   solution to say ~50% of the use cases.
>
> Yes, this is a very serious limitation of `map-into`.
> I decided not to try to tackle it when I converted map.el to use
> cl-defmethod, but I'd welcome help on this.
>
>
>         Stefan

Ok I'm looking into it.

Bests
  Andrea

-- 
akrl@sdf.org



  reply	other threads:[~2019-10-05  8:18 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-04  9:58 new function proposal alist-to-hash Andrea Corallo
2019-10-04 19:16 ` Stefan Monnier
2019-10-05  8:18   ` Andrea Corallo [this message]
2019-10-05 15:13     ` Stefan Monnier
2019-10-05 15:45       ` Andrea Corallo
2019-10-05  8:28   ` [PATCH] extend map-into (was: new function proposal alist-to-hash) Andrea Corallo
2019-10-06 14:02     ` [PATCH] extend map-into Stefan Monnier
2019-10-06 20:59       ` Andrea Corallo
2019-10-08 17:29         ` Stefan Monnier
2019-10-08 18:46           ` Andrea Corallo
2019-10-08 20:23             ` Stefan Monnier
2019-10-09 15:35               ` Andrea Corallo
2019-10-09 19:41                 ` Stefan Monnier
2019-10-09 20:02                   ` Andrea Corallo
2019-10-10  8:27                     ` Nicolas Petton
2019-10-10  8:28                     ` Nicolas Petton
2019-10-10 10:06                       ` Andrea Corallo
2019-10-10 11:47                         ` Nicolas Petton
2019-10-11 16:19                         ` Stefan Monnier
2019-10-11 16:29                           ` Andrea Corallo
  -- strict thread matches above, loose matches on Subject: below --
2019-10-03 21:25 new function proposal alist-to-hash Andrea Corallo
2019-10-03 21:40 ` Drew Adams
2019-10-03 21:56 ` Stefan Monnier
2019-10-03 22:07   ` Andrea Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xjfa7af61x0.fsf@sdf.org \
    --to=akrl@sdf.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.