[IDE features]

[Richard A. O'Keefe]

	No, not different interfaces altogether. But imagine the following.
	I have a Clean program open and I decide to rename the
	function chFL to ChangeFormatLayout. Currently I select
	the old name and overtype the new name.

EH?  Why in the name of sanity would you do that instead of a
multi-file global-search-and-replace?  On a Macintosh, for example,
the Alpha editor makes that quite easy.  I do all my serious Clean
editing in programmer's editors like Alpha and Emacs.

	In addition to that
	I would also like to have a button or a menu item that opens
	a rename dialog. Then, after typing the new name and hitting the
	OK-button, the IDE would rename the function itself and
	also all references to the function where it is in scope.

If you want it to fix references in *comments* as well, then the
multi-file interactive-search-and-replace that a programmer's editor
provides is good enough.  If you _don't_ want it to fix references
in comments, then the comments aren't going to stay useful for long.

	(Of course that could fail because of a name clash. I would
	expect the IDE then to revert to the old situation and to
	report the name clash, or ask me questions to solve the clash).
	
	This is one example of an extra feature, not an entirely different
	interface.

No, this is NOT an extra feature for tidying up, it is a feature you
want ALL the time, even while developing new code or correcting errors
in old code.  It is in fact precisely the Interlisp "EDIT WHERE ANY
CALLS <x>" operation, and the UNIX 'cscope' utility provides just such
an interface without even being an editor (it repeatedly invokes the
editor of your choice at the right place).

If the Clean compiler could be asked to dump out a full cross reference
in text form, then other people could easily build Emacs or Alpha
functions to do useful things for you.  While it's nice that the Clean
system on a Mac has an IDE, the best thing it could do for me would be
to let me plug Alpha in instead.  In other words I'd rather have an
integratING environment than an integratED one (:-).
	
	I agree that you cannot change code that does not exist yet, but
	we already have something running to change code three
	continents away.  In our company, everybody has an electronic
	agenda (or is 'scheduler' the right word?), and an e-mail
	client, both provided by a Big Software Company.

Er, that is NOT changing *CODE*.  "Agenda" literally means "(list of)
things to be done".  It's data.  What you have is no more and no less
than a DISTRIBUTED DATA BASE.  We have something like that done quickly
in Java by a student.  When the Clean TCP stuff is released, you'll be
amazed how easy it is to do something like that in Clean as well.
The crucial things that make a distributed data base like that work
is that the remote clients have given CONSENT to their (copies of)
data being changed by other people and that they REMAIN CONNECTED.

If you want your revisions to interfaces not to introduce incompatibilities
with my code, our machines have to be connected, and I must consent to you
changing my code, sight unseen.  Our local news system has been down for
over a week, and ITS here aren't treating its restoration as a priority.
Think what that does to your distributed code base.  As for consent to
change my code, don't hold your breath.

	Now I understand that there may be loads of practical problems,
	but those could be solved.

No, they can't be solved, they can only be *approximately* solved.
Just as the kind of updates you've described *can't* be solved (in
Interlisp, for example, (SET (CONCAT 'FOO 'BAR) 1) has the same
effect as (SETQ FOOBAR 1) but you can't expect Masterscope to find
the hidden reference to FOOBAR in the first version.  Masterscope
is only *approximately* correct.  The same with cscope:  it can be
fooled too, and in particular it misses references in comments,
which really _ought_ to be updated too.  Worse still, it's useless
with code that is generated by another tool.  I'm currently writing
a paper on some sorting algorithms; I have about 25000 lines of C
code generated from 1360 lines of macros and cscope is pretty much
useless for managing it.

Again, a thing I have against IDEs is that they fail to take seriously
the idea that SOURCE CODE IS DATA.  IDEs are great when you are only
dealing with source code that has been generated by hand.  When any
non-trivial amount of your code is generated by other programs (like
the extremely crude scripts I used to convert (subset) Haskell to
Clean, they didn't work on much but they did work on the examples in
my class) an IDE is a pain in that region of interest to proctologists.
One thing I like about SMLNJ is that those people take the idea of
_generating_ ML source code seriously.
	
	But first let's have an IDE that helps us manage the software
	on one computer.

Is it going to do version control and configuration management too?
That's really a much more important question than whether it supports
any particular kind of edit or not.  If I have mixed C and Clean code
(as a student here did), is the Clean IDE going to help me with the C
code too?  What if I make a change in the C code and the clean interface
needs a compatible change?

Given a full cross-reference from Clean, we can build our own smart
editing stuff.  _Please_ let's not waste the Clean team's time on IDE
stuff when far better editors already exist.
.\