datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Drew Adams]

The Elisp Info on Lisp Data Types is presented near the beginning of the
manual, as it is important, basic information. Reading this info, I see no
mention of `face'; `face' is not a datatype. A face is (`type-of') either a
symbol or a vector. Fair enough; some of the "kinds of things", such as
`face', that we reference casually are not themselves datatypes.

But I wonder if perhaps something about this shouldn't be mentioned in the
Info section on datatypes - perhaps mentioning `face' as an example of
something you might in some ways be inclined to think of as a datatype but
that Emacs treats differently from a type. Point out, in particular, that
not everything that has what might look like a type predicate is a
datatype - e.g. `facep'.

Readers can get the impression when reading the section on datatypes that it
covers all of the standard "things" we manipulate in Emacs Lisp. Looking at
the list of type predicates, a reader would never guess that faces even
exist, yet they are important things that we manipulate everyday. There is
no `face' type, but there are faces.

It might help to add a short explanation of this, including mention of
predicates like `facep' that look like, but are not really, type predicates.

What I'm suggesting is:

1) Mention that we sometimes speak casually of some things as if they were
of a particular abstract type, when there is no such type. Make readers
aware that when we speak of some things, like `buffer' and `function', there
are corresponding datatypes, and when we speak of other things, like `face',
there is no corresponding (`face') datatype. This is not obvious, and it's
not obvious which things, like `function', correspond to a datatype and
which, like `face', do not - there is nothing in the predicate names
`functionp' and `facep' that provides a clue.

(And functions, like faces, come in more than one form. It's not obvious why
`function' is considered an abstract datatype with representations as
diverse as lambda expression, keystroke command, and primitive, yet symbol
and vector are not considered the representations of an abstract `face'
datatype.)

2) Cross-reference the discussions of some of the important "non-types",
such as `face'. A reader of the datatypes section and the list of type
predicates would be helped by being made aware that there are also other
(non-primitive) kinds of things that we manipulate, and the reader should be
able to link to the doc of such important things as faces.

Obviously, there is no limit to the "kinds of things" that can exist that
have no corresponding datatype of the same name. The point is just to
mention that 1) such things can exist, and 2) `face', in particular, is one
(and cross-reference the face doc).

Finally, I'm ignorant: Just why is `face' not treated similarly to
`function' - why isn't `face' a datatype? If the answer expresses a general
rule, then perhaps that rule should also  be included in the doc, to clarify
things.

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Thien-Thi Nguyen]

"Drew Adams" <drew.adams@oracle.com> writes:

> Finally, I'm ignorant: Just why is `face' not treated similarly to
> `function' - why isn't `face' a datatype? If the answer expresses a
> general rule, then perhaps that rule should also be included in the
> doc, to clarify things.

probably the general rule is not to introduce too many fundamental
types, as doing so exponentiates complexity, unless absolutely
necessary.  for faces, it doesn't appear to be necessary.

i got on a kick of documenting internals (to exercise a pet doc
extraction system i wrote) for a personal project and am now wondering
how it was that enthusiasm triumphed over experience Yet Again...  so,
while i agree that the documentation could make more distinction between
fundamental and composed (or "defined-by-conventional-use") types, i
figure that doing so might be a bad idea because it would constrain the
implementation.

since `facep' works like `functionp' (fsvo "like"), that should be what
programmers rely on.  if in the future faces become fundamental, that
transition will be easier to handle if prior internals were left
unexposed (ignorance is bliss).

thi

RE: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Drew Adams]

    while i agree that the documentation could make more distinction between
    fundamental and composed (or "defined-by-conventional-use") types, i
    figure that doing so might be a bad idea because it would constrain the
    implementation.

    since `facep' works like `functionp' (fsvo "like"), that should be what
    programmers rely on.  if in the future faces become fundamental, that
    transition will be easier to handle if prior internals were left
    unexposed (ignorance is bliss).

One of my concerns is that readers of the datatypes section will not know
that faces exist. This section is near the beginning of the manual, and it
can give the impression that it also presents all of the important
Emacs-Lisp objects.

At a minimum, I think it would help to mention that, although these are the
only datatypes, there are additional things of interest (like faces) that
are not listed here.

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Miles Bader]

