map.el and naming

map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

Hi,

I'm working on another library similar to seq.el but for maps (alists
and hash-tables for now).

I have an issue with naming regarding mapping over keys/values of a
map. I thought about calling `map-map' the function that would map over
the keys and values of map, and `map-map-keys' the function that would
map over the keys of a map, etc.

This is really ugly to my eyes, as there is map the name and map the
verb.  Does anyone have a better idea?

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Bozhidar Batsov]

[-- Attachment #1: Type: text/plain, Size: 809 bytes --]

Maybe you can call the lib `assoc.el` or something like this, as `map.el`
sounds kind of confusing (I wouldn't expect something named this way to
work with alists). Btw, what about plists?

On 28 February 2015 at 14:24, Nicolas Petton <nicolas@petton.fr> wrote:

> Hi,
>
> I'm working on another library similar to seq.el but for maps (alists
> and hash-tables for now).
>
> I have an issue with naming regarding mapping over keys/values of a
> map. I thought about calling `map-map' the function that would map over
> the keys and values of map, and `map-map-keys' the function that would
> map over the keys of a map, etc.
>
> This is really ugly to my eyes, as there is map the name and map the
> verb.  Does anyone have a better idea?
>
> Cheers,
> Nico
> --
> Nicolas Petton
> http://nicolas-petton.fr
>

[-- Attachment #2: Type: text/html, Size: 1286 bytes --]

Re: map.el and naming

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Date: Sat, 28 Feb 2015 13:24:55 +0100
> 
> I'm working on another library similar to seq.el but for maps (alists
> and hash-tables for now).
> 
> I have an issue with naming regarding mapping over keys/values of a
> map. I thought about calling `map-map' the function that would map over
> the keys and values of map, and `map-map-keys' the function that would
> map over the keys of a map, etc.

Are there any reasons why we couldn't have map-keys that could accept
any object where such an operation makes sense?  IOW, why do we have
to use different functions for different classes of objects, instead
of having a single polymorphic interface?  That would solve the naming
issue as a nice side effect, and more importantly, will allow the
programmer to remember fewer symbols.

Re: map.el and naming

[Artur Malabarba]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

I have no preference for the name, but I agree there's no reason to divide
this functionality in two.
On Feb 28, 2015 1:49 PM, "Eli Zaretskii" <eliz@gnu.org> wrote:

> > From: Nicolas Petton <nicolas@petton.fr>
> > Date: Sat, 28 Feb 2015 13:24:55 +0100
> >
> > I'm working on another library similar to seq.el but for maps (alists
> > and hash-tables for now).
> >
> > I have an issue with naming regarding mapping over keys/values of a
> > map. I thought about calling `map-map' the function that would map over
> > the keys and values of map, and `map-map-keys' the function that would
> > map over the keys of a map, etc.
>
> Are there any reasons why we couldn't have map-keys that could accept
> any object where such an operation makes sense?  IOW, why do we have
> to use different functions for different classes of objects, instead
> of having a single polymorphic interface?  That would solve the naming
> issue as a nice side effect, and more importantly, will allow the
> programmer to remember fewer symbols.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1420 bytes --]

Re: map.el and naming

[Stefan Monnier]

> map. I thought about calling `map-map' the function that would map over
> the keys and values of map, and `map-map-keys' the function that would
> map over the keys of a map, etc.

