Various (and almost completely unrelated) questions and opinions
Wed Feb 21 22:29:10 CET 2001
David Gould wrote:
> Have you looked at Oberon?
Only briefly. I used to use Pascal a lot and Modula-2 some, but
eventually got kind of sick of Wirth languages.
> Anyway, the Oberon argument is that code should be understandable by
> reading it. That is, what is being done and the cost of doing it should
> be apparent by looking at it. The problem with overloading is that "A + B"
> could mean anything, eg "blend these two 80MB images", and it is not obvious
> from the immediate source what the heck is going on or what it might cost.
Well, yes. That's a valid argument for cost-conscious programming. Of
course, it also happens to be an argument against polymorphism,
inheritance, and any other feature that makes it hard to "judge the cost
by the syntax."
I mean, you can already say
add(X,Y) when number(X), number(Y) -> X + Y;
add(X,Y) when element(1, X) == image -> LiC(X,Y).
which means it's already possible to write Erlang code which is hard to
judge the cost of by looking at the application.
> > only of limited use unless you can have user-defined functions in
> > guards. This is assuming that the semantics of any overloaded operator
> > are expressed by a user-defined function, and that relational operators
> > can be overloaded.
> I like the rationale for the restrictions on guards, that they are
> restricted to known time or constant time operations without side
What is worse to me is the unorthogonality - that I can't say integer(X)
or tuple(X) outside of a guard and mean the same thing.
James Hague wrote:
> Overloaded operators don't make sense in a functional language, IMO.
> Actually, I'd argue that they don't make sense in C++. If you consider
> matrix multiplication, the old style C way was like this: matmul(result, a,
> b). The pain isn't from having to type "matmul" instead of "*", it's from
> having to keep track of temporary variables to hold intermediate results.
Well, actually, for me, the pain is having those parentheses - a nesting
level. I work with rather long numerical expressions. And to me it is
much easier to read
a * b * c * d * e * f * g.
matmul(a, matmul(b, matmul(c, matmul(d, matmul(e, matmul(f, g)))))).
"Gobs and gobs of nested brackets" is not one of elements of the LISP
heritage in Erlang that I particularly like! :-)
But this all points to the fact that what I am thinking of is in fact a
different language than Erlang, and I shan't complain about these
characteristics of Erlang in the future. No overloading, guards are a
form of type constraint, and so forth, for the sake of predictability
and ease of cost judgement.
"Ten short days ago all I could look forward to was a dead-end job as a
engineer. Now I have a promising future and make really big Zorkmids."
Chris Pressey, Cat's Eye Technologies, http://www.catseye.mb.ca/
Esoteric Topics Mailing List: http://www.catseye.mb.ca/list.html
More information about the erlang-questions