Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> +(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.)

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

?

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Stefan Monnier]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Emanuel Berg]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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?

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Emanuel Berg]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Emanuel Berg]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Stefan Monnier]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Stefan Monnier]

>> 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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Lars Ingebrigtsen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Yuri Khan]

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).

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Howard Melman]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Augusto Stoffel]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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, ...

RE: [External] : Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Drew Adams]

> 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?

Re: [External] : Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Howard Melman]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Michael Heerdegen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Howard Melman]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Lars Ingebrigtsen]

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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Stefan Monnier]

> 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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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?

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Emanuel Berg]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Howard Melman]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Howard Melman]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Eli Zaretskii]

> 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.

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Emanuel Berg]

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

Re: master baf1a7a4a0: Turn gv-synthetic-place into a function

[Emanuel Berg]

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