Indeed, these names kind of suck.  For `map-map-keys', you could use `
map-keys', tho this name could also be used for a function which just
returns the list of keys.  For `map-map' you could use `map-apply' or
`map-kv' (for "keys and values").

> This is really ugly to my eyes, as there is map the name and map the
> verb.

Agreed.


        Stefan


PS: BTW, among the maps to include, we of course need to support
vectors and char-tables, as well.

Re: map.el and naming

[Stefan Monnier]

> Are there any reasons why we couldn't have map-keys that could accept
> any object where such an operation makes sense?

That's exactly what he's doing.

> IOW, why do we have to use different functions for different classes
> of objects, instead of having a single polymorphic interface?

He's not suggesting different functions for different objects, but
different function for different operations (e.g. either apply
a function to each key in the map, or apply a function to each
key+value in the map).


        Stefan

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 1045 bytes --]

Eli Zaretskii writes:

>> From: Nicolas Petton <nicolas@petton.fr>
>> Date: Sat, 28 Feb 2015 13:24:55 +0100
>> 
>> I'm working on another library similar to seq.el but for maps (alists
>> and hash-tables for now).
>> 
>> I have an issue with naming regarding mapping over keys/values of a
>> map. I thought about calling `map-map' the function that would map over
>> the keys and values of map, and `map-map-keys' the function that would
>> map over the keys of a map, etc.
>
> Are there any reasons why we couldn't have map-keys that could accept
> any object where such an operation makes sense?

That's what I'm doing :)

The only issue I have is regarding naming.  Stefan proposed to name the
library map.el, which I like.  The only issue I have is that "map" is
used for the noun (a map) and the verb (to map over things).  The result
is that to map over the keys/values of a map, I have a function named
`map-map', and I think that's unclear and ugly.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: Nicolas Petton <nicolas@petton.fr>, emacs-devel@gnu.org
> Date: Mon, 02 Mar 2015 08:38:44 +0100
> 
> >> I'm working on another library similar to seq.el but for maps (alists
> >> and hash-tables for now).
> >> 
> >> I have an issue with naming regarding mapping over keys/values of a
> >> map. I thought about calling `map-map' the function that would map over
> >> the keys and values of map, and `map-map-keys' the function that would
> >> map over the keys of a map, etc.
> >
> > Are there any reasons why we couldn't have map-keys that could accept
> > any object where such an operation makes sense?
> 
> That's what I'm doing :)

Then why are you writing a separate library, which is "similar to
seq.el but for maps"?  Why not have a single library that handles all
of these objects: lists, strings, vectors, alists, and hash-tables?

> The only issue I have is regarding naming.  Stefan proposed to name the
> library map.el, which I like.  The only issue I have is that "map" is
> used for the noun (a map) and the verb (to map over things).  The result
> is that to map over the keys/values of a map, I have a function named
> `map-map', and I think that's unclear and ugly.

If you have a single library, this issue will go away, right?

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 435 bytes --]


Eli Zaretskii writes:

> Then why are you writing a separate library, which is "similar to
> seq.el but for maps"?  Why not have a single library that handles all
> of these objects: lists, strings, vectors, alists, and hash-tables?

Isn't it better to treat sequences and maps separate kind of
collections?  They are IMHO too different to be both in the same
library.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Eli Zaretskii]

> From: Nicolas Petton <nicolas@petton.fr>
> Cc: Nicolas Petton <nicolas@petton.fr>, emacs-devel@gnu.org
> Date: Mon, 02 Mar 2015 14:26:43 +0100
> 
> > Then why are you writing a separate library, which is "similar to
> > seq.el but for maps"?  Why not have a single library that handles all
> > of these objects: lists, strings, vectors, alists, and hash-tables?
> 
> Isn't it better to treat sequences and maps separate kind of
> collections?  They are IMHO too different to be both in the same
> library.

But polymorphism _is_ about using the same APIs for treating different
objects.  Do any of the operations in seq.el make sense with the
objects you meant to handle in map.el?  If so, it could make sense to
have them treated by the same API.

Anyway, if the above doesn't sound right, I can suggest maps.el and
correspondingly maps-map-key etc.

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 846 bytes --]


Stefan Monnier writes:

>> map. I thought about calling `map-map' the function that would map over
>> the keys and values of map, and `map-map-keys' the function that would
>> map over the keys of a map, etc.
>
> Indeed, these names kind of suck.  For `map-map-keys', you could use `
> map-keys', tho this name could also be used for a function which just
> returns the list of keys.  For `map-map' you could use `map-apply' or
> `map-kv' (for "keys and values").

I used `map-keys' to return the list of keys indeed.  I don't really
like `map-kv', seems cryptic to me.  `map-apply' could work, but it's
still not as good as `seq-map' for example.

Maybe naming the library map.el isn't a good fit afterall, as map also
refers to mapping.  Would anyone have another idea?

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Artur Malabarba]

> But polymorphism _is_ about using the same APIs for treating different
> objects.

Yes, but associations (or maps) and sequences are not just different
objects, they're different abstractions too. There are many operations
which make sense on both, but even then Emacs has no automatic way of
deciding which version to employ (see below).

> Do any of the operations in seq.el make sense with the
> objects you meant to handle in map.el?  If so, it could make sense to
> have them treated by the same API.

Many certainly do, but the way they must be handled is different for
sequences and associations.
For instance, if you map over a list, you want the function will be
called on each element, but if you map over an association, you want
the function to be called on each key-value pair.

Now, take a plist as an example. If you call `seq-map' on a 2-element
list where the first element happens to be a keyword, `seq.el' has no
way of knowing if you intended to use that as a sequence or as an
association, therefore it just can't handle both cases.
That's why you need two libraries. If you want to map over sequences,
you call seq-map, if you want to map over an association, you call
`map-map' (or whatever it ends up being called).

