[Top][All Lists]

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

Re: [PATCH] Generalize start-process with keyword args

From: Eli Zaretskii
Subject: Re: [PATCH] Generalize start-process with keyword args
Date: Wed, 18 Mar 2015 18:23:25 +0200

> From: Daiki Ueno <address@hidden>
> Cc: Stefan Monnier <address@hidden>,  address@hidden
> Date: Wed, 18 Mar 2015 15:17:39 +0900
> > IMO, it will be terribly confusing to have incompatible treatment of
> > nil in this one API.
> I tend to agree with Stefan, as I find no documentation about the
> implication of no-conversion for ":coding nil" except in the C source
> code.

Since you mentioned the documentation, you seem to interpret
"confusing" as in "confusing Lisp programmers".  But that's not what I
meant: I meant that this unfortunate convention will confuse Lisp
programs which call this API instead or together with the existing
APIs.  Despite what you might think, this convention _is_ used in
several places in Emacs sources; I've bumped into it in the past.  If
'make-process' wants to be compatible with existing interfaces, it
should use the same conventions.

For example, imagine some wrapper around 'make-process' that generates
the coding systems from some data, like MIME charset or something.
Such programs usually test the validity of the result by calling
coding-system-p (which returns t for nil), and if that returns OK, go
ahead and use the resulting coding system.  Imagine the confusion if
'make-process' rejects such values, or assigns its own semantics to
some of them.

I could support a thorough eradication of this convention from all
related interfaces.  But doing that for a single interface is not TRT,
IMO, as it will increase the memory pressure on the Lisp programmers,
which will now have to remember 2 different conventions about this,
and also which API supports which semantics of nil there.  Moreover,
if we ever want to replace 'start-process' with 'make-process' in some
it the users of the former, we will now have to remember to add code
that, when given nil, passes 'binary'.  That's worse than bad
conventions, IMO.

reply via email to

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