Various (and almost completely unrelated) questions and opinions

[Chris Pressey]

David Gould wrote:
> On Wed, Feb 21, 2001 at 03:29:10PM -0600, Chris Pressey wrote:
> > [...] it's already possible to write Erlang code which is hard to
> > judge the cost of by looking at the application.
> Sure, but by that standard, any function call is obscure at the limit.

OK.  I suppose my point is that this sort of feature can always be
abused.  If you disallow it by not offering the feature, you stop it
from being abused, but you also prevent the possible good uses of it.

I don't think it's really worth the tradeoff, in Erlang.

> > 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.
> Ok, I think I agree. If it looks like a function, it should be a function.

(Speaking of conformity, almost every other language I've ever seen uses
">=" for "greater than or equal to".  Not Erlang... :-)

> Please do not fall out of love so fast... and I certainly do not speak for
> the Erlang designers, so maybe overloading is coming soon.

Well, I originally thought about overloading because I thought that
maybe with it, I could use Erlang to solve some problems it wasn't
originally designed for, by having it work on a customized primitive
data type.  But that just isn't the case.

And on general principles, I'm no fan of overloading either, because it
does rely on a lot of far-reaching context.  So I am inclined to agree
with the application of an Oberon-like philosophy to overloading in
Erlang.  Keep it predictable; disallow operator overloading.

Polymorphism (such as it is with this LISP-like type system) is probably
a better idea than overloading for a functional language.  The "=="
operator is a good example of good built-in polymorphism.

My desired language differs from Erlang in several ways.  It's more of a
number-crunching language where cost-consciousness isn't a priority but
clarity is.  What I'm going to do instead of using Erlang (and should
have thought about doing from the start) is to *steal* the best ideas
from Erlang for my own use.  :-)

I'll still write the compiler in Erlang though, and probably have it
compile to Erlang as well.  It's probably a little too much to do with a
parse transformation - and I might want to have destination formats
other than Erlang someday - all the more reason for it to be it's own
language.

_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