This won't only happen with mapping, I think it will happen with
enough other functions to warrant a different library. Of course this
library doesn't have to reimplement everything from scratch, it can
and should fallback on seq.el whenever possible (just like seq.el
sometimes falls back on built-ins like `mapcar').

Re: map.el and naming

[Eli Zaretskii]

> Date: Mon, 2 Mar 2015 14:33:14 +0000
> From: Artur Malabarba <bruce.connor.am@gmail.com>
> Cc: Nicolas Petton <nicolas@petton.fr>, emacs-devel <emacs-devel@gnu.org>
> 
> > But polymorphism _is_ about using the same APIs for treating different
> > objects.
> 
> Yes, but associations (or maps) and sequences are not just different
> objects, they're different abstractions too. There are many operations
> which make sense on both, but even then Emacs has no automatic way of
> deciding which version to employ (see below).

I thought the object type should give enough information about that.

> Now, take a plist as an example. If you call `seq-map' on a 2-element
> list where the first element happens to be a keyword, `seq.el' has no
> way of knowing if you intended to use that as a sequence or as an
> association, therefore it just can't handle both cases.
> That's why you need two libraries. If you want to map over sequences,
> you call seq-map, if you want to map over an association, you call
> `map-map' (or whatever it ends up being called).

I asked whether it would make sense to have the same APIs for both
groups, and where just the type of the object provides enough
information for choosing how to process it.  If you are saying that
doesn't make a lot of sense, then I guess polymorphism doesn't make
much sense in this case.

> This won't only happen with mapping, I think it will happen with
> enough other functions to warrant a different library. Of course this
> library doesn't have to reimplement everything from scratch, it can
> and should fallback on seq.el whenever possible (just like seq.el
> sometimes falls back on built-ins like `mapcar').

If there are APIs that make sense for maps, IMO they should be generic
APIs that can handle both objects now handled by seq.el and those in
map.el.  IOW, if only some of the APIs must be map-specific, that
doesn't mean we need to make them all map-specific, IMO.

Re: map.el and naming

[Artur Malabarba]

> I asked whether it would make sense to have the same APIs for both
> groups, and where just the type of the object provides enough
> information for choosing how to process it.

Sorry for being so roundabout. I think the answer here is just "no"
because there are no `plist' or `alist' object type (and there is no
foolproof way of determining whether a given list is intended as a
plist or not).

Re: map.el and naming

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > If there are APIs that make sense for maps, IMO they should be generic
 > APIs that can handle both objects now handled by seq.el and those in
 > map.el.  IOW, if only some of the APIs must be map-specific, that
 > doesn't mean we need to make them all map-specific, IMO.

This just doesn't make sense in Emacs Lisp because (with the exception
of hash-tables) mapping types are represented as lists, and the only
way to determine whether a list is a sequence or a map is by looking
at the function you call on it.

Re: map.el and naming

[Stefan Monnier]

> of these objects: lists, strings, vectors, alists, and hash-tables?

Think of `seq' and `map' as (Java) interfaces, which can be implemented
by various low-level representations.

Some representations (e.g. lists or vectors) can implement both interfaces.


        Stefan

Re: map.el and naming

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > of these objects: lists, strings, vectors, alists, and hash-tables?
 > 
 > Think of `seq' and `map' as (Java) interfaces, which can be implemented
 > by various low-level representations.
 > 
 > Some representations (e.g. lists or vectors) can implement both interfaces.

Please, let's not go there.  Emacs Lisp is by design, history, and
current practice in Emacs primarily a non-object-oriented language.
It's not object-oriented at the level of Java or Haskell, and
certainly not Smalltalk.  Granted, it is certainly possible to
implement true[1] objects in Lisp, and it's a very valuable technique
in Emacs too (eg, the various components of CEDET).

But the "objects" listed in the quote above are not objects in this
sense.  They don't know their own subclass, and so cannot tell a
function operating on them that "I'm a cons" (Lisp knows that) "which
is the head of a list representing a map using the 'property list'
API" (Lisp can't know that for those objects).  This is a deliberate
design principle; RMS wanted Emacs data structures to be
introspectable, and he chose to do that by avoiding ADTs except where
absolutely necessary for efficiency (buffers, strings, vectors,
hash-tables), and instead building everything out of a few primitive
data types and embedding knowledge of data structures in functions.
This allows a person with access to the source of those functions to
introspect the corresponding data structures.  (How 1970s!  Sure, but
that's when Emacs was designed....)

Certainly it's possible to implement polymorphic functions, too.  But
here, AFAICS we already have the useful ones for sequences (nth, for
one).  I agree that "cons", "car", and "cdr" are not very discoverable
for new learners, but then the ambiguous use of "map" (as a verb, it
either means "iterate over a sequence" or "describe a functional
relationship") is hardly helpful to them.  I really don't see what
benefit these new faux-namespaces (seq.el, map.el) provide, except to
worshippers of consistency.  This is quite different from the
situation with cl-lib, where Common Lisp often uses the same
identifiers as Emacs Lisp with different semantics, and also often
provides rather sophisticated functionality that is not necessary in
"base Emacs" (though extremely expressive and useful in the advanced
applications which make Emacs so powerful).

If you want to build an object-oriented language into Lisp, great.
But first you need objects.  (XEmacs already uses OO implementation
techniques at the C level, but I gather from other threads that in
Emacs such usage is spotty at best.)  We already have EIEIO.  That may
not be appropriate for "promotion" into the core language, or perhaps
people would prefer CLOS or maybe something more appropriate for an
eventual Guile-based Emacs "Lisp".

Footnotes: 
[1]  By which I mean in the conventional sense of "object orientation".

Re: map.el and naming

[bburns.km]

assoc would make sense, as it's for an associative array data type, though it
might be a bit confusing as it's also the name of a function. 

From the definition,

| A map (aka associative array, dictionary, symbol table) is an abstract
data type composed of a collection of (key, value) pairs, such that each
possible key appears at most once in the collection. 

another possibility would be kv.el, for key-value - e.g. you sometimes hear
them referred to as key-value stores. Then kv-map, kv-keys, kv-values, etc.
Or keyvalue.el, then keyvalue-map, keyvalue-keys, etc.





--
View this message in context: http://emacs.1067599.n5.nabble.com/map-el-and-naming-tp350974p351216.html
Sent from the Emacs - Dev mailing list archive at Nabble.com.

Re: map.el and naming

[Stefan Monnier]

> Please, let's not go there.

You must have missed the "Think of" part of my answer.  OO is not just
a bunch of programming language semantics, but is also a way to think
about and design programs.


        Stefan

Re: map.el and naming

[Stephen J. Turnbull]

Stefan Monnier writes:

 > > Please, let's not go there.
 > 
 > You must have missed the "Think of" part of my answer.  OO is not
 > just a bunch of programming language semantics, but is also a way
 > to think about and design programs.

I don't see how "Think of" makes a difference.  We're not talking
about designing programs here, we're talking about designing
languages, specifically Emacs Lisp.  The question is how much
object-orientation of Emacs Lisp primitive types can we implement in
Lisp, and the answer AFAICS is "no more than we already have".

In any case, my main point was that I don't see why seq.el and map.el,
with their pseudo-namespace prefixes, are a good idea for Emacs Lisp.
Sure, if there are useful new operations, add them; if they can be
polymorphic with mnemonic names, better yet.  But AFAICS most of the
interesting polymorphism is already available through functions like
nth.  There's a reason why setnth doesn't exist, you know.  And
mnemonic synonyms (first, rest, ...) are common already.  (Similarly,
there's a reason why rest isn't polymorphic over arrays and strings.)

A wholesale cleanup isn't going to be possible without the kind of
effort required to change the underlying Lisp engine to a Scheme or
Common Lisp implementation.  So AFAICS these pseudo-namespaces are not
going to improve the language.

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

bburns.km writes:

> assoc would make sense, as it's for an associative array data type, though it
> might be a bit confusing as it's also the name of a function. 
>
> From the definition,
>
> | A map (aka associative array, dictionary, symbol table) is an abstract
> data type composed of a collection of (key, value) pairs, such that each
> possible key appears at most once in the collection. 
>
> another possibility would be kv.el, for key-value - e.g. you sometimes hear
> them referred to as key-value stores. Then kv-map, kv-keys, kv-values, etc.
> Or keyvalue.el, then keyvalue-map, keyvalue-keys, etc.

I thought about that, but assoc.el and kv.el already exist.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Nic Ferrier]

nicolas@petton.fr writes:

> bburns.km writes:
>
>> assoc would make sense, as it's for an associative array data type, though it
>> might be a bit confusing as it's also the name of a function. 
>>
>> From the definition,
>>
>> | A map (aka associative array, dictionary, symbol table) is an abstract
>> data type composed of a collection of (key, value) pairs, such that each
>> possible key appears at most once in the collection. 
>>
>> another possibility would be kv.el, for key-value - e.g. you sometimes hear
>> them referred to as key-value stores. Then kv-map, kv-keys, kv-values, etc.
>> Or keyvalue.el, then keyvalue-map, keyvalue-keys, etc.
>
> I thought about that, but assoc.el and kv.el already exist.

Why don't you send PRs to kv then?

I'd be happy to put kv into elpa as well as marmalade.


Nic

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 819 bytes --]


Nicolas Petton writes:

> Hi,
>
> I'm working on another library similar to seq.el but for maps (alists
> and hash-tables for now).
>
> I have an issue with naming regarding mapping over keys/values of a
> map. I thought about calling `map-map' the function that would map over
> the keys and values of map, and `map-map-keys' the function that would
> map over the keys of a map, etc.
>
> This is really ugly to my eyes, as there is map the name and map the
> verb.  Does anyone have a better idea?

