ideas for the IDE; 'obsolete pragmas'

[rinus plasmeijer]

>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 =3D> (\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.


We have the following proposal: when a new version of a module is created we=
 compare the types. If all types remain the same, a stored dynamic can refer=
 to this new module instead of the old one. Otherwise the stored dynamic=
 will remain to point to the old module containing the original definition.
Old modules cannot be trown away if stored dynamics still refer to it.

Greetings,

Rinus.