#ifdef considered harmful

[Alastair Reid]

> Will such a preprocessor work on source code like cpp does or on a syntax
> tree?  The latter would be better, IMO; the former would probably have
> little or no advantage over cpp.

A bunch of people have answered this already but your comment reminded me of 
one of the cpp problems we might want to avoid (by omitting a large chunk of 
cpp functionality).  One of cpp's flaws is that it has absolutely no notion 
of scope so if you define a macro 'bar' then code like this can do surprising 
things.

  foo bar = baz


What do people use macros for?

1) Aliases and abstraction:

Macros are useful in C because C is quite poor at defining aliases for 
existing things.  (e.g., typedefs can't be parameterized, you can't define an 
alias for a variable, creating an alias for a function is expensive unless 
you (can) mark it inline).

Haskell has great ways of creating aliases for things: type synonyms and 
function definitions.  There's no strong need for more.  (A few exceptions 
listed at the end of this mail.)

2) Defining symbols to be used in #ifs

This is useful for conditional compilation in both C and Haskell.

So, I'd like to float the idea that the Haskell preprocessor should _only_ 
support conditional compilation, that macro expansion should only occur in 
lines that begin with '#' not in "normal" lines and that macros should always 
evaluate to expressions with simple scalar types (ints, strings, etc.) 

Similarly, I'd like to drop token splicing (e.g., foo##bar in ANSI C or 
foo/**/bar in K&R C).  It's mostly useful for overcoming limitations in C and 
isn't much used to help you write #ifs.

These two changes make it possible to replace the usual horrible mix 
 of macro expansion, parsing and evaluation with a conventional interpreter.
#defines assign values to variables and 
#if evaluates expressions involving those 'variables'.

I'm not sure if it would still be useful to be able to define parameterized 
macros like 

  #define max(x,y) ...

but I doubt it would cost much to allow it.

Advantages:
1) hspp implementation is a lot simpler.

   [It's probably simple enough that the preprocessor could
   easily be built into Hugs if we wanted.  This isn't the primary
   motivation for this suggestion but it would be nice.]

2) hspp semantics easier to understand so programmers not caught
   out by name capture and all the other problems that cpp can
   cause.

3) hspp only affects lines that start with # in the first column.
   This further lessens chance of programmer being caught out.

4) No need to add extra parentheses round every use of a macro argument
   and round macro bodies as in:

     #define max(x,y) ((x)>(y)?(x):(y))


There's only one place I know of where this restriction would have any 
significant effect.  The FFI libraries have a lot of very similar definitions 
for all the new FFI types to define the Storable instances.  IIRC, a cpp 
macro is used to significantly reduce the amount of code that has to be 
written and to make it easier to read/maintain.  It would be a shame to lose 
this use of cpp but, if this is the only loss, I think it would be worth it.

--
Alastair Reid             www.reid-consulting-uk.ltd.uk

ps Inessential syntax tweak: If we are willing to change cpp syntax instead of 
just restricting it, we might require "=" between the lhs and rhs of a macro 
definition.  This makes parsing of macros a little easier.  cpp macros are a 
bit funny in that you get very different results if you write a space between 
the macro name and the arguments.  For example:

  #define max(x,y) x>y?x:y
and
  #define max (x,y) x>y?x:y

The first is a parameterized macro, the other isn't.  With this change, the 
following would be equivalent.

  #define max(x,y) = x>y?x:y
and
  #define max (x,y) = x>y?x:y