I'm back with this issue.  Since I have "map" both as a verb and as a
name, and because I don't want to call "mapping" something else, I think
I'll go with renaming the library.

What do you think about "hash"?  It seems to be the name used in Ruby
such collections[1].


[1] http://ruby-doc.org/core-2.2.1/Hash.html

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Stefan Monnier]

> I'm back with this issue.  Since I have "map" both as a verb and as a
> name, and because I don't want to call "mapping" something else, I think
> I'll go with renaming the library.
> What do you think about "hash"?

Hmm... I don't like it very much because "hash" sounds very much like
one particular underlying implementation, rather than the
general concept.


        Stefan

Re: map.el and naming

[Stefan Monnier]

> I'm back with this issue.  Since I have "map" both as a verb and as a
> name, and because I don't want to call "mapping" something else, I think
> I'll go with renaming the library.

BTW, to give some idea of the tradeoffs, could you remind us of the main
concrete problems you face when using "map" as the library name
(i.e. actual functions whose name is hard to choose)?


        Stefan

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]


Stefan Monnier writes:

>> I'm back with this issue.  Since I have "map" both as a verb and as a
>> name, and because I don't want to call "mapping" something else, I think
>> I'll go with renaming the library.
>> What do you think about "hash"?
>
> Hmm... I don't like it very much because "hash" sounds very much like
> one particular underlying implementation, rather than the
> general concept.

