emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Replace trivial pcase occurrences in the Emacs sources


From: Eli Zaretskii
Subject: Re: Replace trivial pcase occurrences in the Emacs sources
Date: Tue, 30 Oct 2018 21:54:29 +0200

> From: Stefan Monnier <address@hidden>
> Date: Tue, 30 Oct 2018 15:21:52 -0400
> 
> >> +* Destructuring patterns:: Using pcase patterns to extract subfields.
> > We never used "pcase patterns" in the manual before, so I wonder
> > whether we should start now.  If we want to do that, this should be
> > defined before it is used.
> 
> I'm uncomfortable using "pattern" to refer to "pcase pattern" unless the
> context makes it clear.  I'm not completely sure where best to define
> pcase patterns.

I think the best place of defining them is where we first describe
them, i.e. in the section about pcase itself.

> >> +The macros described in this section use @emph{destructuring}
> >> +patterns, which are normal Pcase patterns used in a context where we
> >> +presume that the object does match the pattern, and we only want
> >> +to extract some subfields.
> >
> > I think we need to define "destructuring" here (or elsewhere in the
> > manual, and have a cross-reference there in this section).
> 
> The paragraph you quoted is exactly what I consider the definition of
> "destructuring pattern" (I don't see a need to define "destructuring"
> separately: the word placed in front of "pattern" is here treated as
> a kind of "proper name", just chosen so that it will help some if they
> already know the term from elsewhere, such as cl-destructuring-bind).

The "destructuring" part needs to make sense, or at least we should
strive that it does.  It isn't a random word.

> > Readers that aren't familiar with that term will not be able to
> > understand why this word is used here.  We need to start this with
> > something like
> >
> >   @dfn{Destructuring} means ...
> 
> I'd rather rename those to "Monnier patterns" and avoid the problem, if
> that's what it takes.

No, I think "destructuring" is about right.  How about this text:

  @dfn{Destructuring} of an object is an operation that extracts
  multiple values stored in the object, e.g., the 2nd and the 3rd
  element of a list or a vector.  @dfn{Destructuring binding} is
  similar to a local binding (@pxref{Local Variables}), but it gives
  values to multiple elements of a variable by extracting those values
  from an object of compatible structure.

> > It would also help to tell what exactly makes a pattern a
> > destructuring one.
> 
> As the paragraph says: it's the context in which it's used.

I'm not sure I understand.  AFAIU, not every pattern described in
"pcase Macro" can be a destructuring one.  Right?

> >> +All @var{exp}s are evaluated first after which they are matched
> >> +against their respective @var{pattern}, introducing new variable
> >> +bindings which can then be used inside @var{body}.
> > AFAIU, this means only some of the pcase patterns make sense in this
> > context.  If that is true, I'd suggest ti somehow tell which are (or
> > which aren't, if that's easier).
> 
> Not sure what you're thinking of.

See above: not every pattern can be a destructuring one, AFAIU.

> >> address@hidden pcase-dolist (pattern list) address@hidden
> >> +This construct executes @var{body} once for each element of
> >> address@hidden, in a context where the destructuring pattern
> >> address@hidden was matched against the element.
> >
> > I don't think I understand what "in a context where the pattern was
> > matched" means here.  Is any aspect of the match except destructuring
> > bindings relevant to execution of the body?
> 
> No.  But those extra bindings are exactly the context I'm referring to.
> In my work, "context" and "environment" are the usual words used to
> refer to the map that links identifiers to their corresponding
> information (typically, type or value depending on the
> ...ahem... context).

I find this too abstract in general, so I think it's better to be
specific where we can.

Thanks.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]