all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
@ 2022-09-18 16:13 Eli Zaretskii
  2022-09-19  6:16 ` Michael Heerdegen
  0 siblings, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-18 16:13 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

> +(defun gv-synthetic-place (getter setter)
>    "Special place described by its setter and getter.
>  GETTER and SETTER (typically obtained via `gv-letplace') get and
> -set that place.  I.e. This macro allows you to do the \"reverse\" of what
> -`gv-letplace' does.
> -This macro only makes sense when used in a place."
> -  (declare (gv-expander funcall))
> +set that place.  I.e. this function allows you to do the
> +\"reverse\" of what `gv-letplace' does.  This function only makes
> +sense when used in a place."

The last sentence makes no sense.  (Yes, it was in the original doc
string, but it would be a good idea to fix that while making changes
in this area.)



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-18 16:13 master baf1a7a4a0: Turn gv-synthetic-place into a function Eli Zaretskii
@ 2022-09-19  6:16 ` Michael Heerdegen
  2022-09-19 11:38   ` Eli Zaretskii
  2022-09-19 12:06   ` Stefan Monnier
  0 siblings, 2 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-19  6:16 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> > +set that place.  I.e. this function allows you to do the
> > +\"reverse\" of what `gv-letplace' does.  This function only makes
> > +sense when used in a place."
>
> The last sentence makes no sense. [...]

Hmm - to me it is clear, so I need to speculate what is needed to make
it better.  Something like

  "This function is only useful in place expressions."

maybe?

Michael.




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-19  6:16 ` Michael Heerdegen
@ 2022-09-19 11:38   ` Eli Zaretskii
  2022-09-20  7:28     ` Michael Heerdegen
  2022-09-19 12:06   ` Stefan Monnier
  1 sibling, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-19 11:38 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Mon, 19 Sep 2022 08:16:18 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > +set that place.  I.e. this function allows you to do the
> > > +\"reverse\" of what `gv-letplace' does.  This function only makes
> > > +sense when used in a place."
> >
> > The last sentence makes no sense. [...]
> 
> Hmm - to me it is clear, so I need to speculate what is needed to make
> it better.  Something like
> 
>   "This function is only useful in place expressions."
> 
> maybe?

Thanks, this is better.  However, we don't have "place expression"
anywhere in the manual (unless I missed something), we have "place
form".  Is this the same?  And if this is the same, how about

  This function is only useful when used with generalized variables.

?



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-19  6:16 ` Michael Heerdegen
  2022-09-19 11:38   ` Eli Zaretskii
@ 2022-09-19 12:06   ` Stefan Monnier
  2022-09-20  7:22     ` Michael Heerdegen
  1 sibling, 1 reply; 42+ messages in thread
From: Stefan Monnier @ 2022-09-19 12:06 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

Michael Heerdegen [2022-09-19 08:16:18] wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>> > +set that place.  I.e. this function allows you to do the
>> > +\"reverse\" of what `gv-letplace' does.  This function only makes
>> > +sense when used in a place."
>>
>> The last sentence makes no sense. [...]
>
> Hmm - to me it is clear, so I need to speculate what is needed to make
> it better.  Something like
>
>   "This function is only useful in place expressions."
>
> maybe?

Or maybe the "in a place" should just be changed to "as a place"?


        Stefan




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-19 12:06   ` Stefan Monnier
@ 2022-09-20  7:22     ` Michael Heerdegen
  0 siblings, 0 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-20  7:22 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> >   "This function is only useful in place expressions."
> >
> > maybe?
>
> Or maybe the "in a place" should just be changed to "as a place"?

I would prefer the original version to this suggestion.  I don't like
calling a function a place or generalized variable, or that it can be
used "as" such.  The proposition "in" seems technically more adequate to
me.

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-19 11:38   ` Eli Zaretskii
@ 2022-09-20  7:28     ` Michael Heerdegen
  2022-09-20  7:50       ` Emanuel Berg
  2022-09-20 11:19       ` Eli Zaretskii
  0 siblings, 2 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-20  7:28 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> > Hmm - to me it is clear, so I need to speculate what is needed to make
> > it better.  Something like
> >
> >   "This function is only useful in place expressions."
> >
> > maybe?
>
> Thanks, this is better.  However, we don't have "place expression"
> anywhere in the manual (unless I missed something), we have "place
> form".  Is this the same?

I think we are still aiming at good wording to describe the usage of
generalized variables.  Personally, I use "place expression" and "place
form" as synonyms, since expression and form are synonymous.

>  And if this is the same, how about
>
>   This function is only useful when used with generalized variables.

I prefer the preposition "in" to "with" which sounds more vague to me.

