In Elisp, I've encountered different APIs for modeling boolean values.
I was under the impression that t and nil were the idiomatic ways of representing true and false respectively. However, I've also seen 1 and -1 used to model the same thing.
What confuses me is that I have come across APIs that won't work if nil is supplied but will work if -1 is used.
Can someone help me understand which is in fact the preferred way. And if the answer is t and nil, I welcome any theories on why some developers use 1 and -1 for their APIs...
sds and sepp2k have covered the main misconception, but in answer to:
why some developers use 1 and -1 for their APIs...
The reason that Emacs minor modes use positive and negative numbers (or rather non-positive numbers, including zero) to mean "enable" and "disable", rather than using t and nil, is that the argument is optional, and when an optional argument is not supplied its value will be nil. Consequently it would not be possible to distinguish between passing an argument of nil explicitly, and not passing an argument at all.
Historically, passing no argument (i.e. an argument of nil) meant that the mode would be toggled.
These days the mode is only toggled when calling it interactively, and an argument of nil means "enable". This change was made so that the likes of (add-hook 'prog-mode-hook 'some-minor-mode) -- which will result in some-minor-mode being called with no arguments -- is guaranteed to enable that mode.
Lisp
In lisp (both Emacs Lisp and Common Lisp) the only false value is nil.
Everything else is true, including 0, -1 &c &c.
Emacs
Emacs uses negative arguments (including -1) to indicate "turn off this mode". E.g., C-h f toggle-truncate-lines
With prefix argument ARG, truncate long lines if ARG is positive,
otherwise fold them.
Related
Is the distinction between the 3 different let forms (as in Scheme's let, let*, and letrec) useful in practice?
I am current in the midst of developing a lisp-style language that does current support all 3 forms, yet I have found:
regular "let" is the most inefficient form, effectively having to translate to an immediately called lambda form and the instructions generated are nearly identical. Additionally, I haven't found myself needing this form very often.
let* (sequential binding) seems to be the most practically useful and most often used. This form can be translated to a sequence of nested "lets", each environment storing a single variable. But this again is highly inefficient, wasting space and lookup time.
letrec (recursive binding) can be efficiently implemented, given that no initializer expression refers to an unbound variable. Typically the case is that all initializers are lambda expressions and the above is true.
The question is: since letrec can be efficiently implemented and also subsumes the behavior of let*, regular let is not often used and can be converted to a lambda form with no great loss of efficiency, why not make default "let" have the behavior of the current "letrec" and be rid of the original "let"?
This [let*] form can be translated to a sequence of nested "lets", each environment storing a single variable. But this again is highly inefficient, wasting space and lookup time.
While what you are saying here is not incorrect, in fact there is no need for such a transformation. A compiling strategy for the simple let can handle the semantics of let* with just simple modifications (possibly supporting both with just a flag passed to common code).
let* just alters the scoping rules, which are settled at compile time; it's mostly a matter of which compile-time environment object is used when compiling a given variable init form.
A compiler can use a single environment object for the sequential bindings of a let*, and destructively update it as it compiles the variable init forms, so that each successive init form sees a more and more extended version of that environment which contains more and more variables. At the end of that, the complete environment is available with all the variables, for doing the code generation for generating the frame and whatnot.
One issue to watch out for is that a flat environment representation for let* means that lexical closures captured during the variable binding phase can capture future variables which are lexically invisible to them:
(let* ((past 42)
(present (lambda () (do-something-with past)))
(future (construct-huge-cumbersome-object)))
...))
If there is a single run-time environment object here containing the compiled versions of the variables past, present and future, then it means that the lambda must capture that environment. Which means that although ostensibly the lambda "sees" only the past variable, because future is not in scope, it has de facto captured future.
Thus, garbage collection will consider the huge-cumbersome-object to be reachable for as long as the lambda remains reachable.
There are ways to address this, like accompanying the environmental reference emanating from the lambda with some kind of frame index which says, "I'm only referencing part of the environment vector up to index 13". Then when the garbage collector traverses this fenced reference, it will only mark the indicated part of the environment vector: cells 0 to 13.
Anyway, about whether to implement both let and let*. I suspect if Lisp were being "green field" designed from scratch today, many designers would like reach for the sequentially binding version to be called let. The parallel construct would be the one available under the special name let*. The situations when you actually need let to be parallel are fewer. For instance, let allows us to re-bind a pair of variable symbols such that their contents appear exchanged; but this is rarely something that comes up in application programming. In some programming language cultures, variable shadowing is frowned up on entirely; GNU C has a -Wshadow warning against it, for instance.
Note how in ANSI Common Lisp, which has let and let*, the optional parameters of a function behave sequentially, like let*, and this is the only binding strategy supported! So that is to say:
(lambda (required &optional opt1 (opt2 opt1)) ...)
Here the value of opt2 is defaulted from whatever the value of opt1 is at the time of the call. The initialization expression of opt2 has the opt1 parameter in scope.
Also, in the same Lisp dialect, the regular setf is sequential; if you want parallel assignment you must use psetf, which is the longer name of the two.
Common Lisp already shows evidence of design decisions more recent than let tend to favor sequential operation, and designate the parallel as the extraordinary variant.
Think of metaprogramming. If your default let will sequentially create nested scopes, you'll have to make sure that none of the initialiser expressions are referring to the names from the wrong scopes. You have such a guarantee with a regular let. Control over name scoping is very important when you're generating code.
Letrec is even worse, it's introducing a very complicated scope rules that cannot be easily reasoned with.
Tried to use the persp-mode https://github.com/Bad-ptr/persp-mode.el/blob/master/persp-mode.el to retrieve the emacs windows session after restart. Unable to get it working.
So trying to understand the datastructure used to store the state of the emacs by reading the source code.
The following is the function which is used to store the session state.
(defun* persp-save-state-to-file (&optional (fname persp-auto-save-fname)
(phash *persp-hash*)
respect-persp-file-parameter)
(interactive (list (read-file-name "Save perspectives to file: "
persp-save-dir)))
In the above function two unusual things are observed using edebug (unusual according to my current understanding of elisp).
The optional argument expressions are evaluated.
The expression "(interactive..." is evaluated first and then the optional argument expressions are evaluated.
Any ideas how to debug the code. Also the emacs documentation says "defun*" is related to common-lisp, but no further information is available in emacs docs on how defun* is different from defun. Is there a quick tutorial oh what defun* does without having to learn common-lisp.
Emacs says:
Define NAME as a function. Like normal `defun', except ARGLIST allows
full Common Lisp conventions, and BODY is implicitly surrounded by
(cl-block NAME ...).
Common Lisp arglists provide optional, rest, keyword and aux arguments. Historically this comes from Lisp Machine Lisp and Mumble - two earlier Lisp dialects.
For details see: http://www.gnu.org/software/emacs/manual/html_node/cl/Argument-Lists.html
Have a look at this post for a simplistic snippet explaining
how optional works. The gist is that e.g. persp-auto-save-fname will be the value of fname
if none is given.
And obviously interactive has to be run first, because it provides the arguments.
So if interactive doesn't provide a value for fname it will be persp-auto-save-fname.
I'm curious about the return value of define in Scheme. So I wrote the following lines in Racket
#lang r5rs
(display (define a 3))
And get the error
define: not allowed in an expression context in: (define a 3)
I have 2 questions about this:
Does it mean that define has no return value?
According to R5RS, define is not an expression. It's a program structure. Is it true that only expressions have return values, and other forms don't?
"If a tree falls in a forest and no one is around to hear it, does it make a sound?"
It's not valid to use define in any context where a return value could meaningfully be obtained. So it's moot whether it has a return value or not; you'll never be able to observe it.
In Scheme, define can only be used in two places:
At the top level, or
At the very beginning of a "body".
In neither of those places is a "return value" relevant.
By default Emacs will not highlight constants, struct members, function calls etc (unless inside the definition). I am talking about C major mode here.
I want some basic highlighting, just based on text matching. For example, A word containing only upper case and underscore, [A-Z_]+, for example SOME_CONST, is a constant (unless otherwise highlighted). Similarly, I can match for [a-zA-Z_][a-zA-Z0-9_]\s( as function call; ->[a-zA-Z_][a-zA-Z0-9_]* as a struct member etc.
How can I do this emacs ?
I think the elisp function that you want is font-lock-add-keywords. I've added the following to my .emacs and gotten what I think you want for upper case words:
(font-lock-add-keywords 'c-mode '("\\<\[A-Z_\]\+\\>"))
You'd have to add a bit more to handle integer constants. Some of the documentation around this warns that if you're not intelligent about your regular expressions it can slow things down dramatically, and that you should use regexp-opt for matching multiple keywords.
The part that was a bit confusing for me is that the argument to font-lock-add-keywords can be a regular expression.
This question is really moot, I think I must have hit a bug in my program or something. If you are still looking for PicoLisp and onOff behaviour, look here.
is this supposed to happen?
: (show NIL)
NIL NIL
-> NIL
: (onOff)
-> T
: (show NIL)
T T
-> T
: (=T NIL)
-> T
:
(onOff sym ..) -> flg
Logical negates the VAL's of all argument symbols sym. Returns the
new value of the last symbol.
Should not the symbol names be passed explicitly?
Why does it return value of the last symbol?
It's a bug in the PicoLisp implementation with the onOff macro.
The parameters of the onOff function are: (onOff var ..) -> flg
It takes a var and many more variables and logically negates them (true becomes false, false becomes true). I'm willing to bet that the onOff macro takes a single list of arguments. Which means that if NO arguments are given to it, that list of arguments is empty which means the symbol given to the function is NIL.
Macro is bolded because that's where the problem lies. Using a macro makes it so you can pass the symbols to it without quoting. So the onOff macro is generating incorrect code.
This was a red herring, there was no bug. Sorry, HN wrong call. Also, it is now under the MIT (X11) license, the most liberal of open source licenses.