True.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 743 bytes --]


Stefan Monnier writes:

>> I'm back with this issue.  Since I have "map" both as a verb and as a
>> name, and because I don't want to call "mapping" something else, I think
>> I'll go with renaming the library.
>
> BTW, to give some idea of the tradeoffs, could you remind us of the main
> concrete problems you face when using "map" as the library name
> (i.e. actual functions whose name is hard to choose)?

Sure.

`map-map-keys', `map-map-values' and `map-map' are the issue here.

Stefan, IIRC you suggested `map-keys-apply', `map-values-apply' and
`map-apply', and while it would work, I like the verb "map" much more
(it's also consistent with seq.el).

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 279 bytes --]

On Fri, Apr 10, 2015 at 8:52 PM, Nicolas Petton <nicolas@petton.fr> wrote:

> Since I have "map" both as a verb and as a
> name, and because I don't want to call "mapping" something else, I think
> I'll go with renaming the library.
>

Perhaps name the library "mapping"?

/john

[-- Attachment #2: Type: text/html, Size: 675 bytes --]

Re: map.el and naming

[Artur Malabarba]

Would it be plausible to name the library "map.el", but name the
functions "m-" instead of "map-" (i.e., abbreviate the library name)?

The library could also be named "maps.el". It's slightly unorthodox to
use the plural, but it would emphasize that it refers to maps and not
to mapping.

2015-04-11 14:55 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>> I'm back with this issue.  Since I have "map" both as a verb and as a
>> name, and because I don't want to call "mapping" something else, I think
>> I'll go with renaming the library.
>
> BTW, to give some idea of the tradeoffs, could you remind us of the main
> concrete problems you face when using "map" as the library name
> (i.e. actual functions whose name is hard to choose)?
>
>
>         Stefan
>

Re: map.el and naming

[John Yates]

[-- Attachment #1: Type: text/plain, Size: 449 bytes --]

On Sat, Apr 11, 2015 at 10:11 AM, Nicolas Petton <nicolas@petton.fr> wrote:

> `map-map-keys', `map-map-values' and `map-map' are the issue here.
>

In my life as a C++ programmer I follow a convention in which type names
start with an uppercase letter and run-time denotations names start with a
lowercase letter.  I expect case-sensitive naming is a non-starter here but
just for yucks...
- Map.el
- Map-map-keys
- Map-map-values
- Map-map

/john

[-- Attachment #2: Type: text/html, Size: 1021 bytes --]

Re: map.el and naming

[Dmitry Gutov]

On 04/11/2015 05:11 PM, Nicolas Petton wrote:

> `map-map-keys', `map-map-values' and `map-map' are the issue here.

Why not drop the first `map-' in the function names?