Also, some people seem to like saying a function "is" a generalized
variable when it has a gv setter.  I'm not sure if they would read your
version as intended.

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20  7:28     ` Michael Heerdegen
@ 2022-09-20  7:50       ` Emanuel Berg
  2022-09-20 11:19       ` Eli Zaretskii
  1 sibling, 0 replies; 42+ messages in thread
From: Emanuel Berg @ 2022-09-20  7:50 UTC (permalink / raw)
  To: emacs-devel

Michael Heerdegen wrote:

>> And if this is the same, how about
>>
>>   This function is only useful when used with
>>   generalized variables.
>
> I prefer the preposition "in" to "with" which sounds more
> vague to me.

You use functions in variables now?

But then where are the variables?

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




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20  7:28     ` Michael Heerdegen
  2022-09-20  7:50       ` Emanuel Berg
@ 2022-09-20 11:19       ` Eli Zaretskii
  2022-09-20 14:36         ` Michael Heerdegen
  1 sibling, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-20 11:19 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 20 Sep 2022 09:28:59 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > Hmm - to me it is clear, so I need to speculate what is needed to make
> > > it better.  Something like
> > >
> > >   "This function is only useful in place expressions."
> > >
> > > maybe?
> >
> > Thanks, this is better.  However, we don't have "place expression"
> > anywhere in the manual (unless I missed something), we have "place
> > form".  Is this the same?
> 
> I think we are still aiming at good wording to describe the usage of
> generalized variables.  Personally, I use "place expression" and "place
> form" as synonyms, since expression and form are synonymous.

So saying "place forms" would be preferable from my POV, since we use
that in the manual, and it is even indexed.  Which means users can
easily find the description of that term if they need.

> >  And if this is the same, how about
> >
> >   This function is only useful when used with generalized variables.
> 
> I prefer the preposition "in" to "with" which sounds more vague to me.

What does it mean to "use a function in generalized variables"? how do
you use a function _in_ a variable?

> Also, some people seem to like saying a function "is" a generalized
> variable when it has a gv setter.  I'm not sure if they would read your
> version as intended.

Why not?  For me, using something "with" something else means "in
conjunction with".  Does the latter also sound problematic to you (and
if so, why)?  If not, maybe having "in conjunction with" could solve
the issue?



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20 11:19       ` Eli Zaretskii
@ 2022-09-20 14:36         ` Michael Heerdegen
  2022-09-20 16:27           ` Eli Zaretskii
  2022-09-21  8:32           ` Emanuel Berg
  0 siblings, 2 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-20 14:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> > >  And if this is the same, how about
> > >
> > >   This function is only useful when used with generalized variables.
> >
> > I prefer the preposition "in" to "with" which sounds more vague to me.
>
> What does it mean to "use a function in generalized variables"? how do
> you use a function _in_ a variable?

A generalized variable is a place (form).  You use a function in a place
form like you use it in any (normal) form.  Just the semantics are
different.  Like in

  (car (gv-synthetic-place ...))

> > Also, some people seem to like saying a function "is" a generalized
> > variable when it has a gv setter.  I'm not sure if they would read your
> > version as intended.
>
> Why not?  For me, using something "with" something else means "in
> conjunction with".  Does the latter also sound problematic to you (and
> if so, why)?  If not, maybe having "in conjunction with" could solve
> the issue?

I just find "in" more precise: The function (call) is an integral part
of the place form, so it's "in" it, textually or syntactically.

English is not my first language, so I hope I'm not on a wrong track,
but for me "in" sounds more appropriate.
If a user reads "in conjunction with" and doesn't know much about
generalized variables, she might wonder "Ok, and how?  Can I pass
generalized variables as arguments?".  The relation is not as clear as
with "in" IMO.

I hope you can follow my concerns.  Does it make sense to you?  I want
to find a wording that potentially leads to as few misinterpretations as
possible.

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20 14:36         ` Michael Heerdegen
@ 2022-09-20 16:27           ` Eli Zaretskii
  2022-09-21  5:40             ` Michael Heerdegen
  2022-09-21  8:35             ` Emanuel Berg
  2022-09-21  8:32           ` Emanuel Berg
  1 sibling, 2 replies; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-20 16:27 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Tue, 20 Sep 2022 16:36:55 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > > >  And if this is the same, how about
> > > >
> > > >   This function is only useful when used with generalized variables.
> > >
> > > I prefer the preposition "in" to "with" which sounds more vague to me.
> >
> > What does it mean to "use a function in generalized variables"? how do
> > you use a function _in_ a variable?
> 
> A generalized variable is a place (form).  You use a function in a place
> form like you use it in any (normal) form.

"Use in a place form" and "use in a place" are very different.  The
former can be understood and interpreted; the latter is just
confusing, because it uses "place", a common word, in a meaning that
is completely removed from the "usual" one.  I asked you about the
meaning of the former, not the latter.

> > > Also, some people seem to like saying a function "is" a generalized
> > > variable when it has a gv setter.  I'm not sure if they would read your
> > > version as intended.
> >
> > Why not?  For me, using something "with" something else means "in
> > conjunction with".  Does the latter also sound problematic to you (and
> > if so, why)?  If not, maybe having "in conjunction with" could solve
> > the issue?
> 
> I just find "in" more precise: The function (call) is an integral part
> of the place form, so it's "in" it, textually or syntactically.

Its precision matters much less when this stuff is read for the first
time, by someone who doesn't yet understand well enough what is this
about.  What matters then is our ability to explain what we mean
without confusing.

> English is not my first language, so I hope I'm not on a wrong track,
> but for me "in" sounds more appropriate.
> If a user reads "in conjunction with" and doesn't know much about
> generalized variables, she might wonder "Ok, and how?  Can I pass
> generalized variables as arguments?".  The relation is not as clear as
> with "in" IMO.
> 
> I hope you can follow my concerns.  Does it make sense to you?  I want
> to find a wording that potentially leads to as few misinterpretations as
> possible.

How about the below?

  This function is only useful when used in conjunction with
  generalized variables in place forms.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20 16:27           ` Eli Zaretskii
@ 2022-09-21  5:40             ` Michael Heerdegen
  2022-09-21 14:19               ` Eli Zaretskii
  2022-09-21  8:35             ` Emanuel Berg
  1 sibling, 1 reply; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-21  5:40 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> How about the below?
>
>   This function is only useful when used in conjunction with
>   generalized variables in place forms.