On 6/24/05, Drew Adams <drew.adams@oracle.com> wrote:
> Finally, I'm ignorant: Just why is `face' not treated similarly to
> `function' - why isn't `face' a datatype? If the answer expresses a general
> rule, then perhaps that rule should also  be included in the doc, to clarify
> things.

I tend to think of datatypes in lisp as being disjoint categories of
values; a value can only every have one datatype.

By this rule, a face is not a datatype.  Neither is a variable, and
really neither is a `function' (though there are distinct "function"
datatypes, for instance subrs and compiled-functions).

To be a bit looser, maybe you could say a value has a particular type
if it (1) satisfies some predicate, and (2) the predicate doesn't
depend on any state except the value itself.

This seems as if it would reflect the way people usually think -- you
could have a `function' datatype which included subrs,
compiled-functions, and lambdas, but it _wouldn't_ include fboundp
symbols; type-hierarchies like `number' and `integer' would also work
naturally.

Using that rule, `face' still wouldn't be datatype though, because the
whether a symbol (the lisp representation for a face) is a face or not
depends on external state, not just the value itself.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Richard M. Stallman]

    But I wonder if perhaps something about this shouldn't be mentioned in the
    Info section on datatypes - perhaps mentioning `face' as an example of
    something you might in some ways be inclined to think of as a datatype but
    that Emacs treats differently from a type.

Adding a brief section about faces in that chapter is a good idea.
I don't have time to work on it, but if someone else writes it,
we could install it.

    2) Cross-reference the discussions of some of the important "non-types",
    such as `face'.

My memory doesn't recall any others, but I wouldn't want to rely on it.
What others do you know of?

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Kenichi Handa]

In article <E1Dlgs1-0001Zk-PG@fencepost.gnu.org>, "Richard M. Stallman" <rms@gnu.org> writes:

>     But I wonder if perhaps something about this shouldn't be mentioned in the
>     Info section on datatypes - perhaps mentioning `face' as an example of
>     something you might in some ways be inclined to think of as a datatype but
>     that Emacs treats differently from a type.

> Adding a brief section about faces in that chapter is a good idea.
> I don't have time to work on it, but if someone else writes it,
> we could install it.

>     2) Cross-reference the discussions of some of the important "non-types",
>     such as `face'.

> My memory doesn't recall any others, but I wouldn't want to rely on it.
> What others do you know of?

coding-system, charset, fontset?

---
Kenichi Handa
handa@m17n.org

RE: datatypes in Elisp Info: mention "things" for which there is no"thing" datatype - e.g. faces

[Drew Adams]

        But I wonder if perhaps something about this shouldn't be
        mentioned in the
        Info section on datatypes - perhaps mentioning `face' as an
        example of
        something you might in some ways be inclined to think of as
        a datatype but
        that Emacs treats differently from a type.

    Adding a brief section about faces in that chapter is a good idea.
    I don't have time to work on it, but if someone else writes it,
    we could install it.

        2) Cross-reference the discussions of some of the important
        "non-types", such as `face'.

    My memory doesn't recall any others, but I wouldn't want to rely on it.
    What others do you know of?

I didn't have any others in mind. I just wanted to speak about this
generally, in case there were others. (Kenichi Handa mentions coding-system,
charset, fontset.)

RE: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Drew Adams]

    > Finally, I'm ignorant: Just why is `face' not treated similarly to
    > `function' - why isn't `face' a datatype? If the answer
    > expresses a general
    > rule, then perhaps that rule should also  be included in the
    > doc, to clarify things.

    I tend to think of datatypes in lisp as being...

Whatever people decide on this should be reflected in the Elisp manual (i.e.
it should be updated). Currently, I'm not sure that your POV is reflected
there. There are two places where the `function' datatype is discussed,
which are linked: 1) Lisp Data Types and 2) Functions, linked through
`functionp' at Type Predicates. It's not clear whether the entire discussion
at Functions applies to the `function' datatype.

In general, perhaps we should be clearer when we are speaking of an
"official" datatype and when we are speaking rather more loosely.

If Elisp "datatype" does not reflect something objective and operational
(e.g. determinable by program), then perhaps we shouldn't speak of
"datatype" at all. IOW, perhaps we should either make it clear what
constitutes an Elisp datatype, and which "kinds of things" are datatypes, or
not speak of Elisp datatypes at all.

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Stefan Monnier]

>     2) Cross-reference the discussions of some of the important "non-types",
>     such as `face'.

