[Top][All Lists]

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

Re: native compilation units

From: Stefan Monnier
Subject: Re: native compilation units
Date: Sun, 12 Jun 2022 14:47:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

>> >> In which sense would it be different from:
>> >>
>> >>     (cl-flet
>> >>         ...
>> >>       (defun ...)
>> >>       (defun ...)
>> >>       ...)
>> >>
>> >>
>> > Good point - it's my scheme background confusing me.  I was thinking defun
>> > would operate with similar scoping rules as defvar and establish a local
>> > binding, where fset (like setq) would not create any new bindings.
>> I was not talking about performance but about semantics (under the
>> assumption that if the semantics is the same then it should be possible
>> to get the same performance somehow).
> I'm trying to determine if there's a set of expressions for which it
> is semantically sound to perform the intraprocedural optimizations

The cl-flet above is such an example, AFAIK.  Or maybe I don't
understand what you mean.

> I'm trying to capture a function as a first class value.

Functions are first class values and they can be trivially captured via
things like (setq foo (lambda ...)), (defalias 'foo (lambda ...)) and
a lot more, so I there's some additional constraint you're expecting but
I don't know what that is.

> This was not expected with lexical scope.

You explicitly write `(require 'cl-lib)` but I don't see any

    -*- lexical-binding:t -*-

anywhere, so I suspect you forgot to add those cookies that are needed
to get proper lexical scoping.

> With the current byte-codes, there's just no way to express a call to
> an offset in the current byte-vector.

Indeed, but you can call a byte-code object instead.


reply via email to

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