After reading it a couple of times I think it's fine.

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20 14:36         ` Michael Heerdegen
  2022-09-20 16:27           ` Eli Zaretskii
@ 2022-09-21  8:32           ` Emanuel Berg
  2022-09-21 13:52             ` Michael Heerdegen
  1 sibling, 1 reply; 42+ messages in thread
From: Emanuel Berg @ 2022-09-21  8:32 UTC (permalink / raw)
  To: emacs-devel

Michael Heerdegen wrote:

> A generalized variable is a place (form). You use a function
> in a place form like you use it in any (normal) form.
> Just the semantics are different. Like in
>
>   (car (gv-synthetic-place ...))

OK, so we have symbols that have one slot for a/the function
and another for the variable and this is some third
thing then?

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




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-20 16:27           ` Eli Zaretskii
  2022-09-21  5:40             ` Michael Heerdegen
@ 2022-09-21  8:35             ` Emanuel Berg
  1 sibling, 0 replies; 42+ messages in thread
From: Emanuel Berg @ 2022-09-21  8:35 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii wrote:

> "Use in a place form" and "use in a place" are very
> different. The former can be understood and interpreted; the
> latter is just confusing, because it uses "place", a common
> word, in a meaning that is completely removed from the
> "usual" one. I asked you about the meaning of the former,
> not the latter.

How would this be put using established terminology from
related scientific endeavors e.g. CS, math, astro-numerology
and so on?

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




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21  8:32           ` Emanuel Berg
@ 2022-09-21 13:52             ` Michael Heerdegen
  2022-09-21 14:20               ` Stefan Monnier
  0 siblings, 1 reply; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-21 13:52 UTC (permalink / raw)
  To: emacs-devel

Emanuel Berg <incal@dataswamp.org> writes:

> Michael Heerdegen wrote:
>
> > A generalized variable is a place (form). You use a function
> > in a place form like you use it in any (normal) form.
> > Just the semantics are different. Like in
> >
> >   (car (gv-synthetic-place ...))
>
> OK, so we have symbols that have one slot for a/the function
> and another for the variable and this is some third
> thing then?

Not really.  Note that `gv-synthetic-place' is a corner case
construct that is useful mostly as a helper or to implement support for
more common generalized variables.  There are currently 0 uses in Emacs.

For place forms in general: the idea is that the language allows you to wrap
a normal form that describes the place of a value - like e.g.
(car (alist-get ...))) - into `setf' (or any other place macro) and that
magically allows you to modify or bind that value.  With other words: you
abstract over the concepts "getter" and "setter" functions, since they
are mirror images in a larger concept, and get something _simpler_: you
then need to remember less function names and are allowed to write
simpler code.

Place forms are like normal forms, but only forms that describe the
place of a value and have support as generalized variables are valid as
place forms.  The semantics are different of course since they are not
exactly evaluated like normal Lisp.  They are transformed before
evaluation happens, but that is something very common in Lisp.  Lisp
programmers are used to the fact that not every list in a Lisp program
is evaluated in the standard way.  Think of arguments macros and special
forms.  Not everything is an expression. (1 2) in '(1 2) is not an
expression meant for evaluation, for example.

For place forms you even don't have to learn new syntax.  There is no
additional third thing where stuff is stored...so I would say my
answer to your question is "no".

Please don't get distracted by the discussion of this internal corner
case thing.

Michael.




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21  5:40             ` Michael Heerdegen
@ 2022-09-21 14:19               ` Eli Zaretskii
  0 siblings, 0 replies; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-21 14:19 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: emacs-devel@gnu.org
> Date: Wed, 21 Sep 2022 07:40:12 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > How about the below?
> >
> >   This function is only useful when used in conjunction with
> >   generalized variables in place forms.
> 
> After reading it a couple of times I think it's fine.

Thanks, installed.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 13:52             ` Michael Heerdegen
@ 2022-09-21 14:20               ` Stefan Monnier
  2022-09-21 15:31                 ` Eli Zaretskii
  2022-09-30 23:30                 ` Emanuel Berg
  0 siblings, 2 replies; 42+ messages in thread
From: Stefan Monnier @ 2022-09-21 14:20 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

While `gv-` is a handy short prefix, maybe we should stop using terms
like "place" and "generalized variables" and call them "lvalues" like
the rest of the world.


        Stefan




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 14:20               ` Stefan Monnier
@ 2022-09-21 15:31                 ` Eli Zaretskii
  2022-09-21 16:14                   ` Stefan Monnier
  2022-09-30 23:30                 ` Emanuel Berg
  1 sibling, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-21 15:31 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: michael_heerdegen, emacs-devel

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: emacs-devel@gnu.org
> Date: Wed, 21 Sep 2022 10:20:24 -0400
> 
> While `gv-` is a handy short prefix, maybe we should stop using terms
> like "place" and "generalized variables" and call them "lvalues" like
> the rest of the world.

Would people without background in language parsing understand the
terminology?  If not, lvalue is not better than what we already use.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 15:31                 ` Eli Zaretskii
@ 2022-09-21 16:14                   ` Stefan Monnier
  2022-09-22 10:47                     ` Lars Ingebrigtsen
                                       ` (2 more replies)
  0 siblings, 3 replies; 42+ messages in thread
From: Stefan Monnier @ 2022-09-21 16:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-devel

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 21 Sep 2022 10:20:24 -0400
>> 
>> While `gv-` is a handy short prefix, maybe we should stop using terms
>> like "place" and "generalized variables" and call them "lvalues" like
>> the rest of the world.
>
> Would people without background in language parsing understand the
> terminology?  If not, lvalue is not better than what we already use.

