To think or not to think ;-) 
Author Message
 To think or not to think ;-)

 A very important point occured to me about factoring.
You don't necessarily have to think in order to 'factor out' something.

Eg.:

: WordX A B C D E F G H ;

: WordY L M B C D E F O P ;

(The capital letters are FORTH words.)

You can 'factor out' something:

: WordAux ( ????? ) <-- This is the important point!!!!!

  B C D E F ;

And write:
: WordX A WordAux G H ;
: WordY L M WordAux O P ;

The point is, that if B C D E F are 'ordinary' FORTH words (they take their
parameters from the stack and leave the results there) and they are not
conrol structure elements you can do it 'by texteditor' without knowing or
caring what the stack effcts of the individual words or that of the resulting
word are. (That means it can be done automatically by a program!)
I think it is not very common in other languages (I don't dare to say it
is impossible) and one of the reasons why I prefer old 'purist' FORTH to
LOCALS| .

Andras



Sun, 04 May 1997 12:58:49 GMT  
 To think or not to think ;-)

Quote:
Andras) writes:
>The point is, that if B C D E F are 'ordinary' FORTH words (they take
their
>parameters from the stack and leave the results there) and they are not
>conrol structure elements you can do it 'by texteditor' without knowing
or
>caring what the stack effcts of the individual words or that of the
>resulting word are. (That means it can be done automatically by a

program!)

Where the thinking comes in is that you may know that if you group B C D E
they will form a logically coherant unit that you can give a nice name to
and use 47 times, whereas by adding F which only followed B C D E twice
you've severely inhibited its usefulness!



Wed, 07 May 1997 10:15:26 GMT  
 To think or not to think ;-)

Quote:
: Andras) writes:

:
: >The point is, that if B C D E F are 'ordinary' FORTH words (they take
: their
: >parameters from the stack and leave the results there) and they are not
: >conrol structure elements you can do it 'by texteditor' without knowing
: or
: >caring what the stack effcts of the individual words or that of the
: >resulting word are. (That means it can be done automatically by a
: program!)
:
: Where the thinking comes in is that you may know that if you group B C D E
: they will form a logically coherant unit that you can give a nice name to
: and use 47 times, whereas by adding F which only followed B C D E twice
: you've severely inhibited its usefulness!
:

 Yes that is the thinking part. (This is why FORTH is not used by idiots. ;-)
What I wanted to point out is that you CAN factor out 'units' without
knowing what is their inside structure or even their effect. In other
languages (say C) it is impossible.
The FORTH code visually cries out for 'doing something' with the repeated part.

Of course I don't want to suggest to anybody to do such things 'brainlessly'.

Andras



Thu, 08 May 1997 13:20:38 GMT  
 To think or not to think ;-)


writes:

Quote:

> A very important point occured to me about factoring.
[snip]
>you can do it 'by texteditor' without knowing or
>caring what the stack effcts of the individual words or that of the resulting
>word are. (That means it can be done automatically by a program!)

Wow, a de-optimising compiler with automatic out-lining of code. Brilliant!

Good factoring is one of the most subtle skills in Forth. Sure, editting
sections of words out is easy. The skill comes in choosing which bits to make
into new words. Ideally every part of an application should be reusable (ie
public rather than private), in practice one occasionally has to factor bits
out that are not terribly useful in themselves in order to make the code
readable and testable. These are good reasons for factoring. That a sequence
appears a couple of times in the source is not necessarily a good reason. The
test is; can you give this sequence of words a sensible name?

BCNU, Gordon

"All the words float in sequence,
 No-one knows what they mean,
 Everyone just ignores them"          Brian Eno -- Sky Saw



Thu, 08 May 1997 10:02:41 GMT  
 To think or not to think ;-)

Quote:
: Andras) writes:

:
: >The point is, that if B C D E F are 'ordinary' FORTH words (they take
: their
: >parameters from the stack and leave the results there) and they are not
: >conrol structure elements you can do it 'by texteditor' without knowing
: or
: >caring what the stack effcts of the individual words or that of the
: >resulting word are. (That means it can be done automatically by a
: program!)
:
: Where the thinking comes in is that you may know that if you group B C D E
: they will form a logically coherant unit that you can give a nice name to
: and use 47 times, whereas by adding F which only followed B C D E twice
: you've severely inhibited its usefulness!
:

Another thing occured to me about it.
If B C D E DOES NOT have any 'meaning' but occures 2000 times in a 50000 lines
long source code (written by five people) you most probably won't factor it
out. BUT if you use a program that 'brainlessly' parses the whole source
it might find the repeting pattern.
I mean you can exacly do the opposite of 'function inlining' automatically
but only in FORTH. (Usually only the reverse is considered to be useful but
imagine that you are running out of space!)

