Various (and almost completely unrelated) questions and opinions

[Chris Pressey]

David Gould wrote:
> On Mon, Feb 12, 2001 at 12:58:58AM -0600, Chris Pressey wrote:
> > [...]  Partly what I'd like to see is a sort
> > of "Dangerous Erlang" which trades off some of the safety and
> > predictability for flexibility and expressivity.  [...]
> Hmmm, I am thinking, "typeless Haskell" ;-)

Well, not entirely typeless - for that I think you have to go back to
the lambda calculus itself or "alternative" languages like Unlambda,
where there is only one "type", the function.  Erlang has a type system,
it is just not strongly typed (but there are seperate static analysis
tools to do that, too.)

Also I like Erlang's eager evaluation much better than Haskell's lazy
evaluation.  It is easy enough to build a lazy evaluator in Erlang if
you need one.

I've heard it said that "the number of Haskell programmers worldwide
could fit in my bathroom" - Erlang's takeup may not be explosively
large, but I think more people are actually *using* it for something,
than Haskell.

IMO Haskell == sophisticated, Perl == expedient, Erlang == one of the
best blends of sophistication & expediency since... well, since C!

I've had some thoughts about overloading operators, btw.  I think it's
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.

As an example, I would like to write code like this, in some sort of
idealized Erlang-like language, simply for readability and clarity:

  delivery_charge(Shipment) when Shipment.distance > 5km ->
    $5.00/km * (Shipment.distance - 5km);
  delivery_charge(Shipment) -> $2.00.

Obviously, I could write code which does exactly the same thing in
Erlang, but it would be relatively ugly and cumbersome.  Instead of the
">" operator, I'd have to use a measurement:greater_than() function,
which is a more awkward syntax, and can't be used in a guard either. 
The literal units of measurement would as well have to be expressed as
fairly awkward-looking function invokations like measurement:new(5.00,
[{'$',1},{km,-1}]). Overloading only solves one of these problems, the
rest remain and must be worked around by other means.

The result is that I think I will continue on the path of writing a
little language around the measurement data type, since Erlang alone
can't handle it very nicely.  The good news is that this little language
will be heavily influenced by Erlang and the compiler will probably be
written in Erlang and translate to Erlang - sort of a sublanguage for
modules which rely heavily on manipulation of values with units of
measurement.

_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