random thoughts on language design etc.

[Chris Pressey]

n Fri, 22 Nov 2002 09:29:55 -0600
James Hague <jamesh@REDACTED> wrote:

> >I think it would be great to loosen the
> >restrictions a bit and be able to
> >use arbitrary boolean functions in guards.
> 
> I think this changes the language in such a dramatic way that there's
> not much point in discussing it :)

>From an implementation standpoint, it could be a pain, granted.

But I think it has a minimal impact on the *language* - the resulting
language would be a proper superset of Erlang, since guards are
semantically equivalent to boolean functions.

Consider:

  case module:something(Whatever) of
    {A, B} when ets:lookup(mytable, B) == [{B, something}] ->
      50;
    {C, D, E} when funky:test1(E) > funky:test2(D) ->
      100;
    _ ->
      0
  end.

Is the equivalent of:

  case module:something(Whatever) of
    {A, B} ->
      case ets:lookup(mytable, B) == [{B, something}] of
        true ->
          50;
        false ->
          0
      end;
    {C, D, E} ->
      case funky:test1(E) > funky:test2(D) of
        true ->
          100;
        false ->
          0
      end;
    _ ->
      0
  end

Admittedly, a rather hairy parse transform, but I dare suggest it's within
the bounds of doable.  The benefits would be great from a readability /
maintenance standpoint IMHO, which (also IMHO) is probably the single most
important metric for judging what makes code, *good* code - assuming you
don't have critical performance limits to adhere to via hand optimization.

One might make the argument that Erlang is a language exclusively for soft
real-time applications, and thus should shun all improvements except those
that directly correspond to performance and expediency, but the fact that
the compiler (hardly a real-time application) is written in Erlang would
seem to be a precedent that contradicts that notion :)

> My feeling is that all other Erlang changes should be put on hold until
> something is done to improve records.  Wow, is it ugly to have use
> -include directives, especially without any guarantees that different
> modules are compiled with the same record definitions.  It's like C
> externs all over again.  I know abstract syntax patterns didn't work
> out, but surely there's_something_ that would make a good alternative? 
> I remember seeing mention of a simple, dynamic record system for Erlang
> somewhere, but I haven't been able to locate it.

I can't think of anything simpler or more dynamic than the 'dict' module.

Include files can be avoided if record definitions are internal to a
module which provides accessor functions - although that may be too
OO-flavoured for many Erlangers.

Using -include_lib and recompiling copiously should be a pretty good
guarantee that all modules are using the same record definitions.

But yes, records are ugly ugly ugly, and part of that stems from Erlang's
rather cavalier attitude towards data types, which can be both good and
bad.  One of the worse effects is that no type can really be opaque - it
will be generally be implemented as a tuple or a list, and case clauses
can catch either of those accidentally (especially a list.)  Witness, for
example, the disclaimers placed on the parse tree compatible data type in
the syntaxtools contrib.  That appears to be the best that can be done
until there is some sort of way to define truly distinct types in Erlang.

-Chris