I do not know if in the 'real world' it would be useful but it seems to me
that you can do something in a *SIMPLE* way in FORTH what was not commonly
considered as a possible operation a preprocessor can do.

Andras



Fri, 09 May 1997 13:44:09 GMT  
 To think or not to think ;-)
:
: Wow, a de-optimising compiler with automatic out-lining of code. Brilliant!
:

 A nice name for it. ;-)))) I do not consider this one as the compiler's
job, but a preprocessor can do this 'out-lining'.
(Actually the programmer is always expected to write structured programs
while the compiler is expected to make in unstructured. I am just playing
with the idea to reverse the latter.)

: readable and testable. These are good reasons for factoring. That a sequence
: appears a couple of times in the source is not necessarily a good reason. The
: test is; can you give this sequence of words a sensible name?

As someone (maybe you?) pointed out, a good programmer names a word in the
base what it does (not how it is done). I think in a linguistical sence
the FORTH names are based on pragmatical (as opposed to semantical) background.
It you find out (with the help of an automatic out-liner ;-) that you have
certain operations a hundred times in your program you might be better to
consider a good term for that operation.

Andras



Sat, 10 May 1997 13:20:10 GMT  
 To think or not to think ;-)

Quote:
"Zsoter Andras" writes:
>Another thing occured to me about it.
>If B C D E DOES NOT have any 'meaning' but occures 2000 times in a 50000 lines
>long source code (written by five people) you most probably won't factor it
>out. BUT if you use a program that 'brainlessly' parses the whole source
>it might find the repeting pattern.
>I mean you can exacly do the opposite of 'function inlining' automatically
>but only in FORTH. (Usually only the reverse is considered to be useful but
>imagine that you are running out of space!)

>I do not know if in the 'real world' it would be useful but it seems to me
>that you can do something in a *SIMPLE* way in FORTH what was not commonly
>considered as a possible operation a preprocessor can do.

You are right, this is a 'distress' change, only worth doing in extreme
circumstances (I have had to do it in asm in most projects I've worked on
sadly).

It also pretty much misses the point! By and large functions|routines are
used to save typing (whatever anyone told you....) and encapsulate
functional blocks (simplifying the code). Performing a mechanical reduction
does not help with either.

--
Paul Shirley: Coffee Hunter Extreme



Sun, 11 May 1997 07:54:04 GMT  
 To think or not to think ;-)

Quote:
|> : Andras) writes:

|> :
|> : >The point is, that if B C D E F are 'ordinary' FORTH words (they take
|> : their
|> : >parameters from the stack and leave the results there) and they are not
|> : >conrol structure elements you can do it 'by texteditor' without knowing
|> : or
|> : >caring what the stack effcts of the individual words or that of the
|> : >resulting word are. (That means it can be done automatically by a
|> : program!)
|> :
|> : Where the thinking comes in is that you may know that if you group B C D E
|> : they will form a logically coherant unit that you can give a nice name to
|> : and use 47 times, whereas by adding F which only followed B C D E twice
|> : you've severely inhibited its usefulness!

No thinking necessary yet. Just introduce two factors, BCDE and
BCDEF. The thinking is necessary when you want to give the words more
intelligent names than BCDE.

|> Another thing occured to me about it.
|> If B C D E DOES NOT have any 'meaning' but occures 2000 times in a 50000 lines
|> long source code (written by five people) you most probably won't factor it
|> out.

If a four-word sequence occurs 2000 times, it *has* a meaning.

|> BUT if you use a program that 'brainlessly' parses the whole source
|> it might find the repeting pattern.
|> I mean you can exacly do the opposite of 'function inlining' automatically
|> but only in FORTH. (Usually only the reverse is considered to be useful but
|> imagine that you are running out of space!)

Not only in Forth. Combinators have the same property (combinators are
an intermediate representation used in functional languages). And
assembly language, too, usually. It's also possible in functional
languages and Prolog, although the transformation is a bit more
complicated.

BTW, why do you just look at sequences? You will miss many
opportunities that are obscured by different arrangements of useful
and stack manipulation operations. You can find more opportunities by
comparing the data flow graphs of sequences (for construction of data
flow graphs, see
ftp://server.complang.tuwien.ac.at/pub/papers/ertl92.ps.Z; also I
think Gordon Charlton has a paper in a recent Forth Dimensions). And
even more if you take algebraic properties into account.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed



Mon, 12 May 1997 02:41:26 GMT  
 To think or not to think ;-)

Quote:


> Andras) writes:

