Re: Obsoleting `apply-partially`

[Daniel Colascione]

chad <yandros@gmail.com> writes:

> Related to this:
>
> On Tue, Jun 3, 2025 at 10:52 PM Richard Stallman <rms@gnu.org> wrote:
>
>>   >                                  Many other languages, e.g. Python have
>>   > followed. The central idea is to add static typing to dynamic
>>   > languages in a "gradual" manner by providing a way to create
>>   > statically verified islands of typewise correctness while interfacing,
>>   > usually through "any" types, with code not yet typed. That you can
>>   > proceed with adding typing package by package, function by function,
>>   > without breaking anyone is one the hallmarks of this kind of system.
>>
>> It seems like a reasonable approach, and can fit Lisp pretty easily.
>>
>
> I recently came across this project:
>
>   https://github.com/emacs-elsa/Elsa
>
>  The intro on that project page is:
>
> Elsa - Emacs Lisp Static Analyser test
>> (Your favourite princess now in Emacs!)
>
>
>> Elsa is a tool that analyses your code without loading or running it. It
>> is 100% side-effect free and we strive to keep it that way, so you can
>> analyse any elisp code from anywhere safely.
>
>
>> Elsa adds a powerful type system on top of Emacs lisp (completely
>> optional). It can track types and provide helpful hints when things don't
>> match up before you even try to run the code.
>
>
>
> [table of contents elided]
>>
>
>
> Motivation
>> Dynamic programming languages, such as Emacs Lisp, JavaScript and Python,
>> have many advantages over statically typed languages like Java or C++. They
>> allow for faster development and prototyping due to their dynamic nature,
>> which makes it easier to write and test code quickly.
>
>
>> However, dynamic languages lack the type checking and safety features that
>> statically typed languages provide. This can lead to errors that are
>> difficult to catch during development and can cause issues in production.
>> By adding a type system on top of a dynamic language, we can enjoy the
>> benefits of both dynamic and static languages.
>
>
>> Elsa is a type system and analyser for Emacs Lisp, which aims to provide
>> the benefits of a type system while retaining the flexibility and
>> expressiveness of Lisp. It is similar to TypeScript for JavaScript or
>> Python Type Hints for Python in that it provides a way to add static type
>> checking to a dynamically typed language.
>
>
>> Elsa tries to be idiomatic and use as much available information as
>> possible, such as edebug declarations, defmethod specializers or EIEIO
>> class slot types, so the amount of code that needs to be annotated is
>> minimized.
>
>
> I don't know anyone who has tried it out yet.

Huh. That's pretty cool --- and it's being actively developed! I'd hope
the author would be friendly to using a constraint solver (e.g. z3) to
make the thing simultaneously powerful _and_ fast. I particularly like
that they're inspired by TypeScript: its model will work well for Lisp
for the same reason it works well for JavaScript.

- Structural subtyping (as opposed to Python's nominal types) fits
  Lisp-y ad-hoc data structures (like transcript descriptions) well
  without changing working code.  TS can elegantly express the concept
  of "this thing can be a cons with three ints, or a vector of strings,
  or a cons with two ints, a string, and the symbol :xyzzy", all in the
  type system.

- Flow-based type analysis is huge for our codebase, which has explicit
  or (more commonly) implicit typecases everywhere.

- Bidirectional inference is a huge win for a lambda-heavy language like
  Lisp or JS.

> How to write an extension for your-favourite-package

This section of Elsa's documentation concerns me: mypy plugins didn't
work out well for Python .  Next-generation PYthon type checkers like
pyright, pyrefly, and Astral's new ty don't support plugins, and that's
for the best. Better to make the type system itself powerful enough to
express your concepts so you're not stuck with a specific evaluation
model and concomitant bottlenecks.

Oh, BTW: typing Lisp macros is _hard_. AIUI, it's actually
open-research-question hard. I'm excited to see what Elsa comes up
with here.