Erlang language issues

[Richard Carlsson]

On Tue, 16 Apr 2002, Thomas Lindgren wrote:

> [new and old type tests]
> >The old type tests must of course remain for backwards
> >compatibility, but they are now being renamed to the "is_" forms
> >very early in the compilation.
> 
> I think my basic question is whether one can rename guard tests
> into the new operations directly. This way, one could get rid
> of having both type(X) and is_type(X). It would seem to be possible
> for most cases, perhaps excepting the dual mode of float(X) that
> you mention, or any similar cases.
> 
> (Though looking at the context, it should be possible to deduce
> what version is intended: off the top of my head, on the toplevel
> one uses is_float(X), inside arithmetic one uses to_float(X) or
> whatever the operation may be called. Any questionable cases are
> flagged with a warning.)

You *can* do this, even today! (Shameless self-promotion follows.)

If you get my syntax_tools package (1.2) from erlang.org, there is a
module 'erl_tidy' (full documentation in doc/erl_tidy.html), which does
this and lots more to "modernise" old code - all nicely pretty-printed
with comments and preprocessor stuff preserved. A number of options are
available to control what things are changed.

If you just want to use it as a "lint"-thing, you can give it a flag
"test", and you'll get the reports without changing files.

It automatically updates known obsolete function calls to the new
functions, where possible (i.e., where arity and argument order are the
same). You can supply a list of additional functions to be redirected.

It can remove unused functions from the code, and expand function
imports so that all remote calls become explicit, plus some other nifty
transformations.

The 'dir' function works recursively through a directory tree.
If files are being created, backups of the original files are made.

I can't guarantee that it's totally bug free, but I have run it on the
*whole* Erlang/OTP distribution - every single .erl file in it - and
recompiled, and everything seems to work.

In a few cases, it's just too hard for it to read a particular file (if
weird macros are used), and then it just skips that file.

Go ahead and try it. If you come up with more things it should be able
to update, please tell me.


> > /.../ the reason for the extension is to make guards more like
> > other expressions. A complication is that failure in the first
> > argument of a top-level guard 'or' (semicolon) goes on to try the
> > other alternative as if there were two clauses, while at the
> > expression-level the whole 'or'-operation fails immediately.
> 
> I think making guards behave like expressions is a Good Thing,
> generally speaking, because it is more convenient to have full
> boolean expressions. As you say, the problem is nailing down the details.
> 
> I suppose the behaviours above should be unified. If nothing else, for
> the sanity of programmers :-)

Not to mention the sanity of compiler writers :-]

But this seems to be another of those things that just can't be changed.
Syntactically, we can and do allow and/or for ,/; - but the semantic
difference in guards between "top-level" conjunction and
"expression-level" conjunction will have to remain, I'm afraid. It's a
fairly subtle thing, and I don't think it will cause any real trouble.


> [deep guards]
> I'm a bit ambivalent about permitting "deep guards", however.
> 
> What do we define as a side-effect, for instance? _Reading_ the
> database? Permitting long-running guards means we must be able to
> context-switch inside the guard, which means the database can change
> while we run the guard, which might be construed as an impurity.
> (And what about read locks?) And so on.
> 
> I believe the original restriction on guards comes from concurrent
> logic programming, where "deep guards" had severe problems and
> ultimately led to disallowing them.

Thanks - that saved me from trying to explain this point. I also believe
that although we might be able to extend guards in Erlang somewhat, and
remove some strange syntactic limitations, we will probably never have
"deep guards" - they come with deep problems, especially with things
like context switching. (And a special syntax for declaring guard
functions does not fix this.)

	/Richard

Richard Carlsson (richardc@REDACTED)   (This space intentionally left blank.)
E-mail: Richard.Carlsson@REDACTED	WWW: http://www.csd.uu.se/~richardc/
 "Having users is like optimization: the wise course is to delay it."
   -- Paul Graham