Re: Defining functions on the fly

[Pascal J. Bourguignon]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> Am 16.06.2015 um 11:50 schrieb Pascal J. Bourguignon:
>> There are hooks to customize those general commands to specific modes!
>> For example, instead of writing:
>>
>>      bash-forward-sexp
>>      sh-forward-sexp
>>      pascal-forward-sexp
>>      ada-forward-sexp
>>
>> etc, each mode will just bind a specific forward sexp function to the
>> hook variable:  forward-sexp-function, and forward-sexp will call it.
>>
>>
>
> That's a consideration at the command- resp. key-binding level.
> Nonetheless mode-specific functions are needed to bind then.

Of course, and mode-specific functions will have a mode-specific prefix
in their name.

But if you have functions that are not mode-specific, like,
    (generate-parser mode-specific-grammar), or
    (parse-to-point mode-specific-grammar), 
you DO NOT DUPLICATE those functions with names such as
    pascal-generate-parser  pascal-parse-to-point
    ada-generate-parser     ada-parse-to-point
    c-generate-parser       c-parse-to-point
    bash-generate-parser    bash-parse-to-point
This is dumb.

What you do is to call those general functions from your mode-specific
functions (that since they are specific and different for each mode, do
not contain duplicated code).

What you could do, for those generic functions, is to put them in a nice
re-usable library, give a name to the library, and prefix them by the
name of the library. Eg. if you name the library bovidae, then you will
have:

     bovidae-generate-parser
     bovidae-parse-to-point

but you would not duplicate those functions with names such as:
    pascal-bovidae-generate-parser  pascal-bovidae-parse-to-point
    ada-bovidae-generate-parser     ada-bovidae-parse-to-point
    c-bovidae-generate-parser       c-bovidae-parse-to-point
    bash-bovidae-generate-parser    bash-bovidae-parse-to-point
This would be dumb.


> For now these language mode often invent very basic things in
> parallel: string-strip, in-string-p etc.
> Also creating bugs and quirks that way.

Then factorize that out in a common library!


> Beyond that we can generalize top-level, block, expression and
> statement -- at least to some extend.

You already have a few such functions:

    beginning-of-defun
    end-of-defun
    indent-defun
    mark-defun
    narrow-to-defun


Also, I've noticed a remark in the thread.

Some languages distinguish statements and expressions (and sometimes
also declarations or definitions), but some other languages only have
expressions.  The laters are much more usable and agreable, and more
easily edited also.

When parsing a program, you naturally obtain parse trees labelled with
the kind statement, expression, definition, etc.  But when editing, you
might want to flatten all this down to expressions (sexp), as if you
were editing lisp, because it is easier.  But you could provide tools to
convert between statements and expressions.

For example, if you kill a C statement (selection shown with []):

   [ x=a+b; ]
     if(a==b){
       x=0;
     }else{
       y=42;
     }

then move into an expression context (point shown with |):

     if(|a==b){
       x=0;
     }else{
       y=42;
     }

and yank, the statement x=a+b; could be transformed into an expression
(semicolon removed):

     if((x=a+b),|(a==b)){
       x=0;
     }else{
       y=42;
     }

And backward, an expression:

   x=[ (a==b)?0:42 ];

killed and yanked into statement context:

   {
    |
   }

would transform it into a statment:

   {
    if(a==b){
     return 0;
    }else{
     return 42;
    }
  }   

-- 
__Pascal Bourguignon__                 http://www.informatimago.com/
“The factory of the future will have only two employees, a man and a
dog. The man will be there to feed the dog. The dog will be there to
keep the man from touching the equipment.” -- Carl Bass CEO Autodesk