[erlang-questions] Erlang/YAWS vs Free Pascal/Xitami
Richard A. O'Keefe
Fri Mar 28 05:32:33 CET 2008
> This is a "toy" example, but in Perl I made this mistake (again)
> just yesterday:
> my $thing = get_somestuff(...);
> And of course it really needed to be my ($thing) or my @thing or my
> (@thing). "Difficult to track" is relative, but by the time this all
> bubbled up into a failure it took a silly amount of time to identify
> (a half hour or an hour).
Perl is very much a special case.
In comparison, I've been keeping a log of the changes I've made in a
A lot of these obviously aren't errors as such ("additions" means adding
new features). "type-check" refers to adding code to do more explicit
run-time type checking (typically at object initialisation time).
Let's say there are about 150 real errors there. My estimate is that
only 5 of them would have been found by a type checker and not by
other compiler checks.
Some of the nastier ones would certainly NOT be found a by type checker.
'update-self' refers to a method like
"flexible collections">>removeAllFoundIn: aCollection
which should remove every element that is also found in aCollection.
The problem occurs when the receiver and the argument are the same
collection, which is type legal, but results in modifying a collection
that you are iterating over.
Of course, this doesn't mean that there aren't errors that a type
would find that I haven't noticed yet. But 2% of changes being ones
a type checker would have been the right tool to find is still a small
I've sometimes wondered why this result is so low.
I suspect that Smalltalk syntax is the answer.
As a simple example, let's take
java.util.Arrays.binarySearch(a, i, j, k)
(This really really ought to be a.binarySearch(k), a.binarySearch(i,
and if Java's type system weren't so thoroughly messed up, it would
It's a pretty fair bet that in the two-argument versions the array comes
first and the key you are looking for comes second. The Smalltalk
a binarySearchFor: k
and you would be in no doubt.
The most consistent interface for the four argument version would have
corresponding arguments in corresponding positions, so the second
would still be the key. It isn't. As long as the key you are looking
is not some kind of integer, type checking will save you. But in
Smalltalk you would have
a from: i to: j binarySearchFor: k
and you would not be in the slightest doubt which argument was which.
Out of 24 possible argument orders, Java type checking eliminates all
2 if the key isn't an integer, or 6 if it is, but it still won't help
remember the order of the range arguments, or whether the upper bound is
inclusive or exclusive.
Since "to" is always used for inclusive bounds in Smalltalk, the
method name leaves you in no doubt about any of the arguments.
Now let's look at Erlang.
digraph:add_edge(G, V1, V2, Label)
would be very hard to get wrong if it were
add_edge_to(G) from(V1) to(V2) labelled(Label)
or perhaps even
extend(G) with_edge_from(V1) to(V2) labelled(Label)
I first heard of "split procedure names" back in, oh, 1976,
from a fellow student at Auckland University called Paul Lyons
who had, I believe, invented it for himself. It was certainly
well before Smalltalk 80 came out. He might possibly have been
influenced by PL/I.
It's now about 10 years since I proposed
<name>[(<args>)] ... <name>[(<args>)]
as Erlang syntax, with the idea that
(1) you sort the packets after the first stably by <name>
(2) you concatenate the <names> with "_" separators
(3) you concatenate the argument lists
so something like
extend(G) with_edge labelled(L) to(T) from(F)
extend(G) from(F) labelled(L) to(T) with_edge
extend_from_labelled_to_with_edge(G, F, L, T)
case get_path(G,V1,V2) of
false -> true;
del_path(G, V1, V2)
contract(G) removing paths from(V1) to(V2) ->
case find path in(G) from(V1) to(V2)
of false -> true
; Path -> contract(G) removing edges([V1|Path]),
contract(G) removing paths from(V1) to(V2)
Wordy? Yes. Much chance of a type error? Not much.
Much chance of swapping two arguments of the *same* type? Not much.
This is, to my mind, a syntactically simpler approach than keyword
arguments. It is completely decoupled from the names of the function
parameters, which is particularly important for Erlang because Erlang
function arguments as such don't *have* names. But it serves the same
ends as keyword arguments, and leaves little work for a type checker.
> erlang-questions mailing list
Te Reo Engarihi is a taonga of Te Iwi Pakeha,
ergo we should keep it pure, sans mélange, ruat caelum.
More information about the erlang-questions