emacs lisp bounds-of-thing-at-point and function chaining

Perm url with updates: http://xahlee.org/emacs/thing-at-point_chaining_functions.html

Emacs thing-at-point and Chaining Functions

Xah Recommends:
Amazon Kindle. Read books under the sun. Review

Xah Lee, 2010-10-08

The elisp function 「(thing-at-point 'line)」 is quite annoying.

It is used to grab the current line. Like this:

(defun xxtest ()
  (let (myline)
    (setq myline (thing-at-point 'line) )
    (message "got this: 「%s」" myline)
    ) )

It grabs the line including the line return at the end. However, if the line is the end of file then it does not include the end of line char.

This means, you have to do manual checking after you grab the line.

Use “line-beginning-position” and “line-end-position” instead. (See: All About Processing Lines in Emacs Lisp)

Functional Programing: Chaining Functions

This issue is actually common in programing langs, in Perl, Python, unix shells, all fuck up on this. In Mathematica, there's a principle, that any function always return the same form. For example, a function that solves equation or filters a list, it normally returns a list 「{...}」. But what if the input has no solution? In other langs, they might return nil, null, none, undef, or whatnot fuck. In Mathematica, it simply returns the same form (same tree structure), in this case a empty list. (and in type-ful langs: it should return the same form and same type)

The point is, the programer do not have to do extra checks, or extra “if” statement, when chaining functions. When chaining functions, the functions do not have to break out into a little extra “if” statement or form/type checking. Imagine, water is flowing thru pipes. If no water, or bad water, your filter or checkpoint doesn't have to cut the pipe open to exam it.

This principle is especially important in functional programing. In imperative programing and languages, it matters less, because programer don't chain functions that much (cause often the lang can't), and basically the entire source code is just miscellaneous blocks to do this and that.

In functional programing, overall you simply have 2 blocks in your source code. One for function definitions. And the other, is abstractly one single line of chained functions. Even lisps, usually fail grasping this fundamental idea. (and due to the cumbersome nested paren, which effectively stop the chaining paradigm. (See: Fundamental Problems of Lisp.) )

The following articles are all relevant:

Was this page useful? If so, please do donate $3, thank you donors!

Popular posts from this blog

11 Years of Writing About Emacs

does md5 creates more randomness?

Google Code shutting down, future of ErgoEmacs