all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Pip Cet <pipcet@gmail.com>
Cc: Naoya Yamashita <conao3@gmail.com>, emacs-devel@gnu.org
Subject: Re: [PATCH] * src/eval.c: Stop checking for nvars, and use only CONSP
Date: Tue, 02 Mar 2021 18:48:12 -0500	[thread overview]
Message-ID: <jwv1rcxkulc.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <CAOqdjBe8y5DaS8-_xNGcav=w7fGPT5J=j8KD-fJnYQ5Ys4S2bQ@mail.gmail.com> (Pip Cet's message of "Tue, 2 Mar 2021 19:50:23 +0000")

>> That would mean just replacing the `Flet` in C with another in ELisp, so
>> it would largely just move the question (which is about diagnosing
>> invalid code).
> Two advantages: A macro can be redefined and have its redefinition
> apply to compiled code; and, if let were implemented as a macro, other
> letlikes would have a starting point.

I'd be happy to have a "low-level" `let` and then macros on top, yes.
But some kind of let-like thingy at the lowest level is largely
unavoidable for practical reasons (falling back on funcall+lambda is
cute for the theory, but to get acceptable performance you need to
treat that combination specially).

> For example, I'd love
>
> (traced-let ((a 1) (b 2) (c (throw 'out nil)) (d 3)) ...)
>
> to work (and print "a = 1 b = 2 c = <interrupted>"), but every time I
> need it it seems more effort to write than just to debug things the
> old-fashioned way (did I mention it's my non-integral birthday?)...

I can't see any trouble defining such a macro nor in which way it's
influenced by whether `let` itself is a macro or a special form.

> I think this applies to debugging invalid code, too.

What do you mean by "debugging invalid code"?

> I do wonder why other languages have moved to the equivalent of
>
> (defun f (a) (letq x 1) (+ x a))
>
> or
>
> (defun f (a) (+ (letq x 1) a x))

I find this horrible, like Scheme's `define`.
The semantics of such things tends to be quite intricate.

I think what I find ugly about it is that it means an expression affects
the set of variables bound in the surrounding context.

> What seems particularly problematic to me is that other languages can
> emulate "let" easily, but implementing "letq" in ELisp is...an
> interesting exercise (i.e. I tried and failed).

You can emulate it with a new macro `progn-with-lets` which looks for
`letq` in its body.  It's an interesting exercise, indeed, and its
complexity is a good part of why I dislike such features.

> So those are the emacs-devel-relevant questions: Can you implement
> letq in ELisp?

You can, but by its very nature it can't be implemented "as is": it has
to be done within the context of some other element (like
`progn-with-lets`).

> And why does it feel so wrong in ELisp when it's how
> most other languages do this?

Basically those other languages define their functions (and other forms)
to take bodies implicitly wrapped in `progn-with-lets`.

> For bonus points, make
>
> (defun f ()
>   (letq g (lambda () (letq-in g g-counter 0) (letq-in f f-counter 0)
> (incf g-counter) (incf f-counter)))
>   (cons g (lambda () f-counter))

I'm afraid I have no idea what this code means.
[ I must admit, I'm not familiar with your "most other languages" ;-)  ]


        Stefan




  reply	other threads:[~2021-03-02 23:48 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-02  2:10 [PATCH] * src/eval.c: Stop checking for nvars, and use only CONSP Naoya Yamashita
2021-03-02  2:48 ` Stefan Monnier
2021-03-02  3:09   ` Naoya Yamashita
2021-03-02 14:31     ` Stefan Monnier
2021-03-02 15:19       ` Pip Cet
2021-03-02 15:48         ` Stefan Monnier
2021-03-02 17:04           ` Pip Cet
2021-03-02 17:44             ` Stefan Monnier
2021-03-02 19:50               ` Pip Cet
2021-03-02 23:48                 ` Stefan Monnier [this message]
2021-03-02  5:34 ` Pip Cet
2021-03-02  5:41 ` Eli Zaretskii
2021-03-02  7:14   ` Naoya Yamashita
2021-03-02  7:30     ` Pip Cet
2021-03-02 14:00     ` Eli Zaretskii

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

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

  git send-email \
    --in-reply-to=jwv1rcxkulc.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=conao3@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=pipcet@gmail.com \
    /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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.