> >The point is, that if B C D E F are 'ordinary' FORTH words (they take
> their
> >parameters from the stack and leave the results there) and they are not
> >conrol structure elements you can do it 'by texteditor' without knowing
> or
> >caring what the stack effcts of the individual words or that of the
> >resulting word are. (That means it can be done automatically by a
> program!)

> Where the thinking comes in is that you may know that if you group B C D E
> they will form a logically coherant unit that you can give a nice name to
> and use 47 times, whereas by adding F which only followed B C D E twice
> you've severely inhibited its usefulness!

Dear Andras, I want to give you a reference:

Rick VanNorman, "Kwickly Forth", Proceedings of the 1992 Rochester Forth
Conference, June 17-20,1992, Univ.of Rochester, pp.100-103, 4 references,
(ISBN #0-914593-12-9) printed by: OMNIPRESS..."The Proceedings Printer"

The autor presents his technique to analyse large and unfactored Forth
programs. The objective was to replace most frequent sequences of
words by single words.

If I understood it right, the author did the following steps:

0. The text interpreter in substituted by one that performs also
   the following functionality:
1. DO with each definition:
        1) get a sequence of words (withoul line breaks, etc.)
           (it's a text string with blank-delimited words);
        2) Insert 20 spaces into beginning
        3) replicate the string N times, each times shifting it left
           by 1 character (I think that it is possible to shift by 1 word);
        4) write all these strings to a file;
   OD;
[ what we get (for each definition):
   a lot of lines, each of them contains a sequence of words (starting from
   col.21) which may turn out to be a frequent sequence;
   the shifting allows us to consider the subsequences of the :-definition's
   sequence of words. E.g.:
   For

   we get (at col.21):




]
2. sort the file (sorting column is 21) -- a PD utility was used;
[ what we get now:
   the most frequent word sequences will appear many times in the resulting
   file (at col.21), e.g.:


... DUP 1+ SWAP IF ...
... DUP 1+ SWAP THEN ...
   It is not difficult to write a program which reports about such
   repetitions, as well as to examine such a file by means of an editor
]
3. Report about repeating sequences.
[ this is probably what you want to have, if I understood you well
]

I wish you success,
--
Michael L. Gassanenko



Mon, 12 May 1997 05:26:01 GMT  
 To think or not to think ;-)
: What I wanted to point out is that you CAN factor out 'units' without
: knowing what is their inside structure or even their effect. In other
: languages (say C) it is impossible.

Eh?? And what is all the functional abstraction about, the object oriented
design and all that? The rest of the world is definitely not waiting for
the Forth people be be taught about "factoring".

Besides: "not knowing the effect", do you mean it?

: Of course I don't want to suggest to anybody to do such things 'brainlessly'.
:-)

Dirk

---



Mon, 12 May 1997 15:48:15 GMT  
 To think or not to think ;-)

:
: Dear Andras, I want to give you a reference:
:
: Rick VanNorman, "Kwickly Forth", Proceedings of the 1992 Rochester Forth
: Conference, June 17-20,1992, Univ.of Rochester, pp.100-103, 4 references,
: (ISBN #0-914593-12-9) printed by: OMNIPRESS..."The Proceedings Printer"
:
: The autor presents his technique to analyse large and unfactored Forth
: programs. The objective was to replace most frequent sequences of
: words by single words.

 Thanks a lot. This is exacly what I am talking about. I am happy to hear
that the 'automatic factoring of the *TEXT*' has already occured to someone
else so I am not a complete idiot to post such things.
Sometimes I have very {*filter*} oppinion about the operations a compiler should
and should not do and it is good to hear that I am not alone.

Andras



Tue, 13 May 1997 13:26:08 GMT  
 To think or not to think ;-)

: : What I wanted to point out is that you CAN factor out 'units' without
: : knowing what is their inside structure or even their effect. In other
: : languages (say C) it is impossible.
:
: Eh?? And what is all the functional abstraction about, the object oriented
: design and all that? The rest of the world is definitely not waiting for
: the Forth people be be taught about "factoring".
:
: Besides: "not knowing the effect", do you mean it?

 Yes. Read my original post. You don't have to know the exact semantics of
a sequence of words, not even the stack effect in order to factor them out.
I do not suggest to use it as a programming practice I just want to point
out that this is *POSSIBLE*.

Andras



Tue, 13 May 1997 17:53:16 GMT  
 
 [ 12 post ] 

 Relevant Pages 

1. Thinking about thinking

2. Thinking about thinking

3. Thinking about thinking

4. [Example] Thinking about Thinking

5. Thinking about thinking

6. Thinking about thinking

7. Thinking about thinking

8. Thinking about WinHelp Tools? Think $$$

9. Web Think: Applying Web Thinking to Large Aerospace Applicaitons

 

 
Powered by phpBB® Forum Software