It has some advantages, tho:
- I think the vast majority of those who are familiar with generalized
  variables know the "lvalue" term as well, so there is not much loss.
- A non-negligible number of people who don't know "place" or
  "generalized variables" have heard to word "lvalue" in one course
  or another.
- "lvalue" is known to Wikipedia, contrary to "generalized variables".
- "lvalue" is shorter than "generalized variables".
- "lvalue" is obviously a special term with a technical meaning, contrary
  to "place".

The downside I can see (beside the obvious churn) is that the
explanation of lvalue in Wikipedia might prove more confusing
than helful.


        Stefan




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 16:14                   ` Stefan Monnier
@ 2022-09-22 10:47                     ` Lars Ingebrigtsen
  2022-09-22 11:53                       ` Michael Heerdegen
                                         ` (2 more replies)
  2022-09-22 10:56                     ` Michael Heerdegen
  2022-09-30 23:18                     ` Emanuel Berg
  2 siblings, 3 replies; 42+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-22 10:47 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, michael_heerdegen, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It has some advantages, tho:
> - I think the vast majority of those who are familiar with generalized
>   variables know the "lvalue" term as well, so there is not much loss.
> - A non-negligible number of people who don't know "place" or
>   "generalized variables" have heard to word "lvalue" in one course
>   or another.
> - "lvalue" is known to Wikipedia, contrary to "generalized variables".
> - "lvalue" is shorter than "generalized variables".
> - "lvalue" is obviously a special term with a technical meaning, contrary
>   to "place".
>
> The downside I can see (beside the obvious churn) is that the
> explanation of lvalue in Wikipedia might prove more confusing
> than helful.

Yeah, I don't think anybody would find the Wikipedia definition of
"l-value" (which is how they spell it) to be helpful when understanding
Lisp.  And I'm not sure I do either -- in C, for instance, an l-value is
something that can be assigned to, but in Lisp, a generalised variable
is way more abstract, and can do most anything.

(When that "anything" is very weird, we discourage them, but still.)

So I'd rather keep "generalized variable", long and unwieldy as it is.
I think we should avoid "place" as much as possible, though.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 16:14                   ` Stefan Monnier
  2022-09-22 10:47                     ` Lars Ingebrigtsen
@ 2022-09-22 10:56                     ` Michael Heerdegen
  2022-09-30 23:18                     ` Emanuel Berg
  2 siblings, 0 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-22 10:56 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> It has some advantages, tho:
> - I think the vast majority of those who are familiar with generalized
>   variables know the "lvalue" term as well, so there is not much loss.
> - A non-negligible number of people who don't know "place" or
>   "generalized variables" have heard to word "lvalue" in one course
>   or another.
> - "lvalue" is known to Wikipedia, contrary to "generalized variables".
> - "lvalue" is shorter than "generalized variables".
> - "lvalue" is obviously a special term with a technical meaning, contrary
>   to "place".

A downside I see is that what we want to name are not really "values",
the term could be misleading.  Yes, and it would not really help to
explain what it is.  The descriptions I found "in the internet" also
sound a bit more "meta" and less concrete than our wording and
terminology.  Just my subjective impression.

I see that the term "lvalue" is already used in
(info "(elisp) Generalized Variables") to capture those who already know
that term.  In sum for me it's good as it is.

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 10:47                     ` Lars Ingebrigtsen
@ 2022-09-22 11:53                       ` Michael Heerdegen
  2022-09-22 14:27                         ` Michael Heerdegen
                                           ` (2 more replies)
  2022-09-22 12:26                       ` Yuri Khan
  2022-09-22 14:11                       ` Howard Melman
  2 siblings, 3 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-22 11:53 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I'd rather keep "generalized variable", long and unwieldy as it is.
> I think we should avoid "place" as much as possible, though.

Including "place form"?

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 10:47                     ` Lars Ingebrigtsen
  2022-09-22 11:53                       ` Michael Heerdegen
@ 2022-09-22 12:26                       ` Yuri Khan
  2022-09-22 14:11                       ` Howard Melman
  2 siblings, 0 replies; 42+ messages in thread
From: Yuri Khan @ 2022-09-22 12:26 UTC (permalink / raw)
  To: Lars Ingebrigtsen
  Cc: Stefan Monnier, Eli Zaretskii, michael_heerdegen, emacs-devel

On Thu, 22 Sept 2022 at 18:11, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Yeah, I don't think anybody would find the Wikipedia definition of
> "l-value" (which is how they spell it) to be helpful when understanding
> Lisp.  And I'm not sure I do either -- in C, for instance, an l-value is
> something that can be assigned to, but in Lisp, a generalised variable
> is way more abstract, and can do most anything.

