[IDE features]

[Zuurbier, E. - AMSXE]

Richard O'Keefe wrote:

>	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.

Yes why not. That is not my point. Occasionaly I do the above.
By the way, my call for extra features on the IDE is based on my
experience with the current Clean Mac IDE. I have no experience with
other programming languages nor other IDE's or programmer's editors.

>	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.

Good enough for you, but not for me, because of the scope thing.
But you have a point about the comments. Bringing comments under
control of the IDE would be an interesting endeavour. I am already
working on that for Clean.

>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.

I have the impression that you have mistaken my initial posting
where I spoke about the alteration between code development
and tidying up. It is not like I do development on Mondays,
Wednesdays and Fridays and tidying up the rest of the week.
So: yes, it IS a feature for tidying up and I want it all the time,
because one minute I develop new code or correct an error,
the next minute I tidy up and maybe expose another error
by doing so.

>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).

Fine, I had not imagined I was posting a briliant new idea that noone
had ever thought of before. If Interlisp has something like it,
lets build on it! But I was just giving an example of a feature.
The IDE could be a lot more aware of what it was editing.

>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 support that. This is about the way to get TO an IDE that is aware of
the program structure (and above that, aware of the project structures),
not about the end result of that. I could imagine that the Nijmegen boys are
better compiler writers than IDE-builders.
> 	
>	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.

I was amazed about this distinction, which at this point seems so irrelevant
to me. Even more so as a few lines furtheron you write:
"Again, a thing I have against IDEs is that they fail to take seriously
> the idea that SOURCE CODE IS DATA." 
> 
I was giving an analogy with schedulers, just to illustrate that it may not
be as impossible as you suggest. Yes, there are differences between
agendas and bodies of Clean source code, but your distinction above
to me is not a difference that breaks down the analogy.

>When the Clean TCP stuff is released, you'll be
>amazed how easy it is to do something like that in Clean as well.

I can imagine that.

> What you have is no more and no less than a DISTRIBUTED DATA BASE.
[snip]
>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.

Wait a minute. First you call it no more and no less than a distributed data
base.
Then you list a few crucial things about those. Then you illustrate that you
and I
are never going to work together in a way that satisfies those crucial
things.
So maybe it is not a distributed data base after all?

>	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.

That is a matter of words. If I am happy with half a solution, it is a whole
solution to me.

>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.

I don't know Interlisp and I don't know Masterscope. My reasoning would be
that if the Clean compiler is able to sort out references and scopes, the
IDE could be given that same capability. If I may speculate about your
Interlisp example above, I have the idea that these could be references that
Interlisp
would resolve at runtime, not at compile time. Clean does not have many of
those.
But if there are any, I would be happy with half a solution that only covers
the
compile time references.

>I have about 25000 lines of C
>code generated from 1360 lines of macros and cscope is pretty much
>useless for managing it.
[snip]
>Again, a thing I have against IDEs is that they fail to take seriously
>the idea that SOURCE CODE IS DATA.

I have the impression that your vision on future IDE's for a pure functional
language such as Clean is blurred by bad experiences with existing IDE's
for quick and dirty languages such as C.

>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.

The difference between the two may fade one time, when the edits get
smarter.

Regards Erik Zuurbier