GNU Emacs 20.7 has a function documented as:
> get-largest-window is a built-in function.
>
> Return the largest window in area.
> If optional argument FRAME is `visible', search all visible frames.
> If FRAME is 0, search all visible and iconified frames.
> If FRAME is t, search all frames.
> If FRAME is nil, search only the selected frame.
> If FRAME is a frame, search only that frame.
>
> (get-largest-window &optional FRAME)
Does some older Lisp system also have functions that give such a
non-numeric meaning to the integer zero? Emacs Lisp uses 0 in
obarrays too; did it inherit that from somewhere?
Would a Common Lisp program define this function with keywords
instead of visible, 0, t and nil?
Kalle Olavi Niemitalo <···@iki.fi> writes:
> GNU Emacs 20.7 has a function documented as:
>
> > get-largest-window is a built-in function.
> >
> > Return the largest window in area.
> > If optional argument FRAME is `visible', search all visible frames.
> > If FRAME is 0, search all visible and iconified frames.
> > If FRAME is t, search all frames.
> > If FRAME is nil, search only the selected frame.
> > If FRAME is a frame, search only that frame.
> >
> > (get-largest-window &optional FRAME)
>
> Does some older Lisp system also have functions that give such a
> non-numeric meaning to the integer zero? Emacs Lisp uses 0 in
> obarrays too; did it inherit that from somewhere?
>
> Would a Common Lisp program define this function with keywords
> instead of visible, 0, t and nil?
Strange question. I'm curious why it's asked.
As with most questions like this, it depends on who wrote it and for
what purpose.
A program trying to span multiple dialects, some of which had no
keywords, might do things like this.
Also, even in one dialect, Zmacs used to make distinction betwen calling
someting by Control-U and Control-U 4 (even though they had the same
numerical meaning, you could get extra meaning out of which gesture
had been used). Likewise Control-Minus and Control-Minus Control-1
So in terms of interactively calling something, you wanted to get the
most out of your interface, you might designate a few extra args
like T and NIL and assign them to Control-U and Control-1 and have
all other args be specific keyed-in arguments so that you had something
that was program-callable but also had a clear mapping to a key
command. This means a few special values as args, and the rest have
to be shoehorned into the small integers.
Some functions are designed to be dispatched in a uniform way, so
an integer result might be useful. For example, in Maclisp, where
characters were integers, returning -1 was the eof-value was common
because being able to have the result be fixnum was important (maybe
ieven necessary--I can't recall).
In Maclisp, also, there was a general-purpose inquiry form called
status that took "keywords" (unevaluated symbols) saying what to do.
(status its) would return the number of seconds (as a flonum [i.e, float])
until the system was due to go down, or -1.0 if the system was not due
to go down or -2.0 if the system was already down [this amused me at
first until I remarked about it to an expert, who halted timesharing
and ran lisp in non-timesharing mode, where it returned -2.0].
I'm sure there are lots of precedents for number-declared functions
returning 0 as a don't-know value. Most-positive-fixnum is probably
used once in a while, too.
I'm told that in the ancient human languages, there were designated
values (soemtimes as small as 3), but usually bigger, that passed for
infinity in similar ways. As I heard it, 40 was often used to mean
infinity, hence the 40 days and 40 nights in the Bible's big flood
rain thing is supposed to be read "an infinitely or uncountably
long time", not a literal 40. I have no formal reference to back
this up. If someone knows it to be false, or can offer a refinement
of the story, I'd be curious.
Kent M Pitman <······@world.std.com> writes:
> > Would a Common Lisp program define this function with keywords
> > instead of visible, 0, t and nil?
>
> Strange question. I'm curious why it's asked.
I felt the use of 0 there is strange because the function gives a
pretty similar meaning to the symbol "visible"; it's weird that the
value for "search all visible and iconified frames" is suddenly a
number. At first I thought Emacs might be using some fast dispatch
that checks just the type; but it isn't. Perhaps it's just to save
symbols, like you once wrote you do. (visible-or-iconified does not
yet exist as a symbol.)
As for that question, I was thinking of how you (plural) changed
EVAL-WHEN to use keywords. Plus I had trouble deciding whether to
post on comp.emacs or comp.lang.lisp and thought this would make it
more topical here. :-)
> This means a few special values as args, and the rest have
> to be shoehorned into the small integers.
If it were that, they'd have used a number instead of the "visible"
symbol too.
I'm still hoping for a history reference about 0 in obarrays.
If older Lisps had obarrays like Emacs Lisp has, that is.
Kalle Olavi Niemitalo <···@iki.fi> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > > Would a Common Lisp program define this function with keywords
> > > instead of visible, 0, t and nil?
> >
> > Strange question. I'm curious why it's asked.
>
> I felt the use of 0 there is strange because the function gives a
> pretty similar meaning to the symbol "visible"; it's weird that the
> value for "search all visible and iconified frames" is suddenly a
> number. At first I thought Emacs might be using some fast dispatch
> that checks just the type; but it isn't. Perhaps it's just to save
> symbols, like you once wrote you do. (visible-or-iconified does not
> yet exist as a symbol.)
>
> As for that question, I was thinking of how you (plural) changed
> EVAL-WHEN to use keywords. Plus I had trouble deciding whether to
> post on comp.emacs or comp.lang.lisp and thought this would make it
> more topical here. :-)
Well, EVAL-WHEN was changed because shadowing it was hard without also
shadowing the keywords. In a language without keywords, where you might
want to return a symbol like VISIBLE (rather than :VISIBLE), there would
be the additional concern that shadowing the word VISIBLE would shadow
the return value from this function. By sticking to values like T and NIL
that tend to be in all user packages, you reduce this risk a lot (though
not entirely because some people do try to shadow T and NIL -- still, those
people set themselves up for lots of aggravation and are ready for it).
> > This means a few special values as args, and the rest have
> > to be shoehorned into the small integers.
>
> If it were that, they'd have used a number instead of the "visible"
> symbol too.
Probably in that case. But I was answering your question more generally.
Consider a function that moves a window might have this argspec:
A positive integer x moves the window x to the left.
A negative integer x moves the window -x to the right.
Control-- moves the window to be left aligned with its superior.
Control-0 moves the window to be centered relative to its superior.
Control-u moves the window to be right aligned with its superior.
This would be pretty easy to remember and you might imagine the calling
sequence would be
(move-window n)
where n was one of -x, x, nil, 0, or t respectively for the above situations
not because -x, x, :left, :center, and :right wouldn't be clearer but because
there might be an overarching style that all commands tended to take this
particular set of special cases.
Then again, if one were really organized about it, one might allow the command
to be defined so that program-calling could specify that an interactive gesture
of control-- was the equivalent of a program-call with :left. But that would
be only one possible language design decision, and as I've so often mentioned,
langauge design decisions are not good in the abtract, they are only good in
context, so you'd have to see the rest of the language to know what was best.
I was merely trying to justify what you asked for a justification for, because
I felt you were saying "could there be a possible justification" and I think
the answer is "yes". I wasn't making a statement about whether this was
a necessary way to go.
> I'm still hoping for a history reference about 0 in obarrays.
> If older Lisps had obarrays like Emacs Lisp has, that is.
*** WARNING ***
Text beyond here describes HISTORICAL elements of Lisp and does
not apply to Common Lisp nor probably any modern Lisp dialect. Read
onward if you like that kind of thing, but don't let it confuse you about
how Lisps work, since they have changed a lot since.]
*** WARNING ***
I'm not familiar with GNU Emacs obarrays so I can't say if they were
related to earlier dialects. I'm really not sure why any discussion
of obarrays is relevant to this discussion since (in Maclisp at least)
obarrays did not have much to do with integers except insofar as they
were arrays and required integers to index into them. Also, in Maclisp,
:foo was just a symbol on the obarray like any other, with : being
alphabetic. The following data is from my Revised Maclisp Manual
(not presently webbed, but hopefully coming soon ... I had it almost
done last fall and then had a disk crash at an unfortunate time when
I was behind on backups -- shame on me):
| Elements of an obarray are lists of symbols which are the fillers of that
| ``bucket'' in the obarray. The hash function for determining which symbol
| belongs in which bucket is (\ (SXHASH _sym_) 511.).
[where as a historical note, backslash (\) is the remainder function
for Maclisp and slash (/) in Maclisp was used for what backslash
in Common Lisp is used for.]
So the only place that 0 gets involved is when SXHASH returns a number that
is when SXHASH returns something that is 0 mod 511, or however one says that.
Here's the spec for SXHASH in case that helps:
| (SXHASH q) SUBR 1 arg
| SXHASH computes a hash code of an S-expression, and returns it as a
| (possibly negative) fixnum. A property of SXHASH is that
| (EQUAL x y) _implies_ (= (SXHASH x) (SXHASH y)).
| The number returned by SXHASH is some possibly large number in
| the range allowed by fixnums. It is guaranteed that:
| 1) SXHASH for an atomic symbol will always be positive.
| 2) SXHASH of any particular expression will be constant in
| a particular implementation for all time.
| 3) Two different implementations may hash the same
| expression into different values.
| 4) SXHASH of any object of type RANDOM will be zero.
| 5) (= (SXHASH i) i), for any fixnum i.
[Note: Maclisp type RANDOM was the type for things that didn't have any
other type and that you weren't supposed to play with. The most common
thing users would get their hands on of type RANDOM was a compiled function
pointer, which had no type of its own, and was normally manipulated
indirectly through the name of a function, there being no SYMBOL-FUNCTION
operation, but could be found on the SUBR or LUSBR or FSUBR property of
a symbol. But other things could be type RANDOM, if you accidentally (or
intentionally used compiled calls (to avoid error checking) to CAR or CDR
or CXR to go into parts of objects not intended to be gone-into, like
SYMBOL block headers.]
Further obarray trivia in case you care:
| The value of OBARRAY is an array which is a table of known symbols. When
| a symbol is read in it is _interned_ on this obarray (ie, made EQ to any
| atomic symbols with the same pname that were previously read in).
| If a symbol, such as one created by (GENSYM), is not in this table an atom
| read in with the same pname will not be EQ. There will be two separate
| copies. The obarray may be manipulated by the functions REMOB and INTERN.
| A new obarray can be created using the function *ARRAY (preferred) or ARRAY.
| The symbol OBARRAY may be SETQ'd or lambda-bound to different obarrays at
| different times, which allows multiple sets of symbols to be kept separate
| -- you can have different symbols with the same pname interned on different
| obarrays at the same time. Note that the value of OBARRAY is not a symbol
| which names an array, but an array object itself. [...]
|
| The array property of the symbol OBARRAY is the same array as its
| initial value. It is recommended that the value of this property not be
| changed since it is frequently invaluable to have this backup pointer
| available while debugging.
|
| Example:
|
| ;; User-defined INTERNEDP predicate...
| (DEFUN INTERNEDP (X)
| (MEMQ X (ARRAYCALL T OBARRAY (\ (SXHASH X) 511.))))
Hope this helps.
Kent M Pitman <······@world.std.com> writes:
> I'm really not sure why any discussion
> of obarrays is relevant to this discussion since (in Maclisp at least)
> obarrays did not have much to do with integers except insofar as they
> were arrays and required integers to index into them.
In Emacs Lisp, obarrays don't contain NIL-terminated CDR-linked lists;
instead, they contain 0-terminated lists linked through a hidden slot
in each symbol. (This makes it impossible to intern a symbol in
multiple obarrays without messing with other symbols.) I assumed the
use of 0 there was related to its use as a special argument, but I
guess not.
Thanks for the info!
Kalle Olavi Niemitalo <···@iki.fi> wrote:
: GNU Emacs 20.7 has a function documented as:
:> get-largest-window is a built-in function.
:>
:> Return the largest window in area.
:> If optional argument FRAME is `visible', search all visible frames.
:> If FRAME is 0, search all visible and iconified frames.
:> If FRAME is t, search all frames.
:> If FRAME is nil, search only the selected frame.
:> If FRAME is a frame, search only that frame.
:>
:> (get-largest-window &optional FRAME)
: Does some older Lisp system also have functions that give such a
: non-numeric meaning to the integer zero? Emacs Lisp uses 0 in
: obarrays too; did it inherit that from somewhere?
autolisp, based on xlisp, doesn't do that. users also don't.
we would use strings, no symbols, because quoted symbols mess up our
optimizer. symbols as special arg had been used for two or three core
functions, to do it the lispish way, but then people didn't care for the
advantages and stayed with the simple, slow and wasteful strings.
esp. with the COM extension which could have been solved by strings,
symbols or keywords, it was designed for certain funcs with keywords taking
strings, and symbols or strings. people keep using strings.
(vla-invoke com-object "method") or (vla-invoke com-object 'method) as
stylistic point we do sometimes use symbols here for long strings (> 10
chars), because the probability to trash the optimizer is less and the
advantage for symbols over strings is bigger.
but numbers like 0 or -1 here are just inconsistent and bad C habits.
he didn't want to introduce :visible.
--
Reini Urban
http://xarch.tu-graz.ac.at/acadwiki/AutoLispFaq