Yeah, generalized variables are more like “properties” in Java-like
languages (syntactically an object data member, but behaviorally a
pair of setter and getter functions) or “lenses” in Haskell (read-only
or read-write adapters over a value presenting a different interface).



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 10:47                     ` Lars Ingebrigtsen
  2022-09-22 11:53                       ` Michael Heerdegen
  2022-09-22 12:26                       ` Yuri Khan
@ 2022-09-22 14:11                       ` Howard Melman
  2022-09-22 16:45                         ` Eli Zaretskii
  2 siblings, 1 reply; 42+ messages in thread
From: Howard Melman @ 2022-09-22 14:11 UTC (permalink / raw)
  To: emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I'd rather keep "generalized variable", long and unwieldy as it is.
> I think we should avoid "place" as much as possible, though.

+1

I've written elisp for decades but am not completely
comfortable with the "new" stuff like cl-lib and gv and it
took me a little to wrap my head around setf.

I like the term "Generalized Variable" and would prefer to
see "gv" used instead of "place".

The beginning of the Generalized Variables section of the
elisp manual is fine for me and mostly the sub-section
"12.17.1 The ‘setf’ Macro".  But referring to "the left
side" of a sexp doesn't help me, e.g., "The ‘setf’ form is
like ‘setq’, except that it accepts arbitrary place forms on
the left side rather than just symbols. For example, ‘(setf
(car a) b)’..."  I can follow the rest but I don't think of
"the first argument" to setq as "the left side".

And I think rather than

 -- Macro: setf [place form]...
     This macro evaluates FORM and stores it in PLACE, which must be a
     valid generalized variable form.  If there are several PLACE and
     FORM pairs, the assignments are done sequentially just as with
     ‘setq’.  ‘setf’ returns the value of the last FORM.

I'd prefer

 -- Macro: setf [gv val]...
     This macro evaluates VAL and stores it in GV, which must be a
     valid generalized variable form.  If there are several GV and
     VAL pairs, the assignments are done sequentially just as with
     ‘setq’.  ‘setf’ returns the value of the last VAL.

I find it much easier to process GV as "generalized
variable" rather than "place", as long as each docstring where
I run across GV uses "generalized variable" someplace so I
could look up the term.  I'm less invested in changing
"form" above to "val" but did it for two reasons: it matches
what setq calls its second argument (and the actual setf
docstring) and it doesn't reuse the term "form" which is
used in the description of the first argument.  I'm fine
thinking of lisp forms, but since everything is a form, I'd
rather actually name arguments to differentiate them when
possible. 

Just my $0.02

-- 

Howard




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 11:53                       ` Michael Heerdegen
@ 2022-09-22 14:27                         ` Michael Heerdegen
  2022-09-22 16:30                         ` Augusto Stoffel
  2022-09-23 15:07                         ` Lars Ingebrigtsen
  2 siblings, 0 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-22 14:27 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel

Michael Heerdegen <michael_heerdegen@web.de> writes:

> Including "place form"?

I mean, it also has an advantage: it allows to distinguish between the
"place", the location, of a value (to be referenced or modified), and
the "place form" that describes that location.  The disadvantage is that
the word "place" alone can be misunderstood (as describing a location in
the code, for example).

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 11:53                       ` Michael Heerdegen
  2022-09-22 14:27                         ` Michael Heerdegen
@ 2022-09-22 16:30                         ` Augusto Stoffel
  2022-09-22 17:27                           ` [External] : " Drew Adams
  2022-09-23 15:07                         ` Lars Ingebrigtsen
  2 siblings, 1 reply; 42+ messages in thread
From: Augusto Stoffel @ 2022-09-22 16:30 UTC (permalink / raw)
  To: Michael Heerdegen
  Cc: Lars Ingebrigtsen, Stefan Monnier, Eli Zaretskii, emacs-devel

On Thu, 22 Sep 2022 at 13:53, Michael Heerdegen wrote:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So I'd rather keep "generalized variable", long and unwieldy as it is.
>> I think we should avoid "place" as much as possible, though.
>
> Including "place form"?
>
> Michael.

FWIW, I learned Lisp on the street and I don't think the meaning of
“generalized variable” or “place” is especially hard to guess.  It may
not be obvious for the uninitiated, but there are worse pitfalls.

Perhaps “everybody” learns what an l-value is in their compilers class,
but I find that term pretty opaque.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 14:11                       ` Howard Melman
@ 2022-09-22 16:45                         ` Eli Zaretskii
  2022-09-22 19:55                           ` Howard Melman
  2022-09-23  9:41                           ` Michael Heerdegen
  0 siblings, 2 replies; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-22 16:45 UTC (permalink / raw)
  To: Howard Melman; +Cc: emacs-devel

> From: Howard Melman <hmelman@gmail.com>
> Date: Thu, 22 Sep 2022 10:11:14 -0400
> 
> And I think rather than
> 
>  -- Macro: setf [place form]...
>      This macro evaluates FORM and stores it in PLACE, which must be a
>      valid generalized variable form.  If there are several PLACE and
>      FORM pairs, the assignments are done sequentially just as with
>      ‘setq’.  ‘setf’ returns the value of the last FORM.
> 
> I'd prefer
> 
>  -- Macro: setf [gv val]...
>      This macro evaluates VAL and stores it in GV, which must be a
>      valid generalized variable form.  If there are several GV and
>      VAL pairs, the assignments are done sequentially just as with
>      ‘setq’.  ‘setf’ returns the value of the last VAL.

VAL stands for "value", and talking about "evaluating a value" makes
little sense, IMO.  How about

  This macro evaluates FORM and stores its value in PLACE, ...



^ permalink raw reply	[flat|nested] 42+ messages in thread

