Re: RFC: make maphash return a list

[Klaus-Dieter Bauer]

Wilfred Hughes <me <at> wilfred.me.uk> writes:

> 
> 
> 
> 
> > maphash is nice because it doesn't cons a list.
> So you're saying that maphash returning nil is a desirable property 
because it doesn't build a list if you don't want it? OK, I understand. I 
think it might be helpful for the docstring of maphash to say 'for side 
effects only' the same way mapc does. My (incorrect) intuition was that any 
mapFOO function would return a sequence unless otherwise stated.> (defun 
choose-name-to-taste (callable table)
> >   "Left as an exercise for the reader."
> >   (let ((retlist nil))>    (maphash (lambda (key value)
> >               (setq retlist (cons (funcall callable key value) 
retlist)))>             table))>    retlist))
> 
> Yep, exactly. I don't want to turn this into bikeshedding -- I only felt 
it was a nice to have, and of course I can build a list myself. Since both 
mapcar and mapc exist in core Emacs, would it be worthwhile to have a 
blessed chose-name-to-taste implementation in core?> Isn't this [adding 
functionality to loop] the right place to improve elisp?
> 
> That's an excellent idea, I'll try to put together a patch for that.
> 
> Thanks for your feedback, I appreciate it.
> Wilfred
> 


> “maphash is nice because it doesn't cons a list.”

While I understand the performance considerations (regarding possibly
high memory use in some cases), I find having some variant that DOES
return values producing less readable code. If all “map...” functions
returned values unless explicitly told not to this would allow for a
more consistently functional style of programming. I'm not sure how
style conventions usually are for emacs lisp, but personally I find
code much more readable that avoids changing the value of variables.

E.g. I found my own code easiert to read and expand if I can do a
list-operation like

  (mapcar 'modification-2 (mapcar 'modifification-1 (maphash (lambda
    (k v) (return-something k v)))))

compared to

  (let (mapped-hash) (maphash (lambda (k v) (push (return-something k
    v) mapped-hash))) (mapcar 'modification-2 (mapcar 'modification-1
    mapped-hash)))

For full backward compatibility (some code may depend on maphash
returning nil) and preserving the performance advantage, why not
introduce an optional argument to all those builtin “map...” functions
or an alternative version that returns the values (sort of like the
mapc, mapcar pair).

As for cl-loop: I use that macro alot. However, it is unnecessarily
limiting, as there isn't a corespondence for all “map...” functions
that don't return values. Then you're back to some

  (let (x) (map... (lambda (..) (push .. x))) x)

again in order to get the input-value for the loop. Also, when I see
“mapcar” I know a list will be returned -- with “cl-loop” there is no
such clarity. Also, unlike general “map...” functions, cl-loop is like
a separate language to be learned.

While of course everyone can define a “hashmap” function as described
or similiarily a “atommap” or “keymapmap”, I'd expect code-readability
to suffer from having custom functions for such things, unless they
are implemented in a widely used package like “cl-lib”, though then
again, such functions wouldn't have anything todo with common lisp.

To be fair though, the standard indentation scheme doesn't promote
this style of programming either. In standard indentation, the above
example would read either (ignoring that maphash doesn't return the
list of values)

  (mapcar 'modification-2 
          (mapcar 'modifification-1 
                  (maphash (lambda (k v) (return-something k v)))))

or

  (mapcar 
   'modification-2 
   (mapcar 
    'modifification-1 
    (maphash (lambda (k v) (return-something k v)))))

kind regards, Klaus