unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Emanuel Berg <incal@dataswamp.org>
To: emacs-devel@gnu.org
Subject: Re: optional argument defaults in `cl-defun' vs old way - warning, discrepancy!
Date: Sat, 07 Oct 2023 15:01:42 +0200	[thread overview]
Message-ID: <87ttr21t8p.fsf@dataswamp.org> (raw)
In-Reply-To: 8149455e-40e4-4566-8a3c-96834e803be0@alphapapa.net

Adam Porter wrote:

> Yes, this is how CL optional and keyword arguments work.
> See (info "(cl) Argument Lists") and search for "SVAR".
> It does require a bit more diligence in some cases, but it
> also provides more flexibility. And FWIW, I think I actually
> have to check the SVAR something like 1% of the time [...]

Okay, but how does one know when that has to be checked?
Because after writing the `cl-defun', certain use which one
didn't plan for, still cannot be allowed to break it. And if
one has to check SVAR for every cl-defun, I don't see the
advantage with the &optional arg default syntax being big
enough to prefer cl-defun to `defun' for the use case of
optional args.

At least with `defun' and &optional, nil always means the
default has to be used - even if nil was submitted explicitely
by a programmer or a program - or rather, that doesn't exist
as a special case so one doesn't have to care about it.

In practice, with defun, it would me to always check if
&optional args ar set, and if not, set each of them to
a default value. But not having to do that with `cl-defun' is
not a clear advantage anymore, since one sometimes (or
always?) has to check SVAR instead.

Note that this, i.e. having to check for nils with defun,
doesn't mean nil can't be used as the default. It would only
amount to

  (or arg (setq arg nil))

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




  reply	other threads:[~2023-10-07 13:01 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-06  2:30 optional argument defaults in `cl-defun' vs old way - warning, discrepancy! Emanuel Berg
2023-10-06  9:36 ` Adam Porter
2023-10-07 13:01   ` Emanuel Berg [this message]
2023-10-06 13:54 ` [External] : " Drew Adams
2023-10-07 13:12   ` Emanuel Berg
2023-10-06 21:37 ` Richard Stallman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ttr21t8p.fsf@dataswamp.org \
    --to=incal@dataswamp.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

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