Re: compiler directives

["Krishnaswami, Neel" <address@hidden>]

Dorai Sitaram [mailto:ds26@gte.com] wrote:
> 
> I really don't have a problem with compiler directives
> being treated as lang constructs.  It is the other-way
> smudging, ie, all lang constructs are compiler
> directives (which was what was suggested here)
> that strikes me as requiring some more persuasion.  

Okay, let's say that our compiler is a function cc, and it
uses 

  parse :: text -> AST 
  compile :: AST -> object-code

so that

  cc :: text -> object-code
  let cc = fun(t) { compile(parse(t)) }

Then, to add some pragmas to the compiler, we change the interface
of parse() and compile like so:

  parse :: text -> (AST * pragmas)
  compile :: (AST * pragmas) -> object-code

and this lets us continue to define cc as 'fun(t) { compile(parse(t)) }'.
Now suppose some joker offers a pair of type definitions:

  type AST' = (AST * pragmas)
  type pragmas' = (AST * pragmas)

so that compile can have either type 

  compile :: AST' -> object-code
  compile :: pragmas' -> object-code

What's changed? I think that I slipped a joker in the deck with 
the second type for parse() that I offered, the one with the sig 
'parse :: text -> (AST * pragmas)'. 

A compiler directive in the sense of a command-line flag doesn't 
live with the source text, except when you define an inline pragma. 
Conversely, a procedure or class or type definition lives in the 
source text, except when it comes from a library in some other 
part of the system.

So my 'text' type wasn't really well-defined. I don't know how to
define it, either. (Maybe some monadically-minded Haskell programmer
does. :)

--
Neel Krishnaswami
neelk@cswcasa.com