[erlang-questions] The Erlang Rationale

[Richard O'Keefe]

On 2 Oct 2008, at 8:23 pm, Benjamin Tolputt wrote:

> Richard O'Keefe wrote:
>> <snip>Nice logging example</snip>
>
> The problem I see with your solution(s) is that they are only better  
> if
> the Erlang were different (i.e. top level variables and ?HERE).

Wrong, as I realised after posting it.
In fact, >>>>in that very posting<<<< I showed how top
level variables are >>>not<<< in fact needed.

Let me offer the skeleton again,
slightly generalised.

	-compile({inline, [{compile_time_debug_level,0},
			   {log_error,3}, {log_warning,3}]}).

	compile_time_debug_level() -> errors.

	log_error(L, F, A) ->
	    logger:log(error, ?MODULE, L, F, A).

	log_warning(L, F, A) ->
	    case compile_time_debug_level()
               of warnings -> logger:log(warning, ?MODULE, L, F, A)
	       ; errors   -> ok
	    end.

called as

	... log_error(?LINE, "...", [...]) ...
	... log_warning(?LINE, "...", [...]) ...

where ?LINE is sufficient because after -include
processing, the local log functions are in the same module
as the caller, so ?MODULE doesn't need to be passed.

	
> This, to
> me, is just a game of "what if" (unless you re actually putting them
> into Erlang - in which case, I humbly apologise). "What if" scenarios
> are great and all, but don't actually a valid argument make.

You have completely mistaken the form of my argument at the point.
My argument had the implicit form (which I thought to be so very
obvious given good will as to not need spelling out)

	GRANTED for the sake of argument that logging of this form
	is something not currently well served,
	WHAT WOULD WE NEED TO DO in order to remove any need to
	use the preprocessor for this purpose.

I first considered a run-time method of discovering the caller's
location and dismissed it.

I then mentioned top-level variables BUT SHOWED HOW WE DON'T NEED THEM.
(Although it would be nice if the Dialyzer were more tolernate of the
resulting code.)

I then mentioned ?HERE as a possible idea that would leave the
source code with a visible mention of "at this point I pass my
source location" -- hence would be more tokens to type than
using a macro -- but in a much shorter and potentially richer
form than ?MODULE, ?LINE.

Given my history of writing EEPS, readers were expected to see this
as a pre-pre-EEP for ?HERE.  Today I've mailed out patches to add a
prototype version of ?HERE that gives you {?MODULE,?LINE,undefined}
with undefined as a place-holder for a future {function,arity}.

However, on the way home last night, it became annoyingly obvious
that we don't actually need ?HERE at all.  If people are content
with ?MODULE and ?LINE, they can get that right now, passing
?LINE in the call and supplying ?MODULE in the (-included) callee.

Note that when I complain about what macros do to maintainability
-- including the ability of editors to indent properly --
I am *not* arguing against -include or even against ?MODULE and
?LINE or any other compiler-generated context-sensitive named
constants, which turn out to be more abundant than I had
remembered.

This is a textbook case of why "no, we have to deal with the language
as it is" is very bad thinking.  Erlang is open source.  We DON'T
have to stick with the language as it is.  We can all, any of us,
invent alternatives and write EEPS.  Having said "I need macros to
do X", it is not helpful to just rest there.  One should say "Have
I really identified a need for macros or is there another way to do
it?  If I have really identified a need, what changes to the language
or system would eliminate that need?"

Come to think of it, my first (rejected) idea, of picking up the
location at run time, might *long term* be the very best idea of
all.  (Or, on the other hand, it might still be as stunningly bad
as I first thought it.  I was inspired by the nargs() function
that was available in some versions of C.)  One of the issues that
keeps coming up each year is someone wanting better location
information in errors messages and tracebacks, and digging that out
at run time seems to be the only practical way to do it.  That
being done, we wouldn't need ?MODULE, ?FILE, ?LINE, or any of those
things; we could pick them up at run time.  (Anyone else out there
remember the B6700?  1960s design mainframe and operating system,
but run-time errors *routinely* gave you line numbers in tracebacks.)