ideas for the IDE; 'obsolete pragmas'

Erik Zuurbier F.S.A.Zuurbier@inter.nl.net
Thu, 2 Apr 1998 20:43:23 +0200


Marco Pil wrote:

>I read your mail about 'obsolete pragmas' with great interest. It seems to
>provide
>a solution for a problem I was just dealing with (see below for a description).
>
>There were a few things I didn't understand:
> > *1 There is no substitute for the obsolete function in the new version:
> > This should be indicated explicitly for the obsolete function in the
> > combined module: a new function with the same name may not be a substitute.
> > The compiler can then generate a warning message, informing the programmer
> > that the function is going to disappear in the next version of the module.
> > This is better than what we now have: the message "function not defined".
>
>Why is "This function is going to disappear" a better message than  "function
>not defined"? If the function has become obsolete, any reference to this
>function
>must be gone, so no message "function not defined" will be generated.

Let me give an example. Say the Clean Team decides to overhaul the StdList
module and change

map :: (.a -> .b) ![.a] -> [.b]

into

map :: ![.a] (.a -> .b) -> [.b]

to make it more orthogonal, more in line with other functions or whatever
reasons. If you guys just do that, next time I recompile any of my existing
programs, I get all kinds of error messages. Worse still if Nijmegen
decides that map is not necessary anymore, yes I *will* get loads of
messages like "function not defined" on existing programs when I recompile.
So my proposal would be to include the following in the combined module:
(assuming /' and '/ as the pragma brackets)

map /'obsolete'/ :: (.a -> .b) ![.a] -> [.b]
 (etc)
map :: ![.a] (.a -> .b) -> [.b]
 (etc)
>
>And what about this source-to-source transformation? If the old version of
>the function
>has been conserved, can this not simply be used whenever it is needed ?!

Sure, but the goal of upgrading to Nijmegen's new version of the StdList
module is to get rid of any calls to the old version. So in the above
example, we could include the following transformation:

... /'transformation: map => (\fun list -> map list fun)'/

So any occurrence of map in my existing program would be replaced by
(\fun list -> map list fun).
With that, my existing program will compile with the new version of
StdList, and also with yet the next version which would only include
the new version of map.

The upgraded version of my existing program may not be particularly
beautiful after this transformation, but at least it works and uses
the modern map function. Next time I dive into the existing program,
I may also do some cosmetics. But if anybody knows about more
exciting types of source to source transformation, to include the cosmetics,
I might just applaud at them.

Hope this helps.
Erik Zuurbier