Naming both the package and one of the functions in it simply `map' 
sounds good to me.

That would conflict with `map' alias in cl.el, though...

Re: map.el and naming

[Artur Malabarba]

> Why not drop the first `map-' in the function names?
>
> Naming both the package and one of the functions in it simply `map' sounds
> good to me.

That would deceptive, as it sounds like a general mapping function,
not something that only applies to associative structures.

Re: map.el and naming

[John Mastro]

Nicolas Petton <nicolas@petton.fr> wrote:

> > I'm working on another library similar to seq.el but for maps (alists
> > and hash-tables for now).
> >
> > I have an issue with naming regarding mapping over keys/values of a
> > map. I thought about calling `map-map' the function that would map over
> > the keys and values of map, and `map-map-keys' the function that would
> > map over the keys of a map, etc.
> >
> > This is really ugly to my eyes, as there is map the name and map the
> > verb.  Does anyone have a better idea?
>
> I'm back with this issue.  Since I have "map" both as a verb and as a
> name, and because I don't want to call "mapping" something else, I think
> I'll go with renaming the library.

How about "mapping.el"? Not a verb, as in "mapping over a list", but
rather a noun, as in "a hash table (or an association list) is a mapping
from keys to values."

So you would have e.g. `mapping-map' and `mapping-map-keys'. It loses
some of the nice concision of "map" (and of course "map" still shows up
twice), but it doesn't seem too bad to me.

-- 
john

Re: map.el and naming

[Stefan Monnier]

> Would it be plausible to name the library "map.el", but name the
> functions "m-" instead of "map-" (i.e., abbreviate the library name)?

Yes, the problem under discussion is the prefix to use for the
functions.  The name of the library is much less of an issue.  Usually,
they're more or less the same, but they don't have to be.


        Stefan

Re: map.el and naming

[Stefan Monnier]

>> `map-map-keys', `map-map-values' and `map-map' are the issue here.
> Why not drop the first `map-' in the function names?

Because map-keys would most naturally be the name of a function which
returns the keys of a map.

> Naming both the package and one of the functions in it simply `map' sounds
> good to me.

For map-map, we could live with just "map", indeed, in theory, but...

> That would conflict with `map' alias in cl.el, though...

Indeed, that would be a problem (while cl.el is being phased out, it's
still in very common use, so the conflict would bite rather often).


        Stefan

Re: map.el and naming

[Stefan Monnier]

> So you would have e.g. `mapping-map' and `mapping-map-keys'. It loses
> some of the nice concision of "map" (and of course "map" still shows up
> twice), but it doesn't seem too bad to me.

To catch on, it's very important for the prefix to be short.  So I think
"mapping-" won't do.


        Stefan

