Re (2): emacs' approach to text manipulation.

[no.to...@gmail.com]

In article <87ipjny...@kuiper.lan.informatimago.com>, "Pascal J. Bourguignon" <p...@informatimago.com> wrote:

> no.to...@gmail.com writes:
>
> > Just as an example, transforming/reformatting:
> >>> part of line broken into short
> >>> piece
> >>> and continued in a 3rd sub-line
> > to equal length lines of default size,
> > via 'first principles' i.e. with pointers/indices is painfull.
> >
> > But the *nix-tools approach of filtering the data through
> > multiple stages is economical in effort:
> > remove all ">"|
> > translate EOL to <space> |
> > use existing <format all lines to default < len , break at word boundry
> > and remove repeated spaces |
> > prepend "> " to each line|
> > prepend "> " to each line
> >
> > In order to profitably use this powerful & economical method, you
> > need to have a library of suitable filters, which unix has.
> >
> > Since lisp has a functional point-of-view, which matches the idea
> > of serially transforming the data, I'm wondering how emancs would
> > approach the above problem?
>
> Read: http://dorophone.blogspot.com/2011/04/deep-emacs-part-1.html
I'm working on it

> and part 2.
*part-2.html seems not to exist -- yet?

Last time I did a lisp project was IIRC with DOS-xlisp, before 386 existed.
I'll persever with your text, but have you or anyone else considered
using the goal-directed approach i.e. top down?

To explain how a TV works, you start from the [familiar] picture,
and work backwards. You don't start from the rf-tuner end.
Working backwards from the goal [as indeed the device was designed]
'motivates'/shows-the-reason-for each step.

Thus:
* our goal is to economise [on human effort] for programming;
* this is achieved by reducing the number of distinct concepts needed;
* functional/serial-transformation style reduces the number of things
to remember, since at stage N, all previous things, except the output
of N-1 are irrelevant;
* but functional/serial-transformation style require
impedance-matching/compatibility between N-1's output & N's input;
* perhaps monads help with this requirement?

Thanks,

== Chris Glur.