Not all maps are hashmaps, like The Beam’s map is not a hashmap, rather it ‘starts’ as a form of linked list, then once it reaches like 32 elements or so it swaps to some kind of tree I think (or was it a hash lookup?).
In C++ I’ll often use a hashmap for unordered large collections, but I’ll use an RBTreeMap for when I have less than around 10 elements as it is just so much faster at small sizes (though slower at large), which makes it great to use for an Event data structure for example.
I honestly think it’s more for use by code generators, like javascript’s Symbol stuff is too. ^.^
Even then, the map function is mapping a set of inputs to a set of outputs, which is the very definition of a pure function over a set of ‘things’. Something like Enum.apply I would entirely expect it to take an enumerable of functions that it would then call on a value or so. Enum.all I would expect to return a boolean of whether all elements in an enumerable pass some condition check.
Better than C++ calling map as transform or C++ calling reduce as accumulate. ^.^;
I tend to think of Elixir as in ‘magical potion’, which makes a ‘hex’ or whatever. ^.^
Exactly! I should probably do a set of posts here on category theory (or on my blog, little-used it is) and how elixir uses it.
Lol, but it’s so darned convenient and unambiguous! ^.^
transform alone no, but transform_each would be more correct-ier ? map, while mapping a set of inputs to outputs, doesn’t really provide you with a map between those inputs and outputs in the end, so you don’t end with a map (a was_mapped_to b).
I always thought objects were JS’s maps that incidently could be other things too. Ah.
The problem is that it isn’t transforming, it’s mapping, it’s not changing the input, rather it’s taking the input, mapping it, and writing a new output. ^.^
Interestingly the C++ transform function can also take a function that takes two inputs, which would be the current element as well as the last value output, it’s a pattern that was useful on only a single occasion or two but one in which I don’t see in most functional languages. It would be like making this (typed in-post, may not compile):
defmodule Blah do
def bloop([], _fun, prior \\ null, output \\ []) do
:lists.reverse(output)
end
def bloop([elem | lst], fun, prior, output) do
elem = fun.(prior, elem)
bloop(lst, fun, elem, [elem | output])
end
end
Not at all actually, and in doing so will cause a major performance hit in many applications.
Specifically a Javascript object in about every VM out gets ‘reified’ to a C/C+±like struct with defined in fields in defined places to get super fast, this is known in the VM world as the ‘Shape’ of the object, and as long as that doesn’t change it can be super-optimized. However, using an object as a map means it’s shape is always changing so it can’t hoist calls to direct fields, forcing it to fall back to a map lookup via the VM instead of native code, which can very well be slower than a dedicated map type (even one defined in javascript itself).
They don’t always end up with Merge’s though, but do always involve pulling down other’s data and doing something with it to store it in the local repository (whether a merge or not, though that is the common way on github, but not everyone uses github).
Yes, but the submitter’s intent is (always?) to merge.
At least when doing PR’s in github and etc. (which is github’s feature/interface, not git’s). Git has git request-pull, where wording and intention are bit different.
About map: There are many terms in functional programming that are weird to people coming from different places, since they have their roots in Category Theory. However, using a different name for these concepts (I’m talking about things like Semigroups, Monoids, Functors, Applicative Functors, Foldables, Monads) would not capture their precise meaning.
(And besides that, make it impossible to search for the last 40+ years of research and tutorials about them).
Disclaimer: The following isn’t intended as a proposal for change, but rather the viewpoint of someone who doesn’t really care about the theoretical side of Haskell’s relationship with category theory.
On that note, though, “functor” as it’s used in programming languages at the moment is fairly imprecise.
From a practical perspective I think naming that is focused more on attributes is clearer. Mappable is more descriptive and to the point than Functor. I’d never argue to change it, but I do think it’d make people connect with the concept a bit more. It also flows better with superclass restrictions: Mappable => Applyable/Applicable(?) => Bindable describing a tree of attributes that something has.
Not always. I’ve PR’d a lot of repo’s just for the purpose of demonstrating something, testing something, etc… etc…
Except a functor maps from one ‘container’ type to that same ‘container’ type, where a map ‘maps’ from one ‘container’ type to a different ‘container’ type. Whatever type each hold internally can be different of course, it’s the container types that matter. And indeed languages like OCaml and Haskell follow this pretty well. I might have it backwards, I havn’t had coffee yet… >.>
The name Functor has almost no practical relevance for how to use them in Haskell/OCaml and it really is only because of the crowd that they don’t have names that map directly to what they represent in a practical sense.
I guess I’m just not seeing it. I think these kinds of things have been poison to Haskell (maybe more so than other languages) because there is what I perceive as a shroud of abstract stuff that really doesn’t have much to do with the practical usage of things and I think that’s where a lot of people needlessly give up.
I agree that you can see both in Haskell and ML what they were thinking with naming things “functor”, but it’s not a productive link and I don’t think “getting it” in one translates very well to the other, because both have chosen an arbitrary thing to represent this abstract idea.
I personally very much dislike the light-hearted and joke-y names people give to things in programming – like “gems” in Ruby. Just call it a “library” or “addon” or “plugin” and get it over with? Most of us I bet don’t need warm fuzzy feelings when working with code.
I agree with @Qqwy on a common thesaurus but ultimately only a small subset of people would use it and the internet forums will have one more reason to engage in flame wars (“look at him, he calls Map a Hash! what a noob”).
Unless we have a Skynet level of AI that immediately censors anything not well-named after uploading it I don’t see a common terminology ever taking off.
Heh, “of course” everyone knows that if you are working with its interface you should call it a Dictionary, whereas when working with its internals, it would be a HashMap!
