[IDE features]

[Richard A. O'Keefe]

I intend this to be my last message on this topic, because I think
I'm running out of useful things to say.

Erik Zuurbier wrote

	I have the impression that you have mistaken my initial posting
	where I spoke about the alteration between code development
	and tidying up.

So it would appear.  I'm sorry about that.

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

Yes, I claim that
    ALL (SOURCE CODE) IS (DATA).
I do *not* claim
xx  ALL (DATA) IS (SOURCE CODE).
There are two things about source code that distinguish it from
other data:
(a) The ability to specify potentially unbounded computations from
    a finite amount of data.  (Before anyone asks:  yes, by this
    criterion genomes _are_ source code.)
(b) Long-distance dependencies mediated by names.

I don't know what your appoinments scheduler is exactly, but
I am surmising that
 - the data base SCHEMA is fixed, so the _semantics_ of the data
   cannot be altered by someone entering a new appointment
 - "facts" in the data base are not allowed to contain logical variables
   (except possibly for "null" values of some kind)
 - facts are pretty much independent.

I will accept that distributed maintenance of a database *SCHEMA* is
like distributed maintenance of source code.

	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.

I suspect that that is because you have not understood the distinction.
Perhaps, although I rather doubt it, you have a distriubuted logical
data base where anyone can add new IDB rules at any time.  I imagined
that only changes to the EDB were allowed.

There is a _vast_ difference, at the very least of degree, between a
system where you are changing constants and the identity of any
constant is not in doubt, and a system where questions of identity are
in principle undecidable.  Mind you, deciding identity in data bases
is not easy either, as Kent's "Data and Reality" explains clearly.
This is why many data base designers are careful to distinguish between
(a reference to) what a thing _is_ (an internally generated ID) and
what a thing is _called_ (an externally supplied name).

	>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.
	
	Wait a minute.  First you call it no more and no less than a
	distributed data base.

Here "IT" = "your appointment scheduler".  *NOT* the source code
maintenance problem; your appointment scheduler.

	Then you list a few crucial things about those.

Right.

	Then you illustrate that you and I are never going to
	work together in a way that satisfies those crucial things.

On *source code*.

	So maybe it is not a distributed data base after all?
	
But now you have changed "it" from "your appointment scheduler" to
"source code maintenance".  Indeed, my argument *did* show that
"source code maintenance" is NOT as easy as a simple distributed
data base like your appointment scheduler.

	>	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.
	
No, it is NOT "a matter of words".  It is a matter of FACTS.  When I
say that these problems cannot be solved, I mean that there are real
examples where approximate solutions *WILL* give wrong answers.  If you
are "happy with half a solution", that means you are happy with tools
that will fail half the time, and you won't know WHICH half.

Let me give you an example.  A certain UNIX vendor provides a graphical
browser for C.  It can show you a call graph of which functions call
what.  The one time I needed this tool, the output was *useless*, because
	p = f;
	...
	(*p)(x, y, z);
was not tracked, and the tool firmly believed that the function f was
never called anywhere.  This was "half a solution" which presumably
many of the vendor's customers were "happy" with, yet on at least one
example it was dangerously wrong.

	But if there are any, I would be happy with half a solution that
	only covers the compile time references.
	
Consider just

	f x y = g (h x) (h y)

	...  (f 12) ...

Now let's change that to

	f y x = g (h x) (h y)

	... (f 12) ...

Yes, the Clean IDE should be able to recognise a reference to f here.
What to do you want it to change f _to_?
We've already agreed that it's necessary to distinguish
"fix body of f", where (f 12) should stay as it is, and
"change interface of f", where (f 12) should become (\ y -> f y 12).

Now let's make it just a little bit more complicated.

	map f [] = []
	map f [x:xs] = [f x:map f xs]

	f x y = x - y
	g x y = x / y

	h fs x y = map (\f -> f x y) fs

	... h [f g] ...

Where, exactly, is the reference to f?  If we are changing the
interface of f, should we change the interfaces of g and h as
well, and do we do these changes concurrently, and if not, what
are we to do with the intermediate states, which might not be
legal Clean code (and so might not be analysable)?

	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.

No, my vision is sharped by having done lots of edits,
and my appreciation of the fact that many program properties of
interest are literally uncomputable.
I'm aware of some of the work that has been done on theorem proving
and program proving environments, and that seems like a better place
to look that existing IDEs, but it's amazing just how much work it
can be to deal with quite a tiny program.

As I see it, the *real* benefit from languages like Clean is not that
they may in some future Golden Age permit the construction of smart
editors, but that they let us write shorter clearer programs in the
first place so that we don't *need* smart editors so much.

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

I find this a rather baffling claim.  How do smart edits stop requirements
changing?  How do they stop underlying system interfaces changing?  How do
they stop people asking the smart editor to make the wrong change?
	
My single biggest problem with Clean is that it assumes tab stops are
every 4 columns, which is true in NONE of the environments I use, so that
I have to be extra careful to tell my editor "eliminate TAB characters".
If Clean could handle comments like //TAB=8 at the front of a file, that
would be pretty smart by me.