In Erlang it is fairly common to want to perform a side-effecty operation over a list of values, not because you want to collect an aggregate (fold), actually map the input list to the output list (map), or build a new list in some way (list comprehension) but because you just want the side-effects of the operation.
The typical idiom (especially for broadcasting messages to a list of processes) is to use a list comprehension for this, or sometimes lists:map/2:
%% Some procedural side-effect, like spawning list of processes or grabbing %% a list of resources: [side_effecty_procedure(X) || X <- ListOfThings], %% Or, for broadcasting: [Pid ! SomeMessage || Pid <- ListOfPids], %% And some old farts still do this: lists:map(fun side_effecty_procedure/1, ListOfThings), %% Or even this (gasp!) which is actually made for this sort of thing: lists:foreach(fun side_effecty_procedure/1, ListOfThings), %% but lacks half of the semantics I describe below, so this part %% of the function namespace is already taken... (q.q)
That works just fine, and is so common that list comprehensions have been optimized to handle this specific situation in a way that avoids creating a return list value if it is clearly not going to be assigned to anything. I remember thinking this was sort of ugly, or at least sort of hackish before I got accustomed to the idiom, though. “Hackish” in the sense that this is actually a syntax intended for the construction of lists and only incidentally a useful way to write a fast side-effect operation over a list of values, and “ugly” in the sense that it is one of the few places in Erlang you can’t force an assertion to check the outcome of a side-effecty operation.
For example, there is no equivalent to the assertive ok = some_procedure() idiom, or even the slightly more complex variation used in some other situations:
case foo(Bar) of
ok -> Continue();
Other -> Other
end,
a compromise could be to write an smap/2 function defined something like
smap(F, List) ->
smap(F, 1, List).
smap(F, N, []) ->
ok;
smap(F, N, [H|T]) ->
case F(H) of
ok -> smap(F, N + 1, T);
{error, Reason} -> {error, {N, Reason}}
end.
But this now has the problem of requiring that whatever is passed as F/1 have a return type of ok | {error, Reason} which is unrealistic without forcing a lot of folks to wrap existing side-effecty functions in something that coerces the return type to match this. Though that might not be bad practice ultimately, its still perhaps more trouble than its worth.
It isn’t like most Erlang code is written in a way where side-effecty iteration over a list is likely to fail, and if it actually does fail the error data from a crash will contain whatever was passed to the side-effecty function that failed. But this still just doesn’t quite sit right with me — that leaves the prospect of list iteration in the interest of achieving a series of side effects as at least a little bit risky to do in the error kernel (or “crash kernel”) of an application.
On the other hand, the specific case of broadcasting to a list of processes would certainly be nice to handle exactly the same way sending to a single process works:
%% To one message Pid ! SomeMessage, %% To a list of messages Pids ! SomeMessage,
Which seems particularly obvious syntax, considering that the return of the ! form of send/2 is the message itself, meaning that the following two would be equivalent if the input to the ! form of send/2 also accepted lists:
%% The way it works now Pid1 ! Pid2 ! SomeMessage, %% Another way I wish it worked [Pid1, Pid2] ! SomeMessage,
In any case, this is clearly not the sort of language wart that gets much attention, and its never been a handicap for me. It just seems a bit hackish and ugly to essentially overload the semantics of list comprehensions or (ab)use existing list operations like maps and folds to achieve the side effect of iterating over a list instead of having a function like smap/2 which is explicitly designed to achieve side-effecty iteration.