Re: MISC-d Digest V97 #40

[Todd <Todd@xxxxxxxxx>]

>> Questions that I would like to see answered. What are the most common

>> types of errors that he has when coding forth. If the editor were
more
>> sophisticated could some of those errors be caught. Does he feel that

>> context sensitive editors might be usefull.

>I think that this question is beaten to death.  If the editor could do
the
>programming, why pay programmers to program?

my current editor does do a considerable amount of the programming that
I used to have to do by hand. It performs extensive error checking,
builds data graphs and color marks keywords so that I know if something
is spelled right. It could be extended to give outline capibilities to
the code, better support comments. A forth compiler could have the
ability to show and map the stack to some selected snippit of code so
that the programmer could step though the code without running the
program. Would it be useful to be able to mark the code that pushes the
values on the stack that are subsequently used by a word.

>>  How about the possibility of
>> using a compression scheme to find common subexpression sequences in
the
>> code.

>This has also been beaten to death.  The answer is "Yes, somebody did
it,
>and it found terribly meaningless patterns."  One should factor out not

>based on code sequence, but based on conceptualization, modularity,
data
>hiding and maintainability.  These are concept very difficult to embed
in
>some formal graph parsing algorithm.

There is a considerable amount of dialog in the Forth community about
how compact Forth programs are and the advantages it has. If a
compressor could find common subexpressions and exloit them as an
optimization then the programmer would not have to visualize thier
exsitence. My compiler already does things like strength reduction,
constant folding, and loop unrolling. If for some chip function calls
had no cost then meaningless patterns would have value. The compiler
does not have to concern itself with onceptualization, modularity, data
hiding and maintainability. These concepts operate at a higher
abstraction.

>> Would he trust this to be fully automatic or more like a spell
>> checker that reports possible changes.

>With the current idea of putting a small number of tightly threaded
code
>snippets on-chip, obviously "optimal" layout and threading is an
>interesting question.  But the object of optimization is a few code
>endings rather that a multi-programmer project.