[DOC] About Lisp Data Types

[DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

Lars Ingebrigtsen closed my bug report #49785.

I failed to make it clear that several sentences are difficult to
understand and that the content should be reworked.

Although, I am willing to admit that my presentation was lame.

One can conceive that what is central to apprehend the functioning of a
Lisp program is the “printed representation” because this one
distinguishes itself from the “read syntax” at the source level and
tries to evoke an instanciated process. Except that the keys to
understanding this are missing.
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Eli Zaretskii]

> Date: Sun, 01 Aug 2021 11:20:16 +0200
> From:  Kevin Vigouroux via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> Lars Ingebrigtsen closed my bug report #49785.
> 
> I failed to make it clear that several sentences are difficult to
> understand and that the content should be reworked.
> 
> Although, I am willing to admit that my presentation was lame.
> 
> One can conceive that what is central to apprehend the functioning of a
> Lisp program is the “printed representation” because this one
> distinguishes itself from the “read syntax” at the source level and
> tries to evoke an instanciated process. Except that the keys to
> understanding this are missing.

FWIW, I, like Lars, couldn't understand what was unclear about the
description in the manual.  It sounds crystal clear to me.

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

I think the structure of the text is a bit shaky especially for the
convergence with the textual representation. Let's go over it again.

    Throughout this manual, the phrases “the Lisp reader” and “the Lisp
    printer” refer to those routines in Lisp that convert textual
    representations of Lisp objects into actual Lisp objects, and vice
    versa.  *Note Printed Representation, for more details.

The first statement is confusing. Does the “Lisp reader” manage the
textual representation in some way? Different meanings are mixed
together and can no longer be differentiated: the objects manipulated by
Emacs Lisp, the Lisp program (read ⇆ eval), the source code (syntax).
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Arthur Miller]

Kevin Vigouroux via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> I think the structure of the text is a bit shaky especially for the
> convergence with the textual representation. Let's go over it again.
>
>     Throughout this manual, the phrases “the Lisp reader” and “the Lisp
>     printer” refer to those routines in Lisp that convert textual
>     representations of Lisp objects into actual Lisp objects, and vice
>     versa.  *Note Printed Representation, for more details.
>
> The first statement is confusing. Does the “Lisp reader” manage the
> textual representation in some way?

Yes. It converts the textual representation, which is the source code,
into objects in Emacs memory which can be used by Emacs when you do the
computations that code is meant to carry out. "those routines" refer to
function(s) in Emacs that convert source code into Lisp objects in
memory and vice versa. I think it is quite clear in the text.

>                                     Different meanings are mixed
> together and can no longer be differentiated

Not at all, that paragraphs is explicin on what is meant with ceratin
two phrases. I am not sure how could you make it more explicit. Compare
to a math definition: We denote set or real numbers with R. Same there.

>                                               the objects manipulated by
> Emacs Lisp, the Lisp program (read ⇆ eval), the source code (syntax).

The source code is not same as syntax. Syntax is a textual form in which
source code is written. Source code is the text specifying what computer
should do, written according to some syntatic and semantic rules. Emacs
Lisp is a name of programming language Emacs understand and which you
can use to write your own computation which Emacs executable can carry
on. The Lisp program in Emacs case, is any of such programs written in
that lanugage that you feed into Emacs, either by reading in a source
file, evaluating a bufer in Emacs, or just even just a symbolic
expression via M-: etc.

I hope it helps a bit. 

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

Yes, I'll give you that, but you didn't quite get what I meant or the
whole point.

The expression “... and vice versa” implies that a conversion is
performed but the Lisp objects normally remain as is. One conversion is
really done by Emacs Lisp (Lisp reader) but the other one makes sense
for the mind (Lisp printer) ; it is not commutative.

What I am trying to say is that we have the common syntax, expression,
and evaluation, but without the thought process.
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Arthur Miller]

Kevin Vigouroux via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Yes, I'll give you that, but you didn't quite get what I meant or the
> whole point.
>
> The expression “... and vice versa” implies that a conversion is
> performed but the Lisp objects normally remain as is. One conversion is
> really done by Emacs Lisp (Lisp reader) but the other one makes sense
> for the mind (Lisp printer) ; it is not commutative.

No, lisp printer prints actual lisp objects to strings. Which you can
even read back with lisp reader :). So it's  not just "in mind", if I
understand correctly what you mean. Docs says explicitly what lisp
reader and printer refers to, nothing is left to imagination, docs are
perfectly clear in that regard.

> What I am trying to say is that we have the common syntax, expression,
> and evaluation, but without the thought process.