> My memory doesn't recall any others, but I wouldn't want to rely on it.
> What others do you know of?

        obarray

Not sure how important it is for this section of the elisp manual, tho,
especially now that we have hash-tables.


        Stefan

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Kevin Rodgers]

Miles Bader wrote:
 > I tend to think of datatypes in lisp as being disjoint categories of
 > values; a value can only every have one datatype.

But types form a hierarchy, see e.g.
M-: (info "(elisp)Sequences Arrays Vectors")

-- 
Kevin Rodgers

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Luc Teirlinck]

Miles Bader wrote:

   I tend to think of datatypes in lisp as being disjoint categories of
   values; a value can only every have one datatype.

It can only have one _primitive_ data type (returned by type-of), but
it can have tons of data types.  See `(elisp)Lisp Data Types' and 
`(elisp)Type Predicates'.

Sincerely,

Luc.

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Luc Teirlinck]

For purposes of this discussion, note that facep is not a type
predicate, because it returns t for face names (strings or symbols) as
well as for internal face objects.  I noticed that the docs for facep
are not very clear on this.  I propose the following doc changes,
which I could install if desired:

===File ~/faces.el-diff=====================================
*** faces.el	23 Jun 2005 16:53:05 -0500	1.324
--- faces.el	24 Jun 2005 13:47:03 -0500	
***************
*** 204,210 ****
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  
  (defun facep (face)
!   "Return non-nil if FACE is a face name."
    (internal-lisp-face-p face))
  
  
--- 204,213 ----
  ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
  
  (defun facep (face)
!   "Return non-nil if FACE is a face name or internal face object.
! Return nil otherwise.  A face name can be a string or a symbol.
! An internal face object is a vector of the kind used internally
! to record face data."
    (internal-lisp-face-p face))
  
  
============================================================

===File ~/display.texi-diff=================================
*** display.texi	23 Jun 2005 20:49:48 -0500	1.169
--- display.texi	24 Jun 2005 14:00:28 -0500	
***************
*** 1628,1639 ****
  @cindex face id
  Each face has its own @dfn{face number}, which distinguishes faces at
  low levels within Emacs.  However, for most purposes, you refer to
! faces in Lisp programs by their names.
  
  @defun facep object
! This function returns @code{t} if @var{object} is a face name symbol (or
! if it is a vector of the kind used internally to record face data).  It
! returns @code{nil} otherwise.
  @end defun
  
  Each face name is meaningful for all frames, and by default it has the
--- 1628,1639 ----
  @cindex face id
  Each face has its own @dfn{face number}, which distinguishes faces at
  low levels within Emacs.  However, for most purposes, you refer to
! faces in Lisp programs by the symbol that names them.
  
  @defun facep object
! This function returns @code{t} if @var{object} is a face name string
! or symbol (or if it is a vector of the kind used internally to record
! face data).  It returns @code{nil} otherwise.
  @end defun
  
  Each face name is meaningful for all frames, and by default it has the
============================================================

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Miles Bader]

On 6/25/05, Luc Teirlinck <teirllm@dms.auburn.edu> wrote:
>    I tend to think of datatypes in lisp as being disjoint categories of
>    values; a value can only every have one datatype.
> 
> It can only have one _primitive_ data type (returned by type-of), but
> it can have tons of data types.  See `(elisp)Lisp Data Types' and
> `(elisp)Type Predicates'.

Man, did any of you guys read past the 1st paragraph of my message...?

The most important of a datatype, I think, is that it's a property of
the _value_, which is not really true of faces etc.

-Miles
-- 
Do not taunt Happy Fun Ball.

Re: datatypes in Elisp Info: mention "things" for which there is no "thing" datatype - e.g. faces

[Richard M. Stallman]

    > My memory doesn't recall any others, but I wouldn't want to rely on it.
    > What others do you know of?

    coding-system, charset, fontset?

It would be useful to have brief information about all of these,
in that chapter.  It doesn't need to say much, and perhaps these
all work the same way, so a single section could describe them all.