Various (and almost completely unrelated) questions and opinions

[Chris Pressey]

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
> effects.

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.

than

  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.

_chris

-- 
"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