4 ms·

"I eventually made a decision to learn Emacs because I knew that it follows the principles of functional programming better than ordinary shell scripting. In fu

"I eventually made a decision to learn Emacs because I knew that it follows the principles of functional programming better than ordinary shell scripting. In functional programming you have two key ingredients: functions, and a means to compose functions together to build larger functions that solve a particular problem. Without using Emacs, your functions are the Linux CLI tools, and you can compose these tools with shell pipes to solve problems. But Emacs provides better ways of composing CLI tools because it is programmed in Lisp, which is a functional programming language." Lisp is a multi-paradigm language, which lets you program in a functional style, but doesn't force you to do so.

gpderetta 5y ago
and the elisp code you see around does not particularly follow a functional style either. Arguably shell pipelines feel more functional.
zelphirkalt 5y ago
I think one of Emacs' design decisions was deliberately not going fully functional, but having global state and different scoping (Was it "dynamically scoped"? I always forget, which one is which.), because threading everything through all the functions would be quite complicated. However, it may be possible to interact with Emacs using Elisp in a quite functional way.
- dan-robertson 5y ago
  Many early lisps had dynamic scoping only. It meant that this code would return 5 (defvar x 1) ; new global var (defun foo () x) ; function returns x (+ (let ((x 4)) (foo)) (foo)) ; => 5 It also meant that anonymous functions weren’t closures. Later on, scheme used lexical scoping and Common Lisp used lexical scoping normally with dynamic scoping for special (typically global) variables like standard-input. At the time, implementers were worried that they wouldn’t be able to do lexical scoping efficiently. Emacs lisp only had dynamic scoping for a long time. Furthermore it had buffer-local-variables where the editor has a notion of the current buffer, buffers can have definitions of variables, and the value you get for a variable depends on what it is bound to within that buffer as well as dynamically. Over time elisp got true closures/lexical scope, first via a library and later as a language feature (if a certain buffer-local variable is set when you compile/evaluate a file, you get lexical scoping; the easy way to set it is by writing a specially formatted line in the file which allows emacs to set ‘safe’ buffer local variables on opening the file.
  - zelphirkalt 5y ago
    I knew, that Elisp got lexical scoping at some point, but do you know, whether package authors now use it often or maybe even more than dynamic scoping? Also thanks for the practical example of when it makes a difference!
    - omaranto 5y ago
      > lexical scoping [...] do you know, whether package authors now use it often or maybe even more than dynamic scoping? All non-ancient packages use lexical scope. Most ancient packages anyone cared about were converted.
- deleted 5y ago
  [deleted]

gpderetta 5y ago

and the elisp code you see around does not particularly follow a functional style either. Arguably shell pipelines feel more functional.

zelphirkalt 5y ago

I think one of Emacs' design decisions was deliberately not going fully functional, but having global state and different scoping (Was it "dynamically scoped"? I always forget, which one is which.), because threading everything through all the functions would be quite complicated. However, it may be possible to interact with Emacs using Elisp in a quite functional way.

dan-robertson 5y ago
Many early lisps had dynamic scoping only. It meant that this code would return 5 (defvar x 1) ; new global var (defun foo () x) ; function returns x (+ (let ((x 4)) (foo)) (foo)) ; => 5 It also meant that anonymous functions weren’t closures. Later on, scheme used lexical scoping and Common Lisp used lexical scoping normally with dynamic scoping for special (typically global) variables like standard-input. At the time, implementers were worried that they wouldn’t be able to do lexical scoping efficiently. Emacs lisp only had dynamic scoping for a long time. Furthermore it had buffer-local-variables where the editor has a notion of the current buffer, buffers can have definitions of variables, and the value you get for a variable depends on what it is bound to within that buffer as well as dynamically. Over time elisp got true closures/lexical scope, first via a library and later as a language feature (if a certain buffer-local variable is set when you compile/evaluate a file, you get lexical scoping; the easy way to set it is by writing a specially formatted line in the file which allows emacs to set ‘safe’ buffer local variables on opening the file.
- zelphirkalt 5y ago
  I knew, that Elisp got lexical scoping at some point, but do you know, whether package authors now use it often or maybe even more than dynamic scoping? Also thanks for the practical example of when it makes a difference!
  - omaranto 5y ago
    > lexical scoping [...] do you know, whether package authors now use it often or maybe even more than dynamic scoping? All non-ancient packages use lexical scope. Most ancient packages anyone cared about were converted.
deleted 5y ago
[deleted]