emacs-devel
[Top][All Lists]
Advanced

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

Re: Why is there no `until' in elisp?


From: Garreau\, Alexandre
Subject: Re: Why is there no `until' in elisp?
Date: Wed, 17 Oct 2018 11:23:15 +0200
User-agent: Gnus (5.13), GNU Emacs 25.1.1 (i686-pc-linux-gnu)

On 2018-10-17 at 15:04, Yuri Khan wrote:
> In both these implementations, ‘until’ is still a pre-condition loop
> (same as ‘while’, but with the condition negated).

Something such as the C “do” construct might overcomplicate the
language, while I think normal `while' and `until' are not only simpler
but also superior: with those you have the case of 0 loops, in which
basically works as a when.

> However, in many languages that have an ‘until’ loop as a language
> construct, it is a post-condition loop. The body is executed first,
> then the condition is evaluated.

Which languages?  I looked again in bash to be sure, and bash doesn’t do
that.

> Of course, that raises additional questions…
>
> * Should a hypothetical ELisp ‘until’ macro implement a post-condition loop?

I find this a useless discrepancy, coming from inconsistent languages,
that shouldn’t be imported in elisp.  Which is less bad than others in
this respect.

> * If so, should the condition be passed as the last argument?

I guess so, it’d be confusing otherwise.  Yet from a low level
standpoint it’s not trivial (you need last arg of the linked list, but
you might just as well delay the problem by just using `progn'), but
this time I feel this stays elegant enough as the other form present no
real advantages.

>   * If so, how should indentation work? (indent the body 4 spaces,
> condition 2 spaces?)

I guess… can (indent …) declaration constructs allow that?

>   * The macro will then have to take body and condition as a single
> &rest list, and split it, right?

Yes I think.  Since here it’s a lot more crucial and important than a
basic side-effects / not-always-used thing such as `progn' (though if I
wanted to make `progn' look more functional I’d do the same for it, as
an option).

I’ve alway found sad that `defun' &args specs were not powerful enough
for this kind of things (&rest rest &optional last), or even supporting
docstrings (although that requires typing so…).



reply via email to

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