* RE: [External] : Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 16:30                         ` Augusto Stoffel
@ 2022-09-22 17:27                           ` Drew Adams
  2022-09-22 17:47                             ` Michael Heerdegen
  0 siblings, 1 reply; 42+ messages in thread
From: Drew Adams @ 2022-09-22 17:27 UTC (permalink / raw)
  To: Augusto Stoffel, Michael Heerdegen
  Cc: Lars Ingebrigtsen, Stefan Monnier, Eli Zaretskii,
	emacs-devel@gnu.org

> FWIW, I learned Lisp on the street 

What street was that? ;-)

> and I don't think the meaning of
> “generalized variable” or “place” is especially hard to guess.  It may
> not be obvious for the uninitiated, but there are worse pitfalls.
> 
> Perhaps “everybody” learns what an l-value is in their compilers class,
> but I find that term pretty opaque.

I agree.  Had to read the Wikipedia page.

If we want to reference something non-Emacs,
maybe CL setf etc. doc is a better touchstone?


^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: [External] : Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 17:27                           ` [External] : " Drew Adams
@ 2022-09-22 17:47                             ` Michael Heerdegen
  0 siblings, 0 replies; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-22 17:47 UTC (permalink / raw)
  To: Drew Adams
  Cc: Augusto Stoffel, Lars Ingebrigtsen, Stefan Monnier, Eli Zaretskii,
	emacs-devel@gnu.org

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

> > Perhaps “everybody” learns what an l-value is in their compilers class,
> > but I find that term pretty opaque.
>
> I agree.  Had to read the Wikipedia page.

Glad to hear I'm not the only one.

Michael.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 16:45                         ` Eli Zaretskii
@ 2022-09-22 19:55                           ` Howard Melman
  2022-09-23  6:19                             ` Eli Zaretskii
  2022-09-23  9:41                           ` Michael Heerdegen
  1 sibling, 1 reply; 42+ messages in thread
From: Howard Melman @ 2022-09-22 19:55 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Howard Melman <hmelman@gmail.com>
>> Date: Thu, 22 Sep 2022 10:11:14 -0400
>> 
>> And I think rather than
>> 
>>  -- Macro: setf [place form]...
>>      This macro evaluates FORM and stores it in PLACE, which must be a
>>      valid generalized variable form.  If there are several PLACE and
>>      FORM pairs, the assignments are done sequentially just as with
>>      ‘setq’.  ‘setf’ returns the value of the last FORM.
>> 
>> I'd prefer
>> 
>>  -- Macro: setf [gv val]...
>>      This macro evaluates VAL and stores it in GV, which must be a
>>      valid generalized variable form.  If there are several GV and
>>      VAL pairs, the assignments are done sequentially just as with
>>      ‘setq’.  ‘setf’ returns the value of the last VAL.
>
> VAL stands for "value", and talking about "evaluating a value" makes
> little sense, IMO.

I mean describe-function on setq (in Emacs 28.2) starts:

    (setq [SYM VAL]...)

    Set each SYM to the value of its VAL.
    The symbols SYM are variables; they are literal (not evaluated).
    The values VAL are expressions; they are evaluated.

I was just following that.

> How about
>
>   This macro evaluates FORM and stores its value in PLACE, ...

It's better.

For me, I'm still not completely clear if "generalized
variable" is exactly the same as "place" and if "generalized
variable form" is the same as "place form".  That's what I'd
like to see clarity on and if they are the same, just use
one term.

-- 

Howard




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 19:55                           ` Howard Melman
@ 2022-09-23  6:19                             ` Eli Zaretskii
  2022-09-23 13:42                               ` Howard Melman
  0 siblings, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-23  6:19 UTC (permalink / raw)
  To: Howard Melman; +Cc: emacs-devel

> From: Howard Melman <hmelman@gmail.com>
> Date: Thu, 22 Sep 2022 15:55:03 -0400
> 
> > How about
> >
> >   This macro evaluates FORM and stores its value in PLACE, ...
> 
> It's better.

OK, thanks.

> For me, I'm still not completely clear if "generalized
> variable" is exactly the same as "place" and if "generalized
> variable form" is the same as "place form".  That's what I'd
> like to see clarity on and if they are the same, just use
> one term.

They are the same thing.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 16:45                         ` Eli Zaretskii
  2022-09-22 19:55                           ` Howard Melman
@ 2022-09-23  9:41                           ` Michael Heerdegen
  2022-09-23 10:53                             ` Eli Zaretskii
  1 sibling, 1 reply; 42+ messages in thread
From: Michael Heerdegen @ 2022-09-23  9:41 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:


> > I'd prefer
> > 
> >  -- Macro: setf [gv val]...
> >      This macro evaluates VAL and stores it in GV, which must be a
> >      valid generalized variable form.  If there are several GV and
> >      VAL pairs, the assignments are done sequentially just as with
> >      ‘setq’.  ‘setf’ returns the value of the last VAL.
>
> VAL stands for "value", and talking about "evaluating a value" makes
> little sense, IMO.

Indeed.

>  How about
>
>   This macro evaluates FORM and stores its value in PLACE, ...

