* Re: The poor state of documentation of pcase like things. [not found] ` <83si2f9ve4.fsf@gnu.org> @ 2016-01-03 4:08 ` Dmitry Gutov 2016-01-03 9:02 ` David Kastrup 2016-01-03 15:26 ` Eli Zaretskii 0 siblings, 2 replies; 12+ messages in thread From: Dmitry Gutov @ 2016-01-03 4:08 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael_heerdegen, emacs-tangents, dancol, dak On 01/03/2016 05:47 AM, Eli Zaretskii wrote: > The syntax of 'when' is nowhere as complex as that of 'pcase'. Obviously. But the given example uses a simple, small subset of pcase syntax. If you don't want to use even that, it seems to indicate that you're going to avoid the more complex uses of it even more so. And thus, never use pcase at all. Which doesn't seem like a good choice, from my perspective. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 4:08 ` The poor state of documentation of pcase like things Dmitry Gutov @ 2016-01-03 9:02 ` David Kastrup 2016-01-03 13:33 ` Dmitry Gutov 2016-01-03 15:26 ` Eli Zaretskii 1 sibling, 1 reply; 12+ messages in thread From: David Kastrup @ 2016-01-03 9:02 UTC (permalink / raw) To: Dmitry Gutov; +Cc: michael_heerdegen, Eli Zaretskii, dancol, emacs-tangents Dmitry Gutov <dgutov@yandex.ru> writes: > On 01/03/2016 05:47 AM, Eli Zaretskii wrote: > >> The syntax of 'when' is nowhere as complex as that of 'pcase'. > > Obviously. > > But the given example uses a simple, small subset of pcase syntax. If > you don't want to use even that, it seems to indicate that you're > going to avoid the more complex uses of it even more so. Uh what? Whether pcase does not help with simple cases should have little bearing on whether it helps with more complex cases. > And thus, never use pcase at all. If it does not help with simple cases, and it does not help with complex cases, yes, that would be the obvious best choice. I don't think that this the argument you intend to make. > Which doesn't seem like a good choice, from my perspective. You are arguing as if we were paid for its use, not as if it had inherent value. Let it make its own case where it actually brings something to the table. We don't replace trivial cases of `if` with `cond`, `while` with `cl-loop` and so on. If we used constructs for the sake of using constructs, the code base would show a lot more use of `cl-do` (which offers little savings in return for its unreadability). Let it speak for itself where it makes sense instead of everywhere. -- David Kastrup ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 9:02 ` David Kastrup @ 2016-01-03 13:33 ` Dmitry Gutov 2016-01-03 14:07 ` David Kastrup 0 siblings, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2016-01-03 13:33 UTC (permalink / raw) To: David Kastrup; +Cc: michael_heerdegen, Eli Zaretskii, dancol, emacs-tangents On 01/03/2016 11:02 AM, David Kastrup wrote: > Uh what? Whether pcase does not help with simple cases should have > little bearing on whether it helps with more complex cases. But it does. It takes less code, and follows the common design of pattern matching, which isn't hard to understand and internalize. In the more complex cases, the syntax may have some thorns, but not in cases where you could replace it with `cl-case'. So if a person refuses to use it, *and* would choose to rewrite it using `cond' on any occasion, that tells me they won't reach for it in the more complex cases either. > If it does not help with simple cases, and it does not help with complex > cases, yes, that would be the obvious best choice. I don't think that > this the argument you intend to make. And I didn't. > You are arguing as if we were paid for its use, not as if it had > inherent value. If *you* use it, *I* get to read it, and enjoy the succinctness and readability. And it's easier to extend later. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 13:33 ` Dmitry Gutov @ 2016-01-03 14:07 ` David Kastrup 2016-01-03 14:10 ` Daniel Colascione 0 siblings, 1 reply; 12+ messages in thread From: David Kastrup @ 2016-01-03 14:07 UTC (permalink / raw) To: Dmitry Gutov; +Cc: michael_heerdegen, Eli Zaretskii, dancol, emacs-tangents Dmitry Gutov <dgutov@yandex.ru> writes: > On 01/03/2016 11:02 AM, David Kastrup wrote: > >> Uh what? Whether pcase does not help with simple cases should have >> little bearing on whether it helps with more complex cases. > > But it does. It takes less code, You mean, less input. > and follows the common design of pattern matching, which isn't hard to > understand and internalize. And yet Emacs has more than just regexp operations for dealing with strings, and most string operations are carried out without reverting to regexps. > In the more complex cases, the syntax may have some thorns, Then it's not doing a good job of reducing complexity. If it requires me to use quasiquote for stuff that contains neither unquote nor unquote-splicing (and has no sensible interpretation of unquote-splicing in connection with its own use of quasiquote anyway), it does a bad human interfacing job. Why do I need to quote self-quoting expressions at all? And why do self-quoting symbols differ in meaning when preceded by quasiquote? In Lisp, `nil is equivalent to nil . That's not what pcase sees, I think. What's actually involved here is that quoted parts are matched literally, and unquoted symbols are matched to single elements. Special-casing only ` and , to work according to that equivalence leads to awkward input, awkward reading, and premature complexity. > So if a person refuses to use it, *and* would choose to rewrite it > using `cond' on any occasion, that tells me they won't reach for it in > the more complex cases either. We don't forcefeed people complex constructs for simple cases. Even the ubiquitous quasiquote is not used gratuitously in our code base just to get people used to the idea they might want to use it in cases where it would actually be needed in connection with unquote or unquote-splicing. >> You are arguing as if we were paid for its use, not as if it had >> inherent value. > > If *you* use it, *I* get to read it, and enjoy the succinctness and > readability. And it's easier to extend later. It is less succinct and readable than existing quite less complex utilities for simple uses. -- David Kastrup ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 14:07 ` David Kastrup @ 2016-01-03 14:10 ` Daniel Colascione 2016-01-03 14:50 ` David Kastrup 0 siblings, 1 reply; 12+ messages in thread From: Daniel Colascione @ 2016-01-03 14:10 UTC (permalink / raw) To: David Kastrup, Dmitry Gutov Cc: michael_heerdegen, Eli Zaretskii, emacs-tangents [-- Attachment #1: Type: text/plain, Size: 1408 bytes --] On 01/03/2016 06:07 AM, David Kastrup wrote: > Dmitry Gutov <dgutov@yandex.ru> writes: > >> On 01/03/2016 11:02 AM, David Kastrup wrote: >> >>> Uh what? Whether pcase does not help with simple cases should have >>> little bearing on whether it helps with more complex cases. >> >> But it does. It takes less code, > > You mean, less input. A side effect of a more expressive system. >> and follows the common design of pattern matching, which isn't hard to >> understand and internalize. > > And yet Emacs has more than just regexp operations for dealing with > strings, and most string operations are carried out without reverting to > regexps. > >> In the more complex cases, the syntax may have some thorns, > > Then it's not doing a good job of reducing complexity. If it requires > me to use quasiquote for stuff that contains neither unquote nor > unquote-splicing (and has no sensible interpretation of unquote-splicing > in connection with its own use of quasiquote anyway), it does a bad > human interfacing job. Why do I need to quote self-quoting expressions > at all? And why do self-quoting symbols differ in meaning when preceded > by quasiquote? In Lisp, `nil is equivalent to nil . That's not what > pcase sees, I think. I find pcase quite readable; it's not going away. Honestly, I also found the existing documentation completely adequate. [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 14:10 ` Daniel Colascione @ 2016-01-03 14:50 ` David Kastrup 2016-01-03 14:56 ` Daniel Colascione 2016-01-03 14:57 ` Dmitry Gutov 0 siblings, 2 replies; 12+ messages in thread From: David Kastrup @ 2016-01-03 14:50 UTC (permalink / raw) To: Daniel Colascione Cc: michael_heerdegen, Eli Zaretskii, emacs-tangents, Dmitry Gutov Daniel Colascione <dancol@dancol.org> writes: > On 01/03/2016 06:07 AM, David Kastrup wrote: >> Dmitry Gutov <dgutov@yandex.ru> writes: >> >>> On 01/03/2016 11:02 AM, David Kastrup wrote: >>> >>>> Uh what? Whether pcase does not help with simple cases should have >>>> little bearing on whether it helps with more complex cases. >>> >>> But it does. It takes less code, >> >> You mean, less input. > > A side effect of a more expressive system. > >>> and follows the common design of pattern matching, which isn't hard to >>> understand and internalize. >> >> And yet Emacs has more than just regexp operations for dealing with >> strings, and most string operations are carried out without reverting to >> regexps. >> >>> In the more complex cases, the syntax may have some thorns, >> >> Then it's not doing a good job of reducing complexity. If it requires >> me to use quasiquote for stuff that contains neither unquote nor >> unquote-splicing (and has no sensible interpretation of unquote-splicing >> in connection with its own use of quasiquote anyway), it does a bad >> human interfacing job. Why do I need to quote self-quoting expressions >> at all? And why do self-quoting symbols differ in meaning when preceded >> by quasiquote? In Lisp, `nil is equivalent to nil . That's not what >> pcase sees, I think. > > I find pcase quite readable; it's not going away. So it should not get fixed or made more consistent with expectations? > Honestly, I also found the existing documentation completely adequate. The problem is that its underlying design principle, matching quoted stuff structurally/literally and using unquoted symbols as variable names, is only implemented in a cursory manner. That means that reading a pcase expression and understanding what it does does not enable you to fix it with confidence or write your own. Its forced use of `quasiquote' where `quote' would suffice were it properly implemented is a contributor to the "there must be something non-obvious going on" impression. Scheme has the somewhat similar pattern matching library by Andrew Wright <URL:http://wiki.call-cc.org/man/3/Pattern%20matching> but it does not make the design mistake of using quasiquote while ignoring quote. People don't use it as a control structure replacement, however, in spite of it being more coherent and powerful than Emacs' pcase. It is used when needed and/or appropriate. Which is perfectly fine. For example, matching patterns in the byte compiler would be an excellent case for working with matching/binding constructs of that kind. Indeed, Scheme's more "modern" replacement of the macro system, syntax forms, tends to be used for a lot of code in Scheme interpreters/compilers (particularly in GUILE-2.x, incidentally a significant contributing factor to its abysmal bootstrapping performance as the bootstrapping variant does not scale to the task) and is also of somewhat similar kind. But syntax-case system, while based on similarly syntaxed elements, is quite different from a particular expression matcher as it basically is used to extend one large global pattern matcher used for eval rather than doing a single matching operation per call. -- David Kastrup ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 14:50 ` David Kastrup @ 2016-01-03 14:56 ` Daniel Colascione 2016-01-03 14:57 ` Dmitry Gutov 1 sibling, 0 replies; 12+ messages in thread From: Daniel Colascione @ 2016-01-03 14:56 UTC (permalink / raw) To: David Kastrup Cc: michael_heerdegen, Eli Zaretskii, emacs-tangents, Dmitry Gutov [-- Attachment #1: Type: text/plain, Size: 2113 bytes --] On 01/03/2016 06:50 AM, David Kastrup wrote: > Daniel Colascione <dancol@dancol.org> writes: > >> On 01/03/2016 06:07 AM, David Kastrup wrote: >>> Dmitry Gutov <dgutov@yandex.ru> writes: >>> >>>> On 01/03/2016 11:02 AM, David Kastrup wrote: >>>> >>>>> Uh what? Whether pcase does not help with simple cases should have >>>>> little bearing on whether it helps with more complex cases. >>>> >>>> But it does. It takes less code, >>> >>> You mean, less input. >> >> A side effect of a more expressive system. >> >>>> and follows the common design of pattern matching, which isn't hard to >>>> understand and internalize. >>> >>> And yet Emacs has more than just regexp operations for dealing with >>> strings, and most string operations are carried out without reverting to >>> regexps. >>> >>>> In the more complex cases, the syntax may have some thorns, >>> >>> Then it's not doing a good job of reducing complexity. If it requires >>> me to use quasiquote for stuff that contains neither unquote nor >>> unquote-splicing (and has no sensible interpretation of unquote-splicing >>> in connection with its own use of quasiquote anyway), it does a bad >>> human interfacing job. Why do I need to quote self-quoting expressions >>> at all? And why do self-quoting symbols differ in meaning when preceded >>> by quasiquote? In Lisp, `nil is equivalent to nil . That's not what >>> pcase sees, I think. >> >> I find pcase quite readable; it's not going away. > > So it should not get fixed or made more consistent with expectations? > >> Honestly, I also found the existing documentation completely adequate. > > The problem is that its underlying design principle, matching quoted > stuff structurally/literally and using unquoted symbols as variable > names, is only implemented in a cursory manner. That means that reading > a pcase expression and understanding what it does does not enable you to > fix it with confidence or write your own. I find it adequately general --- much more so than, say, destructuring-bind. Do you have a concrete proposal? [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 14:50 ` David Kastrup 2016-01-03 14:56 ` Daniel Colascione @ 2016-01-03 14:57 ` Dmitry Gutov 2016-01-03 15:15 ` David Kastrup 1 sibling, 1 reply; 12+ messages in thread From: Dmitry Gutov @ 2016-01-03 14:57 UTC (permalink / raw) To: David Kastrup, Daniel Colascione Cc: michael_heerdegen, Eli Zaretskii, emacs-tangents On 01/03/2016 04:50 PM, David Kastrup wrote: > So it should not get fixed or made more consistent with expectations? I think you should file bug(s) with specific examples and improvements. > Its forced use of `quasiquote' where `quote' would suffice were it > properly implemented is a contributor to the "there must be something > non-obvious going on" impression. IIUC, you can use quotes where they would "suffice". ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 14:57 ` Dmitry Gutov @ 2016-01-03 15:15 ` David Kastrup 2016-01-03 15:21 ` Dmitry Gutov 0 siblings, 1 reply; 12+ messages in thread From: David Kastrup @ 2016-01-03 15:15 UTC (permalink / raw) To: Dmitry Gutov Cc: michael_heerdegen, Eli Zaretskii, Daniel Colascione, emacs-tangents Dmitry Gutov <dgutov@yandex.ru> writes: > On 01/03/2016 04:50 PM, David Kastrup wrote: > >> So it should not get fixed or made more consistent with expectations? > > I think you should file bug(s) with specific examples and improvements. > >> Its forced use of `quasiquote' where `quote' would suffice were it >> properly implemented is a contributor to the "there must be something >> non-obvious going on" impression. > > IIUC, you can use quotes where they would "suffice". So why would people write (pcase exp (`nil nil) ... ? What's with the overuse of quasiquote? -- David Kastrup ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 15:15 ` David Kastrup @ 2016-01-03 15:21 ` Dmitry Gutov 0 siblings, 0 replies; 12+ messages in thread From: Dmitry Gutov @ 2016-01-03 15:21 UTC (permalink / raw) To: David Kastrup Cc: michael_heerdegen, Eli Zaretskii, Daniel Colascione, emacs-tangents On 01/03/2016 05:15 PM, David Kastrup wrote: > So why would people write > > (pcase exp > (`nil nil) ... Easier to just use the same kind of quote everywhere? > ? What's with the overuse of quasiquote? You should ask those people. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 4:08 ` The poor state of documentation of pcase like things Dmitry Gutov 2016-01-03 9:02 ` David Kastrup @ 2016-01-03 15:26 ` Eli Zaretskii 2016-01-03 20:02 ` John Wiegley 1 sibling, 1 reply; 12+ messages in thread From: Eli Zaretskii @ 2016-01-03 15:26 UTC (permalink / raw) To: Dmitry Gutov; +Cc: michael_heerdegen, emacs-tangents, dancol, dak > Cc: dancol@dancol.org, michael_heerdegen@web.de, dak@gnu.org, > emacs-tangents@gnu.org > From: Dmitry Gutov <dgutov@yandex.ru> > Date: Sun, 3 Jan 2016 06:08:35 +0200 > > On 01/03/2016 05:47 AM, Eli Zaretskii wrote: > > > The syntax of 'when' is nowhere as complex as that of 'pcase'. > > Obviously. > > But the given example uses a simple, small subset of pcase syntax. If > you don't want to use even that, it seems to indicate that you're going > to avoid the more complex uses of it even more so. And thus, never use > pcase at all. > > Which doesn't seem like a good choice, from my perspective. But that's not my choice. My choice is to use 'pcase' where it's really needed. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: The poor state of documentation of pcase like things. 2016-01-03 15:26 ` Eli Zaretskii @ 2016-01-03 20:02 ` John Wiegley 0 siblings, 0 replies; 12+ messages in thread From: John Wiegley @ 2016-01-03 20:02 UTC (permalink / raw) To: Eli Zaretskii Cc: michael_heerdegen, emacs-tangents, dancol, dak, Dmitry Gutov >>>>> Eli Zaretskii <eliz@gnu.org> writes: > But that's not my choice. My choice is to use 'pcase' where it's really > needed. I like `destructuring-bind' for simple pattern matches, and cond for simple logic, but I really like pcase for combining the two. I guess we're all really just arguing about balance, which even for one individual changes based on mood and perspective. -- John Wiegley GPG fingerprint = 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-01-03 20:02 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <20151216202605.GA3752@acm.fritz.box> [not found] ` <CAFyQvY3_3g7CUwXf18X55d8XR3Ho9Z5wK-JcmVnXNWnuxQvB6g@mail.gmail.com> [not found] ` <m2twngk2oq.fsf@newartisans.com> [not found] ` <E1aBymS-0007vq-Nh@fencepost.gnu.org> [not found] ` <m2twn84bkq.fsf@newartisans.com> [not found] ` <E1aCLFi-0003B8-Dz@fencepost.gnu.org> [not found] ` <87io3m60bq.fsf@web.de> [not found] ` <E1aCi70-0006Zt-OJ@fencepost.gnu.org> [not found] ` <877fk1nnk0.fsf@web.de> [not found] ` <8760zlue3j.fsf@gmail.com> [not found] ` <87vb7kajgv.fsf@web.de> [not found] ` <83y4c9ag06.fsf@gnu.org> [not found] ` <m2ziwpur9m.fsf@newartisans.com> [not found] ` <87bn95m9eg.fsf@fencepost.gnu.org> [not found] ` <5686CDFB.2010105@dancol.org> [not found] ` <83fuygcs5g.fsf@gnu.org> [not found] ` <56886E32.70305@yandex.ru> [not found] ` <83si2f9ve4.fsf@gnu.org> 2016-01-03 4:08 ` The poor state of documentation of pcase like things Dmitry Gutov 2016-01-03 9:02 ` David Kastrup 2016-01-03 13:33 ` Dmitry Gutov 2016-01-03 14:07 ` David Kastrup 2016-01-03 14:10 ` Daniel Colascione 2016-01-03 14:50 ` David Kastrup 2016-01-03 14:56 ` Daniel Colascione 2016-01-03 14:57 ` Dmitry Gutov 2016-01-03 15:15 ` David Kastrup 2016-01-03 15:21 ` Dmitry Gutov 2016-01-03 15:26 ` Eli Zaretskii 2016-01-03 20:02 ` John Wiegley
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).