I am not sure what do you thing with "but without the thought
process". Some people indeed avoid to use their brains, but I guess that
is not what you mean? :). Just kidding, I don't understand what you
mean there.

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

In this case, I would recommend you to take a look at the Elisp manual.
See [[info:elisp#Output Functions]].

It may sound silly but how can the beginner know everything? By
guessing, of course: good luck!
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Eli Zaretskii]

> Date: Sun, 01 Aug 2021 17:54:09 +0200
> From:  Kevin Vigouroux via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
> In this case, I would recommend you to take a look at the Elisp manual.
> See [[info:elisp#Output Functions]].
> 
> It may sound silly but how can the beginner know everything? By
> guessing, of course: good luck!

The ELisp manual is not for the beginners; we have the Introduction to
Programming in Emacs Lisp for that.  The ELisp manual is the reference
manual for the Emacs Lisp language and its use for extending Emacs.

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 01 Aug 2021 17:54:09 +0200
>> From:  Kevin Vigouroux via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
>> 
>> In this case, I would recommend you to take a look at the Elisp manual.
>> See [[info:elisp#Output Functions]].
>> 
>> It may sound silly but how can the beginner know everything? By
>> guessing, of course: good luck!
>
> The ELisp manual is not for the beginners; we have the Introduction to
> Programming in Emacs Lisp for that.  The ELisp manual is the reference
> manual for the Emacs Lisp language and its use for extending Emacs.
>
>

It's a matter of perspective. Personally, I couldn't continue reading
the Emacs manual because I couldn't understand the numerous references
to Elisp. And the tutorial I did not adhere to, and believe it or not,
the Emacs Lisp reference manual finally did the trick.
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Stefan Monnier via Users list for the GNU Emacs text editor]

> It's a matter of perspective. Personally, I couldn't continue reading
> the Emacs manual because I couldn't understand the numerous references
> to Elisp. And the tutorial I did not adhere to, and believe it or not,
> the Emacs Lisp reference manual finally did the trick.

The problem you described seemed to be around understanding one of the
core ideas of Lisp, whereas the ELisp reference manual doesn't really
aim to teach Lisp.  Maybe the elisp-intro manual gives a more
approachable presentation?


        Stefan

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

The introductory text about the Lisp data types and the “printed
representation” mentions the concepts, but these are not well presented.

After that, you are free to ignore the problem. Besides, it's not my
problem anymore since I already perceive the process.
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

Kevin Vigouroux via Users list for the GNU Emacs text editor wrote:

> In this case, I would recommend you to take a look at the
> Elisp manual. See [[info:elisp#Output Functions]].

Uhm, that's invalid read syntax, you mean this

  (info "(elisp) Output Functions")

?

> It may sound silly but how can the beginner know everything?
> By guessing, of course: good luck!

How can some experienced people be lame despite their
experience? Because their experience consists of being lame...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

This is not a sample code but a hyperlink: see section 19.5 Output
Function in the Emacs Lisp Reference Manual.
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

Kevin Vigouroux via Users list for the GNU Emacs text editor wrote:

> One can conceive that what is central to apprehend the
> functioning of a Lisp program is the "printed
> representation" because this one distinguishes itself from
> the "read syntax" at the source level and tries to evoke an
> instanciated process.

Why is that so difficult to understand?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

The Elisp type system is dynamic which means type checking is
done at run-time. The type is associated with the value,
not the variable.

I guess it is as easy as the type is determined by the syntax
of the input/return value?

E.g., lists:

  (list 'x 'y 'z)
  '(x y z)
  `(x ,@'(y z))

strings:

  "aaa"
  (make-string 3 ?a)

characters:

  ?a
  97

vectors:

  (vector 1 2 3)
  [1 2 3]

and so on - or am I wrong?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

I agree with you. Unfortunately, some parts of the explanation are
unclear or missing.

    In other languages, an expression is text; it has no other form.  In
    Lisp, an expression is primarily a Lisp object and only secondarily the
    text that is the object’s read syntax.  Often there is no need to
    emphasize this distinction, but you must keep it in the back of your
    mind, or you will occasionally be very confused.

• An expression is a Lisp object which gives its meaning.
• An expression cannot be understood in its original form (text).

It makes no sense at first.
-- 
Best regards,
Kevin Vigouroux

Re: [DOC] About Lisp Data Types

[tomas]

[-- Attachment #1: Type: text/plain, Size: 1768 bytes --]

On Sun, Aug 01, 2021 at 03:00:16PM +0200, Kevin Vigouroux via Users list for the GNU Emacs text editor wrote:
> I agree with you. Unfortunately, some parts of the explanation are
> unclear or missing.
> 
>     In other languages, an expression is text; it has no other form.  In
>     Lisp, an expression is primarily a Lisp object and only secondarily the
>     text that is the object’s read syntax.  Often there is no need to
>     emphasize this distinction, but you must keep it in the back of your
>     mind, or you will occasionally be very confused.
> 
> • An expression is a Lisp object which gives its meaning.

Well, not really. An expression is something abstract. It can be
represented as a Lisp object. So the expression

  (+ 12 x)

is represented by the list

  ('+ 12 'x)

(now let's gloss over the fact that '+ is just a shorthand for (quote +)
and so on)

So a list of the symbol +, the number 12 and the symbol x.

An expression can be evaluated: then it corresponds to a value. The
value falling out from that evaluation depends on things (for the
example above, it will depend on the current values assigned to +
and x).

> • An expression cannot be understood in its original form (text).

I don't understand what you want to say here: cannot be understood
by whom? A person? A computer program? Which one?

> It makes no sense at first.

If you show me a piece of Hindi text written in Devanagari, I'll
be unable to make heads or tails of it. But this is due to my
lack of culture, not to the writing or language themselves.

This sounds like a stupid remark, but what I want to hint at is,
that if you don't specify context, it is difficult to understand
what you are after.

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

tomas wrote:

>> It makes no sense at first.
>
> If you show me a piece of Hindi text written in Devanagari,
> I'll be unable to make heads or tails of it. But this is due
> to my lack of culture, not to the writing or
> language themselves.

The parts that the OP has quoted are really poor, I agree
with him.

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Arthur Miller]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> tomas wrote:
>
>>> It makes no sense at first.
>>
>> If you show me a piece of Hindi text written in Devanagari,
>> I'll be unable to make heads or tails of it. But this is due
>> to my lack of culture, not to the writing or
>> language themselves.
>
> The parts that the OP has quoted are really poor, I agree
> with him.

Njah. This is time to get the Dragon book and read it cover to cover
.... just kidding. Chapter 1. introduction would be enough.

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

Arthur Miller wrote:

>> The parts that the OP has quoted are really poor, I agree
>> with him.
>
> Njah. This is time to get the Dragon book and read it cover
> to cover .... just kidding. Chapter 1. introduction would
> be enough.

It should offer precise definitions of every term it
introduces instead of speaking of what something is
"primarily" and "only secondarily" compared to "other
languages" while theorizing what distinctions one "needs to
emphasize" and what to keep "in the back of one's mind".

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Arthur Miller]

Emanuel Berg via Users list for the GNU Emacs text editor
<help-gnu-emacs@gnu.org> writes:

> Arthur Miller wrote:
>
>>> The parts that the OP has quoted are really poor, I agree
>>> with him.
>>
>> Njah. This is time to get the Dragon book and read it cover
>> to cover .... just kidding. Chapter 1. introduction would
>> be enough.
>
> It should offer precise definitions of every term it
> introduces

We are in agreement about that one, but probably not abouot what is
unclear :).

>            instead of speaking of what something is
> "primarily" and "only secondarily" compared to "other
> languages" while theorizing what distinctions one "needs to
> emphasize" and what to keep "in the back of one's mind".

On serious side, you can't have every word in a text go to some precise
defintion. Those terms are phrases and they have their own idiomatic
meaning in this context. So is in every text. Consider for example word
"björnstjänst" and it's explanation on Wikipedia:

https://sv.wikipedia.org/wiki/Bj%C3%B6rntj%C3%A4nst

Will you ask wikipedia authors to precisely define what they mean with
"välmenad tjänst", "eller i varje fall", or some other part of text not
explicitly explained in the article? Probably not because you are well
aware of what those phrases mean from everyday language. So is with the
manual too; some phrases have to be understood from the context, or form
the everyday language etc. Otherwise manual should be a set of axiomatic
rules expressed in concise mathematical language (isn't Lisp itself such
by the way?). Anyway good luck reading such manual :).

Re: [DOC] About Lisp Data Types

[Jean-Christophe Helary]

> On Aug 1, 2021, at 22:00, Kevin Vigouroux via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org> wrote:
> 
> I agree with you. Unfortunately, some parts of the explanation are
> unclear or missing.
> 
>    In other languages, an expression is text; it has no other form.  In
>    Lisp, an expression is primarily a Lisp object and only secondarily the
>    text that is the object’s read syntax.  Often there is no need to
>    emphasize this distinction, but you must keep it in the back of your
>    mind, or you will occasionally be very confused.
> 
> • An expression is a Lisp object which gives its meaning.
> • An expression cannot be understood in its original form (text).
> 
> It makes no sense at first.

It looks like what you find confusing is the co-existence of a textual representation of a "thing" and the thing itself. It helped me to read the 2nd chapter of Ansi Common Lisp by Paul Graham to understand that part of Lisp.

Page 22 of the introduction to programming in elisp (2.2 Getting Buffers) uses the same code as the one you refer to here in that part of the Elisp reference but goes deeper into explanations between the difference between a name and the thing it names.

-- 
Jean-Christophe Helary @brandelune
https://mac4translators.blogspot.com
https://sr.ht/~brandelune/omegat-as-a-book/

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

Jean-Christophe Helary wrote:

> It looks like what you find confusing is the co-existence of
> a textual representation of a "thing" and the thing itself.
> It helped me to read the 2nd chapter of Ansi Common Lisp by
> Paul Graham to understand that part of Lisp.
>
> Page 22 of the introduction to programming in elisp (2.2
> Getting Buffers) uses the same code as the one you refer to
> here in that part of the Elisp reference but goes deeper
> into explanations between the difference between a name and
> the thing it names.

What are you guys talking about?

Isn't it just source and the runtime instances which are the
result of the source, evaluated?

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

Kevin Vigouroux via Users list for the GNU Emacs text editor wrote:

> I agree with you. Unfortunately, some parts of the
> explanation are unclear or missing.
>
>     In other languages, an expression is text; it has no
>     other form.

Actually I agree this isn't clear, in C there are for example
expressions that can be simplified to a single value by the
human and also evaluated to that value by the compiler. So on
the contrary arguably it has several "forms" within its
textualness but also in terms of before/after evaluation.

Also "In other languages" is very inexact, what languages are
those if I may? Because there are so many languages that does
anything and everything in so many different ways.

>     In Lisp, an expression is primarily a Lisp object and
>     only secondarily the text that is the object’s read
>     syntax.

Why primarily one thing and "only secondarily" something else?
If it is both, isn't it one thing as much as the other?

Also, isn't it just source and syntax - in Lisp, parenthesized
lists AKA s-expressions - that evaluates to Lisp objects -
that in turn can be expressed as, and evaluates to, source and
syntax, i.e. parenthesized lists AKA s-expressions?

Isn't the object just the run time instance of static source,
an s-expression, that has been evaluated during the execution
of the program?

> Often there is no need to emphasize this distinction, but
> you must keep it in the back of your mind, or you will
> occasionally be very confused.

Better to provide clear definitions:

  1. s-expression = ...
  2. Lisp object = ...
  3. read syntax = ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Emanuel Berg via Users list for the GNU Emacs text editor]

> Actually I agree this isn't clear, in C there are for
> example expressions that can be simplified to a single value
> by the human and also evaluated to that value by the
> compiler. So on the contrary arguably it has several "forms"
> within its textualness but also in terms of
> before/after evaluation.

By the compiler or more commonly during run time perhaps ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [DOC] About Lisp Data Types

[Eli Zaretskii]

> Date: Sun, 01 Aug 2021 15:00:16 +0200
> From:  Kevin Vigouroux via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
> 
>     In other languages, an expression is text; it has no other form.  In
>     Lisp, an expression is primarily a Lisp object and only secondarily the
>     text that is the object’s read syntax.  Often there is no need to
>     emphasize this distinction, but you must keep it in the back of your
>     mind, or you will occasionally be very confused.
> 
> • An expression is a Lisp object which gives its meaning.
> • An expression cannot be understood in its original form (text).
> 
> It makes no sense at first.

If you read the manual's text for what it is, it makes perfect sense.
The two bullets are your own, they are not in the text.

Re: [DOC] About Lisp Data Types

[Kevin Vigouroux via Users list for the GNU Emacs text editor]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 01 Aug 2021 15:00:16 +0200
>> From:  Kevin Vigouroux via Users list for the GNU Emacs text editor <help-gnu-emacs@gnu.org>
>> 
>>     In other languages, an expression is text; it has no other form.  In
>>     Lisp, an expression is primarily a Lisp object and only secondarily the
>>     text that is the object’s read syntax.  Often there is no need to
>>     emphasize this distinction, but you must keep it in the back of your
>>     mind, or you will occasionally be very confused.
>> 
>> • An expression is a Lisp object which gives its meaning.
>> • An expression cannot be understood in its original form (text).
>> 
>> It makes no sense at first.
>
> If you read the manual's text for what it is, it makes perfect sense.
> The two bullets are your own, they are not in the text.
>

I'm just trying to give my feedback as recommended in the Elisp manual.
But on the other hand, rewriting the text can become difficult.
-- 
Best regards,
Kevin Vigouroux