[erlang-questions] Getting rid of the preprocessor

[Richard O'Keefe]

On 25/05/2012, at 7:12 PM, Vlad Dumitrescu wrote:
> My real question got buried in the discussion about my particular use
> case: previously when the preprocessor and its demise were discussed,
> one main reason for not being able to do anything about it at the
> moment was that first we need to do something about the records. But
> the preprocessor doesn't do anything to records, they are processed by
> the compiler. To quote you from a recent thread: "Abstract patterns
> and frames are all part of a long-time project to make the
> preprocessor unnecessary". Could you please enlighten me as to how the
> preprocessor is involved here?

If two modules need to use the same record,
the definition is put in a .hrl file
and each module -includes that file.
This inclusion is done by the preprocessor.

I just did a quick survey of the .hrl files in a directory
that (sigh) has two releases of Erlang/OTP in it.

          defines=Y defines=N |
records=Y       212       160 |       372
records=N       485        26 |       511
          ========= ========= | =========
Totals          697       186 |       883

(The .hrl files with neither a -record nor a -define
either -include other files, contain -compile directives,
or contain generated code including function definitions.)
> 
>> I presume it goes something like this:
>>        if it looks like a variable, display it as one;
>>        if it looks like a function call, display it as one;
>>        if the display is wrong, it's the programmer's fault
>>        for defining such a stupid macro.
> 
> The displaying of fancy colors in the editor is not the important
> issue. An IDE needs to know as much detail as possible about the code,
> to support navigation and refactorings, to be able to suggest
> meaningful completions and offer reasonable ways to fix any issues it
> finds. This isn't possible if one can't understand (=parse) the code
> properly.

I find myself working on code that isn't _finished_ yet most of the
time, for which there _are_ as yet no facts of the matter on which
an IDE could depend.  If memory serves me, the way Quintus handled
the Emacs interface was for Emacs to ask Prolog to do the parsing.

I for one do not expect "meaningful completions" for macros.

It's worth reflecting that refactoring IDEs started in Smalltalk,
where the syntax is simple, there is no compile time/run time
distinction, and above all, no preprocessor.

> The parser grammar is basically describing this nice language, except
> that any grammar construct or combination thereof may be represented
> by a macro call...

The difficulty is acknowledged.  As is the fact that you can't stop
people using a processor even if there is none in the language.  I
have Smalltalk code generated using m4(1) and awk(1).  The Smalltalk+m4
source code has to be edited *somehow*.

I think "Delenda est preprocessor" was started while I was at RMIT,
perhaps in 1997.  My copy has the date 20 July 1998 on it, which is
after it was sent to SERC.  A copy can be found at
http://www.cs.otago.ac.nz/staffpriv/ok/delenda.txt

It was an internal report to SERC never meant for external publication,
so it is _not_ beautifully formatted.