Re: map.el and naming

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 442 bytes --]

On 04/11/2015 08:34 PM, Stefan Monnier wrote:
>> So you would have e.g. `mapping-map' and `mapping-map-keys'. It loses
>> some of the nice concision of "map" (and of course "map" still shows up
>> twice), but it doesn't seem too bad to me.
> 
> To catch on, it's very important for the prefix to be short.  So I think
> "mapping-" won't do.

"dict-" is short. "Dictionary" is another well-known name for a mapping
data structure.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: map.el and naming

[Stefan Monnier]

> "dict-" is short. "Dictionary" is another well-known name for a mapping
> data structure.

"dict-" is OK with me.


        Stefan

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 408 bytes --]


Stefan Monnier writes:

>> "dict-" is short. "Dictionary" is another well-known name for a mapping
>> data structure.
>
> "dict-" is OK with me.

It would be fine (short and meaningful), but I don't really like how it
sounds.  I know I'm being picky here...

Thanks for the suggestions everyone, I'll think about this for a while.

Cheers,
Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]

Re: map.el and naming

[Stefan Monnier]

>>> "dict-" is short. "Dictionary" is another well-known name for a mapping
>>> data structure.
>> "dict-" is OK with me.
> It would be fine (short and meaningful), but I don't really like how it
> sounds.  I know I'm being picky here...

I also prefer "map-" in general, FWIW.

> Thanks for the suggestions everyone, I'll think about this for a while.

So it seems the alternative is between finding a replacement for the
"map, the type" (where "dict" is the best candidate so far) and finding
a replacement for "map, the operation" (not sure what the best
candidates would be here, maybe "iterate", or "loop", or "visit"?).


        Stefan

Re: map.el and naming

[Stephen J. Turnbull]

Stefan Monnier writes:

 > >>> "dict-" is short. "Dictionary" is another well-known name for a mapping
 > >>> data structure.

+1  I like how it sounds, and the way it phonetically distinguishes
between the object and the operation.

 > So it seems the alternative is between finding a replacement for the
 > "map, the type" (where "dict" is the best candidate so far) and finding
 > a replacement for "map, the operation" (not sure what the best
 > candidates would be here, maybe "iterate", or "loop", or "visit"?).

Try "visit", please.  Iterate and loop imply linear order to some
extent, and people often assume the order is stable against insertion.
(Yeah, I know, in fact "iterate" doesn't imply any such thing, and the
implication in "loop" is pretty weak.  It's just that I've seen this
happen with "iterate" in Python.)

Re: map.el and naming

[Yuri Khan]

On Sun, Apr 12, 2015 at 7:38 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

>  > So it seems the alternative is between finding a replacement for the
>  > "map, the type" (where "dict" is the best candidate so far) and finding
>  > a replacement for "map, the operation" (not sure what the best
>  > candidates would be here, maybe "iterate", or "loop", or "visit"?).
>
> Try "visit", please.  Iterate and loop imply linear order to some
> extent, and people often assume the order is stable against insertion.
> (Yeah, I know, in fact "iterate" doesn't imply any such thing, and the
> implication in "loop" is pretty weak.  It's just that I've seen this
> happen with "iterate" in Python.)

Another term is “for-each”, although it also has a slight connotation
that the function being mapped over the collection is called primarily
for its side effect rather than return value.

Re: map.el and naming

[Nicolas Petton]

[-- Attachment #1: Type: text/plain, Size: 842 bytes --]


Stefan Monnier writes:

>>>> "dict-" is short. "Dictionary" is another well-known name for a mapping
>>>> data structure.
>>> "dict-" is OK with me.
>> It would be fine (short and meaningful), but I don't really like how it
>> sounds.  I know I'm being picky here...
>
> I also prefer "map-" in general, FWIW.
>
>> Thanks for the suggestions everyone, I'll think about this for a while.
>
> So it seems the alternative is between finding a replacement for the
> "map, the type" (where "dict" is the best candidate so far) and finding
> a replacement for "map, the operation" (not sure what the best
> candidates would be here, maybe "iterate", or "loop", or "visit"?).

The candidate I like the most is "apply": `map-apply', `map-keys-apply'
and `map-values-apply'.

Nico
-- 
Nicolas Petton
http://nicolas-petton.fr

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 512 bytes --]