We could also say (a bit more similar to the first sentence of the
`setq' docstring):

  -- Macro: setf [gv val]...
      Set each place described by the generalized variable GV to its VAL.
      ...

Michael.




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23  9:41                           ` Michael Heerdegen
@ 2022-09-23 10:53                             ` Eli Zaretskii
  2022-09-23 17:26                               ` Emanuel Berg
  0 siblings, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-23 10:53 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: emacs-devel

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Date: Fri, 23 Sep 2022 11:41:07 +0200
> 
> >  How about
> >
> >   This macro evaluates FORM and stores its value in PLACE, ...
> 
> We could also say (a bit more similar to the first sentence of the
> `setq' docstring):
> 
>   -- Macro: setf [gv val]...
>       Set each place described by the generalized variable GV to its VAL.
>       ...

Generalized variables don't "describe" places, they _are_ places.

Also, "set a place" has the same problem of conflicting with the
"usual" meaning of the word "place", so it's potentially confusing.

Replacing word by word due to an analogy doesn't always lead to clear
documentation, IME.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23  6:19                             ` Eli Zaretskii
@ 2022-09-23 13:42                               ` Howard Melman
  2022-09-23 15:49                                 ` Stefan Monnier
  2022-09-23 15:54                                 ` Eli Zaretskii
  0 siblings, 2 replies; 42+ messages in thread
From: Howard Melman @ 2022-09-23 13:42 UTC (permalink / raw)
  To: emacs-devel


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Howard Melman <hmelman@gmail.com>
>> Date: Thu, 22 Sep 2022 15:55:03 -0400
>>
>> For me, I'm still not completely clear if "generalized
>> variable" is exactly the same as "place" and if "generalized
>> variable form" is the same as "place form".  That's what I'd
>> like to see clarity on and if they are the same, just use
>> one term.
>
> They are the same thing.

Thanks.

Then I think using just one term is clearer and I agree with
Lars about avoiding "place" as much as possible.  I think GV
would be a clearer parameter name than PLACE.

-- 

Howard




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-22 11:53                       ` Michael Heerdegen
  2022-09-22 14:27                         ` Michael Heerdegen
  2022-09-22 16:30                         ` Augusto Stoffel
@ 2022-09-23 15:07                         ` Lars Ingebrigtsen
  2 siblings, 0 replies; 42+ messages in thread
From: Lars Ingebrigtsen @ 2022-09-23 15:07 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: Stefan Monnier, Eli Zaretskii, emacs-devel

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> So I'd rather keep "generalized variable", long and unwieldy as it is.
>> I think we should avoid "place" as much as possible, though.
>
> Including "place form"?

Yeah, I think "place form" is inscrutable -- people that don't know what
it is may well interpret that as a verb and a noun.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23 13:42                               ` Howard Melman
@ 2022-09-23 15:49                                 ` Stefan Monnier
  2022-09-23 18:05                                   ` Howard Melman
  2022-09-23 15:54                                 ` Eli Zaretskii
  1 sibling, 1 reply; 42+ messages in thread
From: Stefan Monnier @ 2022-09-23 15:49 UTC (permalink / raw)
  To: Howard Melman; +Cc: emacs-devel

> Then I think using just one term is clearer and I agree with
> Lars about avoiding "place" as much as possible.  I think GV
> would be a clearer parameter name than PLACE.

Maybe GVAR is a bit less cryptic, then?


        Stefan




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23 13:42                               ` Howard Melman
  2022-09-23 15:49                                 ` Stefan Monnier
@ 2022-09-23 15:54                                 ` Eli Zaretskii
  2022-09-23 18:11                                   ` Howard Melman
  1 sibling, 1 reply; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-23 15:54 UTC (permalink / raw)
  To: Howard Melman; +Cc: emacs-devel

> From: Howard Melman <hmelman@gmail.com>
> Date: Fri, 23 Sep 2022 09:42:50 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Howard Melman <hmelman@gmail.com>
> >> Date: Thu, 22 Sep 2022 15:55:03 -0400
> >>
> >> For me, I'm still not completely clear if "generalized
> >> variable" is exactly the same as "place" and if "generalized
> >> variable form" is the same as "place form".  That's what I'd
> >> like to see clarity on and if they are the same, just use
> >> one term.
> >
> > They are the same thing.
> 
> Thanks.
> 
> Then I think using just one term is clearer and I agree with
> Lars about avoiding "place" as much as possible.  I think GV
> would be a clearer parameter name than PLACE.

That ship has sailed, unfortunately.  Where were you (and Lars) when
this terminology was introduced and I tried to find some better
alternatives, but was voted down?



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23 10:53                             ` Eli Zaretskii
@ 2022-09-23 17:26                               ` Emanuel Berg
  0 siblings, 0 replies; 42+ messages in thread
From: Emanuel Berg @ 2022-09-23 17:26 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii wrote:

> Generalized variables don't "describe" places, they
> _are_ places.
>
> Also, "set a place" has the same problem of conflicting with
> the "usual" meaning of the word "place", so it's
> potentially confusing.

Again, are we the only one who have this, whatever it is?

If not, how is it usually described?

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




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23 15:49                                 ` Stefan Monnier
@ 2022-09-23 18:05                                   ` Howard Melman
  0 siblings, 0 replies; 42+ messages in thread
From: Howard Melman @ 2022-09-23 18:05 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Then I think using just one term is clearer and I agree with
>> Lars about avoiding "place" as much as possible.  I think GV
>> would be a clearer parameter name than PLACE.
>
> Maybe GVAR is a bit less cryptic, then?

GV has the advantages of being shorter and matching gv.el
and should be clear since docstrings should use "generalized
variable" at least once.

But I'd be fine with GVAR instead.

-- 

Howard




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23 15:54                                 ` Eli Zaretskii
@ 2022-09-23 18:11                                   ` Howard Melman
  2022-09-23 19:00                                     ` Eli Zaretskii
  0 siblings, 1 reply; 42+ messages in thread
From: Howard Melman @ 2022-09-23 18:11 UTC (permalink / raw)
  To: emacs-devel


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Howard Melman <hmelman@gmail.com>
>> Date: Fri, 23 Sep 2022 09:42:50 -0400
>>
>> Then I think using just one term is clearer and I agree with
>> Lars about avoiding "place" as much as possible.  I think GV
>> would be a clearer parameter name than PLACE.
>
> That ship has sailed, unfortunately.

I don't see why a ship has sailed on something without
compatibility issues like changing documentation.

-- 

Howard




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-23 18:11                                   ` Howard Melman
@ 2022-09-23 19:00                                     ` Eli Zaretskii
  0 siblings, 0 replies; 42+ messages in thread
From: Eli Zaretskii @ 2022-09-23 19:00 UTC (permalink / raw)
  To: Howard Melman; +Cc: emacs-devel

> From: Howard Melman <hmelman@gmail.com>
> Date: Fri, 23 Sep 2022 14:11:28 -0400
> 
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Howard Melman <hmelman@gmail.com>
> >> Date: Fri, 23 Sep 2022 09:42:50 -0400
> >>
> >> Then I think using just one term is clearer and I agree with
> >> Lars about avoiding "place" as much as possible.  I think GV
> >> would be a clearer parameter name than PLACE.
> >
> > That ship has sailed, unfortunately.
> 
> I don't see why a ship has sailed on something without
> compatibility issues like changing documentation.

Because by now we have this terminology in gazillion places, and
people are using it and are accustomed to it.



^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 16:14                   ` Stefan Monnier
  2022-09-22 10:47                     ` Lars Ingebrigtsen
  2022-09-22 10:56                     ` Michael Heerdegen
@ 2022-09-30 23:18                     ` Emanuel Berg
  2 siblings, 0 replies; 42+ messages in thread
From: Emanuel Berg @ 2022-09-30 23:18 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier wrote:

> "lvalue" is obviously a special term with a technical
> meaning, contrary to "place".

That's the reason ...

> The downside I can see (beside the obvious churn) is that
> the explanation of lvalue in Wikipedia might prove more
> confusing than helful.

Maybe someone someone from here can make it better then, but
even if it remains something that isn't good, that's not
a reason for us not to use correct terminology ...

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




^ permalink raw reply	[flat|nested] 42+ messages in thread

* Re: master baf1a7a4a0: Turn gv-synthetic-place into a function
  2022-09-21 14:20               ` Stefan Monnier
  2022-09-21 15:31                 ` Eli Zaretskii
@ 2022-09-30 23:30                 ` Emanuel Berg
  1 sibling, 0 replies; 42+ messages in thread
From: Emanuel Berg @ 2022-09-30 23:30 UTC (permalink / raw)
  To: emacs-devel

Stefan Monnier wrote:

> While `gv-` is a handy short prefix, maybe we should stop
> using terms like "place" and "generalized variables" and
> call them "lvalues" like the rest of the world.

Are we talking this? [1]

From a source on C.

  An lvalue (locator value) represents an object that occupies
  some identifiable location in memory (i.e. has an address).

  rvalues are defined by exclusion. Every expression is either
  an lvalue or an rvalue, so, an rvalue is an expression that
  does not represent an object occupying some identifiable
  location in memory.

So maybe an rvalue is just stored somewhere temporarily in the
process of computing something else ...

[1] https://www.tutorialspoint.com/lvalue-and-rvalue-in-c

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




^ permalink raw reply	[flat|nested] 42+ messages in thread

end of thread, other threads:[~2022-09-30 23:30 UTC | newest]

Thread overview: 42+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-09-18 16:13 master baf1a7a4a0: Turn gv-synthetic-place into a function Eli Zaretskii
2022-09-19  6:16 ` Michael Heerdegen
2022-09-19 11:38   ` Eli Zaretskii
2022-09-20  7:28     ` Michael Heerdegen
2022-09-20  7:50       ` Emanuel Berg
2022-09-20 11:19       ` Eli Zaretskii
2022-09-20 14:36         ` Michael Heerdegen
2022-09-20 16:27           ` Eli Zaretskii
2022-09-21  5:40             ` Michael Heerdegen
2022-09-21 14:19               ` Eli Zaretskii
2022-09-21  8:35             ` Emanuel Berg
2022-09-21  8:32           ` Emanuel Berg
2022-09-21 13:52             ` Michael Heerdegen
2022-09-21 14:20               ` Stefan Monnier
2022-09-21 15:31                 ` Eli Zaretskii
2022-09-21 16:14                   ` Stefan Monnier
2022-09-22 10:47                     ` Lars Ingebrigtsen
2022-09-22 11:53                       ` Michael Heerdegen
2022-09-22 14:27                         ` Michael Heerdegen
2022-09-22 16:30                         ` Augusto Stoffel
2022-09-22 17:27                           ` [External] : " Drew Adams
2022-09-22 17:47                             ` Michael Heerdegen
2022-09-23 15:07                         ` Lars Ingebrigtsen
2022-09-22 12:26                       ` Yuri Khan
2022-09-22 14:11                       ` Howard Melman
2022-09-22 16:45                         ` Eli Zaretskii
2022-09-22 19:55                           ` Howard Melman
2022-09-23  6:19                             ` Eli Zaretskii
2022-09-23 13:42                               ` Howard Melman
2022-09-23 15:49                                 ` Stefan Monnier
2022-09-23 18:05                                   ` Howard Melman
2022-09-23 15:54                                 ` Eli Zaretskii
2022-09-23 18:11                                   ` Howard Melman
2022-09-23 19:00                                     ` Eli Zaretskii
2022-09-23  9:41                           ` Michael Heerdegen
2022-09-23 10:53                             ` Eli Zaretskii
2022-09-23 17:26                               ` Emanuel Berg
2022-09-22 10:56                     ` Michael Heerdegen
2022-09-30 23:18                     ` Emanuel Berg
2022-09-30 23:30                 ` Emanuel Berg
2022-09-19 12:06   ` Stefan Monnier
2022-09-20  7:22     ` Michael Heerdegen

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.